Ale jaja, forum działa!

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