Strona główna › Forums › Klub dyskusyjny › Ale jaja, forum działa!
Nowością na dzisiaj jest kolejna gra przeportowana z Linuksa. Tym razem sztuka polega na tym, żeby widoczną na ilustracji większą kulką wypchać z planszy kulki mniejsze. Żeby nie było tak łatwo, te mniejsze próbują z kolei wypchnąć nas. Zbierane bonusy pozwalają przybrać na masie i prędkości, co jak wiadomo z fizyki, zadanie nam ułatwia. Tyle można powiedzieć na temat wyszukanej fabuły. Gra działa szybko nawet na sprzęcie klasy 500 MHz, chociaż biblioteka SDL kryjąca się za widoczną obok zaawansowaną grafiką, tradycyjnie obciąża nam procesor do oporu. Grę z Linuksa na Amigę przeportował James Jacobs, a Stefan Haubenthal przeniósł ją na nasz ulubiony system. Gra spoczęła na MorphOS Files.
Zastanawia mnie na czym polega takie portowanie? Rozumiem, że autorzy portu nie mieli źródeł i przez to gra nie jest tak wydajna jak mogłaby być? Kod C++ z x86 różni się aż tak od tego PPC?
Autorzy mieli źródła i nie w procesorze tkwi problem. Z jakiegoś niezrozumiałego dla mnie powodu 99% gier korzystających z biblioteki SDL jest napisane tak, że nawet, gdy mają nadmiar mocy procesora na swoje potrzeby, obciążają go w 100%. Nie jest to do końca wina samej biblioteki, bo można grę napisać tak, żeby miała np. limit ramek na sekundę i na szybkim sprzęcie oddawała nadmiarowy czas procesora systemowi. Zwłaszcza taką prostą grę jak Koules.
Mnie za to zastanawia że po co marnować czas na portowanie takiego badziewia.
Ender jednym slowem czy grasz czy nie to procek sie poci az wiatrak furkoce 😉
Fakt. Aczkolwiek ja zawsze sobie tlumacze, ze to w celach edu. Nie wszystko da sie przeportowac za pomoca configure;make czyli cos tam sie ow ‘porter’ naumial… chyba.
Jeżeli ktoś umie tylko portować, to nie jest to aż takie marnotrawstwo… Stefan mógłby zamiast tego oglądać telenowele, z dwojga złego lepiej niech portuje ;-P.
Jeżeli ktoś umie tylko portować, to nie jest to aż takie marnotrawstwo… Stefan mógłby zamiast tego oglądać telenowele, z dwojga złego lepiej niech portuje ;-P.
Kto wie czy nie wolałbym sdlowej wersji Brzyduli czy innego M jak Morphos 😉
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.
Sprawdziłem sobie dowolne gry i żadna z nich nie obciąża procesora maksymalnie. Masz jakieś badziewne gry ;).
Dokładnie – FPSE-MOS z gierką Trick’n Snowboarder + ANR z mp3 daje góra 75 % obciążenia cpu 🙂
Czyli jest źle skonstruowana… Chyba, że programista zakłada, że żaden sprzęt nie jest dość dobry dla jego dzieła… Ja rozumiem, że pełnoekranowa gra full wypas raczej będzie chciała dużo zasobów. Ale taki mały casual nie imponujący bynajmniej grafiką czy ilością animowanych obiektów jak Koules? Na co, pytam się, on zużywa ten procesor? Na uzyskanie 150 fps? Po co? W tego rodzaju grach powinien być limit górny szybkości odświeżania i po jego osiągnięciu gra powinna przestać pobierać więcej mocy CPU niż potrzebuje.
Niektore gry maja w opcjach magiczny przelacznik "limit FPS", ktory rozwiazuje problem i sprawdza sie idealnie szczegolnie na laptopach, ktore dzieki temu nie musza szumiec okrutnie wentylatorami.
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. 🙂
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
Copyright 2014 - Wszelkie prawa zastrzeżone MorphOS.pl