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 - 1 z 15 (of 35 wszystkich)
  • Autor
    Wpisy
  • #145
    recedentrecedent
    Participant

    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.

    #411
    EnderEnder
    Participant

    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?

    #412
    Avatarkrashan
    Participant
    Rozumiem, że autorzy portu nie mieli źródeł i przez to gra nie jest tak wydajna jak mogłaby być?

    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.

    #413
    pamperspampers
    Participant
    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?

    Mnie za to zastanawia że po co marnować czas na portowanie takiego badziewia.

    #414
    AvatarRadziN
    Participant
    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?

    Ender jednym slowem czy grasz czy nie to procek sie poci az wiatrak furkoce 😉

    #415
    AvatarRadziN
    Participant
    Mnie za to zastanawia że po co marnować czas na portowanie takiego badziewia.

    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.

    #416
    Avatarkrashan
    Participant
    Mnie za to zastanawia że po co marnować czas na portowanie takiego badziewia.

    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.

    #417
    pamperspampers
    Participant
    Mnie za to zastanawia że po co marnować czas na portowanie takiego badziewia.

    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 😉

    #418
    MDWMDW
    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. 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.

    #419
    AvatarKorni
    Participant

    Sprawdziłem sobie dowolne gry i żadna z nich nie obciąża procesora maksymalnie. Masz jakieś badziewne gry ;).

    #420
    edeede
    Participant

    Dokładnie – FPSE-MOS z gierką Trick’n Snowboarder + ANR z mp3 daje góra 75 % obciążenia cpu 🙂

    #421
    Avatarkrashan
    Participant
    Tak jest skonstruowana typowa pętla główna każdej gry.

    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.

    #422
    AvatarGość
    Participant

    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.

    #424
    MDWMDW
    Participant

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

    #425
    recedentrecedent
    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

Widok 15 wpisów - 1 z 15 (of 35 wszystkich)
  • Musisz być zalogowany aby odpowiedzieć na ten temat.