Od czasu wersji 0.72 platformowej przygodówki The Legend of Edgar, jej twórcy poczynili szereg poprawek w kodzie, a także rozbudowali grę o cztery nowe etapy. Cieszy więc to, że „Hak”, który regularnie portuje tę grę na MorphOS-a, zajął się kilka dni temu najnowszą wersją 0.85. Archiwum z grą można pobrać ze strony autora portu lub z MorphOS Files.
Zamieszczone przez: admin, 18 komentarzy
Komentarze:
Prosta (do granicy toporności), ale zabawna. Jak na razie.
No i oczywiście wsysa całą moc Pegasosa. Z drugiej strony robi przy tym zaledwie 30 klatek na sekundę, więc może ma to uzasadnienie… Prawdą też jest, że okno otworzone na ekranie z włączonymi efektami 3D, w którym to oknie cały czas się coś dzieje, obciąża okrutnie procesor, niezależnie od tego, czy za akcją stoi biblioteka SDL czy nie… Na pełnym ekranie gra robi 46 fps i jeszcze można uznać, że chcę, aby szła na to cała moc procesora. Swoją drogą nasuwa się refleksja, czy żeby w takiej grze mieć 46 ramek na sekundę, potrzebna jest cała moc G4 i Radka 9200? No ale MDW pisał już o niewydolności SDL-a w grafice 2D.
Jak to jest rysowane tymi klasycznymi funkcjami 2D SDL i cały czas cały ekran jest przerysowywany niezależnie od tego czy coś się dzieje czy nie to pewnie musi tak męczyć procesor. Tak naprawdę nie bardzo się orientuje jak bardzo powolne są te funkcje i dedukuję tylko z postów innych na forum.warsztat.gd, które śledzę od kilku lat.
Jeżeli chodzi o sam SDL to oczywiście można oddać światu nadmiarowy czas procesora. Ja już przerobiłem to nasze nieszczęsne Fortis żeby tak było. Wersja 1.2 już czeka na wypuszczenie. Jak tylko dostanę pozytywne wyniki testów na sprzęcie, którego nie mam to wypuszczę. Do tej pory gra wciągała 100% procesora na moim Pegasosie 2 G4/1000. Teraz jak patrzę na wykresik to wciąga ok. 40-50%. Oczywiście podczas ciągłego przerysowywania całego ekranu.
Na Miniaczu w okienku przy zużyciu 93-95% procesora robi 48-50 FPS, na fullscreenie podobnie. Myślę, że możemy to podciągnąć pod "wsysa całą dostępną moc, a i tak nie działa szybciej niż 50 FPS".
Na Miniaczu w okienku przy zużyciu 93-95% procesora robi 48-50 FPS, na fullscreenie podobnie. Myślę, że możemy to podciągnąć pod "wsysa całą dostępną moc, a i tak nie działa szybciej niż 50 FPS".
Zapewne jest to robione tak, że jest ograniczenie do 50 FPS. No i teraz jak wszystko udało się policzyć i ekran odrysować w mniej niż 1/50 sekundy to do końca tego czasu czekają robiąc nic. Jednak to "nic" też zjada czas procesora, a powinno oddać światu zewnętrznemu. 🙂 Trzeba byłoby zerknąć do pętli głównej gry żeby zobaczyć co się tam dzieje. Widzę, że w tych multiplatformowych tworach często ludzie mają to głęboko w nosie. 🙂 Robią tak jakby to robili np. na jakąś konsolę gdzie odpalona gra jest władcą sprzętu i gdzie nikt niczego w tle nie odpali. 🙂
No to zerknąłem, a co mi tam. Odkrycie pierwsze: gra ma limit FPS-ów i wynosi on 60 ramek na sekundę. Odkrycie drugie: pętla jest napisana w taki sposób, że jeżeli ma nadmiar czasu, to wywołuje SDL_Delay(). Pytanie teraz jak jest zaimplementowana ta funkcja w naszym PowerSDL, jednak nie wierzę, żeby itix zrobił ją na busyloopie… Jeżeli jednak SDL_Delay() prawidłowo oddaje czas procesora systemowi, to wniosek jest prosty, że po prostu nasze sprzęty są za wolne, żeby grać w Edgara z pełną szybkością… Co z lekka przeraża i każe zapytać o efektywność samego SDL (bo widać, że programista rozwiązał główną pętlę chyba poprawnie). Przecież w tej grze animuje się raptem kilka elementów, jak chodziłem sobie po planszy tutorialowej, to miałem w porywach trzy animowane elementy, a i tak miałem tylko 46 fps. Wydaje mi się, że głównym problemem jest fakt, że rysowanie gry w SDL odbywa się na płaszczyźnie pikseli umieszczonej w pamięci i ta płaszczyzna co ramkę jest w całości blitowana na ekran. Pod MorphOS-em niestety odbywa się to przy pomocy procesora i stąd chyba się bierze słaba wydolność SDL. Zupełnie inaczej wygląda to w Fortisie, gdzie (z tego co wiem) procesorem na początku ładuje się wszystkie elementy gry do pamięci karty graficznej, a potem przy rysowaniu zasuwa GPU, procesor główny liczy tylko logikę i geometrię gry (pewnie nie do końca mam rację, ale MDW mnie poprawi jakby co
).
Ooo, że Ci się chciało. Fajnie. 🙂
No to ja od razu odpowiem na podstawie moich ostatnich doświadczeń. Funkcja SDL_Delay() w PowerSDL oddaje czas procesorowi. Właśnie tak to zrobiłem i od razu połowa procesora (G4/1000) zaczęła odpoczywać. Zarówno pod MorphOS, Windows, jak i MacOSX.
Co do metody rysowania wszystkiego w Fortis to jest właśnie tak jak mówisz. Cała logika i geometria jest liczona procesorem, a rysowanie odbywa się przez GPU. To oczywiście nie moja zasługa tylko TinyGL. 🙂 Ja tylko używam jego funkcji zamiast tych SDLowych. Gdybyśmy weszli na poziom wyżej z naszym TinyGL i mieli shadery to i liczenie geometrii zostałoby zrzucone na GPU. Procesor liczyłby tylko logikę, coś tam czytał z dysku, brał udział w odtwarzaniu dźwięku. No ale aplikacja musi być napisana pod shadery. Nie wystarczy, że tinygl.library i sterowniki zaczną wspierać OpenGL 2.x, 3.x… No ale na razie mamy OpenGL 1.x i z tego też się cieszę. 🙂
!!! No cóż, trzeba będzie podkręcić Miniacza, żeby w pełni nacieszyć się tą wyśmienitą, acz wymagającą pozycją.
(/me zakasuje rękawy i idzie kręcić).
No i wychodzi na to, że SDL to porażka. Nie ma innego ratunku? Nie zamierzam ruszać SDL-a, widzę, że to strata czasu.
Ja bym szedł drogą taką jak MDW, czyli użył TinyGL. Nawet jeżeli gra jest całkowicie 2D (Fortisa można nazwać „2,5D”), to można skorzystać z akceleratora karty do rysowania. Podstawowa zaleta jest taka, że procesor nie jest prawie w ogóle obciążony rysowaniem, a przerzucanie bitmap odbywa się w obrębie karty graficznej. Dodatkowo rzeczy takie jak kanał alpha w obiektach masz za darmo.
Bo widzisz, SDL często spełnia taką dziwną rolę… Jak się pisze coś w 3D to czyste C/C++ i OpenGL pozwalają rysować sobie bardzo wydajnie trójkąty, człowiek sobie napisze jakieś klasy/funkcje do odczytu jakichś formatów, zrobi prawie wszystko co nie jest bezpośrednio związane z danym systemem. Problem tylko w tym, że tych trójkątów nie ma na czym rysować. 🙂 Potrzebne jest okno/ekran, trzeba jakoś obsłużyć klawiaturę, mysz, joystick, czasem odtworzyć jakiś dźwięk. Źeby zrobić te rzeczy to trzeba się zagłębiać już w systemowe aspekty programowania i znać podstawy systemu pod który się pisze. No a jak ktoś chce coś zrobić na kilka systemów to warstwę tych rzeczy, które wymieniłem trzeba na każdym systemie pisać od początku i w dodatku znać każdy z tych systemów. No i dlatego dawno temu powstała taka biblioteka zwana GLUT. Można nią było sobie otworzyć ekran, stworzyć proste menu, odczytać stan klawiszy, myszy. To można było zrobić raz i kompilowało się na wszystkich platformach (na AmigaOS GLUT miała StormMESA, na MorphOS bardzo szczątkowy GLUT ma TinyGL). No ale GLUT wiele lat temu zakończył swój rozwój na etapie dosyć średnim. Przez swoją multiplatformowość był dosyć ograniczony. Dzisiaj rolę tego GLUT-a często przejmuje właśnie SDL. Ludzie używają go do pisania rzeczy pod system, którego zupełnie nie kumają. 🙂 SDL daje znacznie większe możliwości od GLUT, bo obsługuje jakieś fonty, rozróżnia endiany, obsługuje dźwięk, można nim odczytać wszystkie dostępne tryby graficzne, otworzyć okno, oczytać stan klawiszy, myszy, joysticków, a nawet używać sieci, tworzyć wątki. Można też nim rysować w 2D. No ale właśnie te funkcje są jakieś takie wolne. Oczywiście da się coś w tym zrobić, bo przecież tak chyba została napisana gra Robin Hood (czy jaki ona tam tytuł nosiła) – ta która jest na MacOSX, Windows, MorphOS i chyba Linux.
Jak się nie używa tych funkcji do rysowania to SDL jest przyjemny i jak na standard multiplatformowy całkiem zgodny z systemem. 🙂 Na forach spotykałem kupę ludzi, którzy nawet nie chcąc portować potem swojej gry na inne systemy użwali SDL pisząc program pod Windows. Po prostu nie chcieli dotywać koszmarnego podobno WinAPI. SDL jest przyjemniejszy, szybciej się pod niego pisze niż pod WindAPI. No a do rysowania i tak używają OpenGL, bo to często są gry 3D. 🙂 Można też się bawić w 2D. Po prostu ustawia się odpowiednio macierze, a każdy sprite to dwa trójkąty z teksturą. Narobić się trzeba, bo wypadałoby to ubrać w jakieś zgrabne klasy/biblioteki żeby nie trzeba było za każdym razem wypełniać ręcznie VertexArrayów i inne takiego tam… No ale jak się już zrobi takie rzeczy to możliwości są dużo fajniejsze. Takie rzeczy jak skalowanie, zmiana kolorów, przezroczystości, obracanie właściwie nie kosztuje nic. 🙂 Wszystko zaiwania jak dzikie i nie dotyka procesora.
Brakuje mi jakiejś intl.library 🙁
Może Aminet?


http://aminet.net/search?query=intl.library
Bez jaj zręcznościówki na A500 miały lepszą grafikę mimo iż był w mniejszej ilości kolorów i to wyciska 50 fps ??
No cóż… tak to bywa. 🙂 Trochę jest to cena przenośności, trochę znak czasów, trochę wybranie niewłaściwej technologii, trochę brak umiejętności grafików. Na szczęście nie zawsze tak jest dzisiaj i jest cała masa produkcji, które w miarę normalnie wykorzystują możliwości udostępniane przez dzisiejsze sprzęty i systemy.
Coz, gierka jest 3bit a nie 8 bit, muzyka leci jako wav albo mp3. Rozdzielczosc dodatkowo robi swoje. Nie bronie jej ale to jest bardzo duza roznica miedzy ta a grami z klasyka. Ofcoz nadal uwazam ta gre za gniot ale ma kilka ciekawych rozwiazan.
Coz, gierka jest 3bit a nie 8 bit, muzyka leci jako wav albo mp3. Rozdzielczosc dodatkowo robi swoje. Nie bronie jej ale to jest bardzo duza roznica miedzy ta a grami z klasyka. Ofcoz nadal uwazam ta gre za gniot ale ma kilka ciekawych rozwiazan.
Co po 32 bitach jak wyglada biedniej niż Ruff&Tumble czy Elfmania. Muzyka jest gorsza niż dobre MODY. Poprostu ta jak w przypadku pushover teraz mając Gigaherce nikt się nie przejmuje wydajnością 🙁
Akurat to słaby argument jest, bo muzyka to właśnie MODY (konkretnie .xm-y, czyli moduły fasttrackera). Zdaje się, że można podmieniać na swoje ulubione.