MorphOS.pl – Polska strona użytkowników MorphOS-a
MorphOS.pl – Polska strona użytkowników MorphOS-a

Strona główna Forums Klub dyskusyjny Ale jaja, forum działa!

Widok 15 wpisów - 16 z 30 (of 35 wszystkich)
  • Autor
    Wpisy
  • #426
    MDW
    Participant
    Muszę zaktualizować Fortis, bo to normalnie wstyd żeby tak to działało.

    Yeah, Fortis™ 1.2 jednak nadchodzi! I będzie można grać bez ryczącego w tle wentylatora na G4
    Jednak jest jakiś pożytek z tej gry Koules

    Za aktualizacją mi się nie pali, bo mam świadomość, że tej gry i tak już nikt nie dotyka. No ale wypada zaktualizować. Teraz jestem skupiony na dwóch kolejnych grach. Jedna została wstrzymana przez brak odważnego wydawcy, który podjąłby się wydania tak chorego pomysłu. Jednak ta nie ma znaczenia dla amigowego świata, bo gra ma sens tylko na ekranie dotykowym z multitouch. Druga to prosta gierka. Też raczej bardziej pasuje do różnych smartfonów/tabletów z ekranami dotykowymi (już bez multitouch). Jednak nie ma technicznej przeszkody żeby grac też przy pomocy myszy więc ciągnę także wersję dla MorphOS. 🙂

    #427
    krashan
    Participant
    Oczywiście mogłem użyć SDL_WaitEvent() zamiast SDL_PoolEvent() ale wtedy pętla stała do momentu gdy ruszyłem myszą/klawiaturą, a rysować przecież trzeba, nie? 🙂

    I tu właśnie wyłażą wady multiplatformowych bibliotek. W systemie amigowym zrobiłbyś tak, że timer.device odpowiadałoby Ci na request w regularnych odstępach czasu, a sygnał portu powrotnego tej odpowiedzi dodałbyś do maski Wait() w głównej pętli. Wtedy, po przeliczeniu i narysowaniu ramki spokojnie wszedłbyś w Wait() oddając systemowi procesor bez obawy, że musisz czekać na ruch użytkownika myszą. Nawet jeżeli użytkownik nic nie zrobi, Wait() wróci po sygnale z timera i spokojnie narysujesz następną klatkę… A jak łatwo użytkownikowi dać do ręki regulację FPS-ów (np. na potrzeby urządzenia pracującego z baterii) – wystarczy zmienić interwał czasu dla timer.device. To chyba wiem o czym będzie pierwszy artykuł programistyczny na MorphOS.pl…

    #428
    MDW
    Participant
    Oczywiście mogłem użyć SDL_WaitEvent() zamiast SDL_PoolEvent() ale wtedy pętla stała do momentu gdy ruszyłem myszą/klawiaturą, a rysować przecież trzeba, nie? 🙂

    I tu właśnie wyłażą wady multiplatformowych bibliotek. W systemie amigowym zrobiłbyś tak, że timer.device odpowiadałoby Ci na request w regularnych odstępach czasu, a sygnał portu powrotnego tej odpowiedzi dodałbyś do maski Wait() w głównej pętli. Wtedy, po przeliczeniu i narysowaniu ramki spokojnie wszedłbyś w Wait() oddając systemowi procesor bez obawy, że musisz czekać na ruch użytkownika myszą. Nawet jeżeli użytkownik nic nie zrobi, Wait() wróci po sygnale z timera i spokojnie narysujesz następną klatkę… A jak łatwo użytkownikowi dać do ręki regulację FPS-ów (np. na potrzeby urządzenia pracującego z baterii) – wystarczy zmienić interwał czasu dla timer.device. To chyba wiem o czym będzie pierwszy artykuł programistyczny na MorphOS.pl…

    To prawda, stosowanie multiplatformowych rozwiązań jest na pewno dużo bardziej toporne i mniej eleganckie. Zwłaszcza dla kogoś kto siedzi głęboko w jakimś systemie.

    A jeżeli chodzi o regulację max FPS to też jest to u mnie kwestia zmiany jednej zmiennej. Na iPhone/iPod/iPad robię tak, że jak wylezie na wierzch jakiś systemowy requester (SMS/MMS, info o baterii, przypominajka, powiadomienie z PushNotification, itp.) to zmniejszam maxFPS do 10FPS. Po powrocie do gry znów wracam do normalnej wartości. Problem ciągle był tylko w tym, że nadmiarowy czas nie był oddawany procesorowi tylko para szła w gwizdek, maszyna robiła dosłownie nic oprócz "aktywnego czekania". 🙂 No ale jest ok i to dzięki temu, że mnie (może nieświadomie) zmusiłeś.

    #433
    rzookol
    Participant
    Oczywiście mogłem użyć SDL_WaitEvent() zamiast SDL_PoolEvent() ale wtedy pętla stała do momentu gdy ruszyłem myszą/klawiaturą, a rysować przecież trzeba, nie? 🙂

    I tu właśnie wyłażą wady multiplatformowych bibliotek. W systemie amigowym zrobiłbyś tak, że timer.device odpowiadałoby Ci na request w regularnych odstępach czasu, a sygnał portu powrotnego tej odpowiedzi dodałbyś do maski Wait() w głównej pętli. Wtedy, po przeliczeniu i narysowaniu ramki spokojnie wszedłbyś w Wait() oddając systemowi procesor bez obawy, że musisz czekać na ruch użytkownika myszą. Nawet jeżeli użytkownik nic nie zrobi, Wait() wróci po sygnale z timera i spokojnie narysujesz następną klatkę… A jak łatwo użytkownikowi dać do ręki regulację FPS-ów (np. na potrzeby urządzenia pracującego z baterii) – wystarczy zmienić interwał czasu dla timer.device. To chyba wiem o czym będzie pierwszy artykuł programistyczny na MorphOS.pl…

    To prawda, stosowanie multiplatformowych rozwiązań jest na pewno dużo bardziej toporne i mniej eleganckie. Zwłaszcza dla kogoś kto siedzi głęboko w jakimś systemie.

    A jeżeli chodzi o regulację max FPS to też jest to u mnie kwestia zmiany jednej zmiennej. Na iPhone/iPod/iPad robię tak, że jak wylezie na wierzch jakiś systemowy requester (SMS/MMS, info o baterii, przypominajka, powiadomienie z PushNotification, itp.) to zmniejszam maxFPS do 10FPS. Po powrocie do gry znów wracam do normalnej wartości. Problem ciągle był tylko w tym, że nadmiarowy czas nie był oddawany procesorowi tylko para szła w gwizdek, maszyna robiła dosłownie nic oprócz "aktywnego czekania". 🙂 No ale jest ok i to dzięki temu, że mnie (może nieświadomie) zmusiłeś.

    nie do końca pamiętam SDL ale poprawnie by było zapuścic timera który by generował co określony czas własny event na który by się czekało w WaitEvent, sdl ma takie możliwości

    ps. może jak już przerabisz fortisa to fajnie by było dodać obsługe joystików

    #434
    MDW
    Participant
    nie do końca pamiętam SDL ale poprawnie by było zapuścic timera który by generował co określony czas własny event na który by się czekało w WaitEvent, sdl ma takie możliwości

    No chyba masz rację. Też na coś takiego trafiłem grzebiąc dzisiaj w dokumentacji. Jednak na razie właściwie nie ma potrzeby, bo eventy z klawiatury/myszy i tak są łapane, a tak czy inaczej obsłużę je w dokładnie tym samym miejscu.

    ps. może jak już przerabisz fortisa to fajnie by było dodać obsługe joystików

    Ale w to nikt już nie gra. 🙂 Chęć mam i pewnie kiedyś się wezmę. Tylko kurde nie mam kiedy nawet robić tego co teraz robię. 🙁 Niezbyt lubię wracać do Fortis, bo postanowiłem nie utrzymywać kompatybilność Fortis z nowszymi wersjami moich biednych rozwiązań (nie mam śmiałości nazwać tego silnikiem). Zbyt dużo tam zmieniałem i wiele rzeczy robię inaczej w dzisiejszych moich crapach. 🙂

    #435
    fazior
    Participant

    A ja dam kulkom szansę, czasem takie małe popierdółki potrafią wciągnąć, choć na mosa jeszcze nie spotkałem SDLowej popierdółki która by mnie wessała

    #437
    Ender
    Participant

    Przydałby się krótki kurs robienia gier dla Morphosa. Coś jak C…oś do grania z MA. Tyle tylko że mogłaby być dla przykładu jakaś platformówka zrobiona (C++). A czy myślał ktoś nad stworzeniem języka dla Morphos-a typowo do tworzenia gier i nic więcej? (Coś jak nieśmiertelny Amos. BlitzBasic ma chyba większe możliwości i jest bardziej wszechstronny)

    #439
    MDW
    Participant
    A czy myślał ktoś nad stworzeniem języka dla Morphos-a typowo do tworzenia gier i nic więcej? (Coś jak nieśmiertelny Amos. BlitzBasic ma chyba większe możliwości i jest bardziej wszechstronny)

    Język typowy do gier? Jest dla MorphOS/AmigaOS/AROS od zawsze. Dawniej było to C, a teraz C++. 🙂 I nie nabijam się, mówię całkiem serio. Wystarczy popatrzeć w czym pisze się 99% większych gier. Jest to zawsze C++. Owszem, coś tam powstaje w C#, Javie, Flash/ActionScript, a nawet Pythonie. Jednak panowanie C++ w gamedev (przynajmniej tym dużym) ciągle jest niepodważalne. No może jeszcze w przypadku urządzeń Apple często używa się Objective-C ale to też C-pochodne i natywne. Powód jest chyba zawsze ten sam – potrzeba prędkości. Zwolennicy różnych wirtualnych maszyn często udowadniają, że da się w ich językach zrobić coś szybkiego. Są miliony fanbojskich dowodów na to. Jednak co aplikacja natywna to jednak natywna. W przypadku gdy liczy się każda millisekunda, wirtualne maszyny, garbage collectory i inne cuda tylko przeszkadzają. Poza tym język to tylko język. I tak ważne są biblioteki do rysowania (2D, 3D), jakieś silniki do fizyki, logiki. Duże produkcje często używają języków skryptowych do opisania jakiejś logiki (często jest to Lua, który dzięki Krashanowi istnieje też w wersji dla MorphOS-a). Jak ktoś chce się uwolnić od rzeczy bardzo niskopoziomowych i podstawowych to używa jakiegoś kompletnego silnika (ja akurat nie lubię). Ludzie chorzy (ja) piszą własne nieudolne silniki. 🙂

    Jeżeli mogę coś doradzić swoim na podstawie swojego lamerskiego ale jednak wieloletniego doświadczenia to nie traćcie czasu na jakieś dziwaczne języki. Bez sensu się bawić w jakieś Basici. Ja bardzo żałuję, że dopiero w 2000 roku napisałem pierwsze Hello World w C.

    #440
    Ender
    Participant

    Pewnie masz rację, bo coś już stworzyłeś. Mnie chodziło oto że C++ jest mocno rozbudowany i nie wszystko jest potrzebne takiemu "Kowalskiemu" jak ja. I jak tu wybrać to co niezbędne? Ja raczej jako programista pracować nie będę, ale chętnie nauczyłbym sie tego i owego z C++. Niestety pozostaje pytanie czego muszą spróbować, a co mogę sobie podarować, bo w grach tego się nie wykorzysta. Może jakiś przewodnik – dekalog programisty gier komputerowych?

    #442
    pampers
    Participant
    Przydałby się krótki kurs robienia gier dla Morphosa. Coś jak C…oś do grania z MA. Tyle tylko że mogłaby być dla przykładu jakaś platformówka zrobiona (C++). A czy myślał ktoś nad stworzeniem języka dla Morphos-a typowo do tworzenia gier i nic więcej? (Coś jak nieśmiertelny Amos. BlitzBasic ma chyba większe możliwości i jest bardziej wszechstronny)

    Możliwe że pojawi się AmiDarkEngine dla MorphOSa. Jednak nic nie jest jeszcze przesądzone. Link tutaj: http://www.amidark-engine.com/

    #443
    Tygrys
    Participant
    Przydałby się krótki kurs robienia gier dla Morphosa. Coś jak C…oś do grania z MA.

    Huh, miło wiedzieć że ktoś to przeczytał, a do tego pamięta po latach 😉

    Ja bym teraz jednak zainteresował się jakąś biblioteką, jak chociażby SDL, która mocno ułatwia pisanie gier. Artykułów opisujących sposób programowania gier z użyciem SDLa jest mnóstwo, również w języku polskim. Zaletą SDL jest to że raz napisaną grę kompilujesz na wiele platform.

    #444
    Gość
    Participant
    Każda dynamiczna gra obciąża maksymalnie procesor. Nie ma to nic wspólnego z SDL. Tak jest skonstruowana typowa pętla główna każdej gry.

    No i tak chyba powinna działać każda gra systemowa, oprócz gier pod "WB". A resztę chyba trzeba określić priorytetami tasków. 🙂

    #445
    Ender
    Participant
    Przydałby się krótki kurs robienia gier dla Morphosa. Coś jak C…oś do grania z MA.

    Huh, miło wiedzieć że ktoś to przeczytał, a do tego pamięta po latach 😉

    Ja bym teraz jednak zainteresował się jakąś biblioteką, jak chociażby SDL, która mocno ułatwia pisanie gier. Artykułów opisujących sposób programowania gier z użyciem SDLa jest mnóstwo, również w języku polskim. Zaletą SDL jest to że raz napisaną grę kompilujesz na wiele platform.

    No ale z tego co czytam SDL raczej się nie sprawdza to raz, a dwa mnie interesuje tworzenie typowo pod Morphos-a a nie multiplatformowo. Ja nie zamierzam podbijać świata, a jedynie chciałbym zaistnieć w środowisku.

    #446
    Ender
    Participant

    Już widzę, myślałem, że to błąd.

    #447
    Gość
    Participant
    No ale z tego co czytam SDL raczej się nie sprawdza to raz, a dwa mnie interesuje tworzenie typowo pod Morphos-a a nie multiplatformowo. Ja nie zamierzam podbijać świata, a jedynie chciałbym zaistnieć w środowisku.

    Tak czy inaczej, np. GNU Robbo dla MOSa to aktualnie, jedyna grywalna wersja na klasyku (na własnym ekranie). Starodawna wersja GNU Robbo dla AOS4 prędkościowo nie nadaje się do grania. Na 68k też wiadomo jak jest.
    Ja uważam że zajętość procesora na MOSie nie znaczy nic, dopóki przy jakiejś grze SDL można spokojnie oglądać film i jednocześnie odsłuchać mp3. Lepsze gry SDL niż brak gier w ogóle. 🙂

Widok 15 wpisów - 16 z 30 (of 35 wszystkich)
  • Musisz być zalogowany aby odpowiedzieć na ten temat.
Warning: realpath(): open_basedir restriction in effect. File(/) is not within the allowed path(s): (/usr/home/widelec/domains/morphos.pl/public_html:/tmp:/usr/share:/usr/local/share/pear:/dev) in /usr/home/widelec/domains/morphos.pl/public_html/wp-includes/functions.php on line 2056 Warning: realpath(): open_basedir restriction in effect. File(/) is not within the allowed path(s): (/usr/home/widelec/domains/morphos.pl/public_html:/tmp:/usr/share:/usr/local/share/pear:/dev) in /usr/home/widelec/domains/morphos.pl/public_html/wp-includes/functions.php on line 2056 Warning: realpath(): open_basedir restriction in effect. File(/) is not within the allowed path(s): (/usr/home/widelec/domains/morphos.pl/public_html:/tmp:/usr/share:/usr/local/share/pear:/dev) in /usr/home/widelec/domains/morphos.pl/public_html/wp-includes/functions.php on line 2056 Warning: realpath(): open_basedir restriction in effect. File(/) is not within the allowed path(s): (/usr/home/widelec/domains/morphos.pl/public_html:/tmp:/usr/share:/usr/local/share/pear:/dev) in /usr/home/widelec/domains/morphos.pl/public_html/wp-includes/functions.php on line 2056 Warning: realpath(): open_basedir restriction in effect. File(/) is not within the allowed path(s): (/usr/home/widelec/domains/morphos.pl/public_html:/tmp:/usr/share:/usr/local/share/pear:/dev) in /usr/home/widelec/domains/morphos.pl/public_html/wp-includes/functions.php on line 2056 Warning: realpath(): open_basedir restriction in effect. File(/) is not within the allowed path(s): (/usr/home/widelec/domains/morphos.pl/public_html:/tmp:/usr/share:/usr/local/share/pear:/dev) in /usr/home/widelec/domains/morphos.pl/public_html/wp-includes/functions.php on line 2056