[MDW]

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ś.

[MDW]

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. 🙂

[MDW]

Krashan:
Muszę zwrócić Ci/Wam honor. 🙂 Przyznam, że robię to z wielką radością. 🙂 Już piszę o co chodzi…

Tak mnie wkurzyło to narzekanie, że 100% zajętości procka to wina SDL, że w końcu postanowiłem popatrzeć o co w tym chodzi i czy naprawdę nie da się nadmiarowego czasu jaki zostaje do narysowania ramki oddać procesorowi zamiast czekać bez sensu na odebranie sygnału z klawiatury/myszy (bo renderowanie i tak mam ograniczone do częstotliwości odświeżania ekranu). 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? 🙂 No ale nie chciało mi się wierzyć, że to tak ma być. Owszem, gry napierniczają na maxa i często zjadają wszystko co daje komputer. No ale takie proste gry aż tyle nie muszę zjadać. Dzisiejszy komputer się przy nich nudzi. 😀

Popatrzyłem na Google i często jako rozwiązanie problemu pojawia się SDL_Delay(), spróbowałem i faktycznie to było to. 😀 Pojęcia nie miałem, że SDL_Delay() nie zjada czasu procesora. 🙂 Zrobiłem szybką modyfikację i naprawdę jest przeogromna różnica. 🙂 Pod ręką mam teraz tylko peceta ale to nie ma znaczenia. CPU Usage z 50% (czyli 100% jednego rdzenia, bo to dwurdzeniowy) spadło do 0-9% (w zależności od tego się akurat dzieje na ekranie. Do tego dostałem właśnie odpowiedź na forum Warsztatu (takie forum dla gameklepaczy) i gość mnie utwierdził w przekonaniu o słuszności SDL_Delay pokazując swoje rozwiązanie. Wcześniej byłem sceptycznie nastawiony do SDL_Delay dodatkowo z tego powodu, że wtedy nie dostaję informacji z klawiatury/myszy. No ale po co mi te informacje wtedy? Przecież one nie zginą i wszystkie je dostanę przy następnym SDL_PoolEvent().

Muszę zaktualizować Fortis, bo to normalnie wstyd żeby tak to działało. 😀

Dzięki za zmobilizowanie mnie do zajęcia się tą, prostacką przecież, sprawą. 🙂

quaint:
Fortis w MacAppStore też zaktualizuję w najbliższych dniach. 🙂

[MDW]

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. Wyjątkiem są jakieś szachy czy coś takiego. Naprawdę sprawdźcie sobie dowolną grę. W grze wszystko musi być przerysowane, zaktualizowane kilkadziesiąt razy na sekundę więc nie ma wyjścia. Ok, może w tej grze zostałoby jeszcze trochę procka, bo nie ma tu nic wielkiego. Ale naprawdę niezależnie od tego czy jest to SuperFrog, Quake, Benefactor, Lemmings, Heretic, Settlers czy cokolwiek innego to tak wygląda. I tak jest na wszystkich platformach.

[Autor]

Wpisy