Strona główna › Forums › Klub dyskusyjny › Ale jaja, forum działa!
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. 🙂
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…
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ś.
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
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.
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. 🙂
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
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)
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.
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?
Możliwe że pojawi się AmiDarkEngine dla MorphOSa. Jednak nic nie jest jeszcze przesądzone. Link tutaj: http://www.amidark-engine.com/
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 i tak chyba powinna działać każda gra systemowa, oprócz gier pod "WB". A resztę chyba trzeba określić priorytetami tasków. 🙂
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.
Już widzę, myślałem, że to błąd.
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. 🙂
Copyright 2014 - Wszelkie prawa zastrzeżone MorphOS.pl