Wydajność i Optymalizacja w grach

[krzysio664]

Witam,

Ostatnio dużo myślałem, nad zwiększeniem wydajności w grach.

Ankieta ma na celu sprawdzenia najskuteczniejszej metody na optymizację gry. Która metoda jest najlepsza, najskuteczniejsza?

 

EDIT: Jakby jakiejś metody brakowało pisać.

[Moe]

Według mnie kod gry / programu należy pisać w najzwięźlejszej formie, bez "Długich rozpisków" itd...

 

Takie moje zdanie,

Moe

 

Edit.

Nie zauważyłem ankiety, dodałeś za późno :)

Według mnie 2.

[PsichiX]

bez "Długich rozpisków"

co to znaczy?

[Moe]

co to znaczy?

 

Jak by to wytłumaczyć, o to, żeby kod był bardziej zwięzły i czytelny, oraz żeby starać się go w miarę skracać.

[Muuuuczek567]

Na pierwszy ogień idzie dezaktywacja/aktywacja obiektów.

Można niszczyć obiekty, gdy wyjdą poza room.

Rysowanie tekstów można zostawić surface'om, jeśli wartości wyświetlanych tekstów nie zmieniają się często.

No i tak jak napisał Moe, zwięzłość kodu.

[Markuz]

Czasami kod może być dłuższy a gra jest bardziej wydajna :)

[Platyna]

Jak by to wytłumaczyć, o to, żeby kod był bardziej zwięzły i czytelny, oraz żeby starać się go w miarę skracać.

Częściowo się nie zgodzę. Markuz dobrze rzecze! W algorytmice najprostsze i najkrótsze rozwiązania to zazwyczaj rozwiązania brutowe. Nieraz (bardzo często) kod co ma 300 linijek może w sekundę wykonać operację, którą 10 linijkowy kod będzie wykonywał godzinę.

 

Z tym, że akurat w prostych grach jakie tu się zwykle pojawiają jakieś skomplikowane algorytmy zwykle potrzebne nie są. Więc rzeczywiście na wasze potrzeby zwykle prosty, zwięzły kod jest lepszy.

[Moe]

Czasami kod może być dłuższy a gra jest bardziej wydajna :)

 

Takie zjawisko jest rzadkie jak kupa słonia

 

W kupie siła! W kupie moc!

[krzysio664]

Ankieta zaktualizowana.

 

A jak sprawa wygląda z wczytywaniem zasobów z plików, zdarzają się lagi? ile czasu potrzeba na wczytanie takich zasobów, czy wczytywać na początku gry czy w czasie?

[Platyna]

Takie zjawisko jest rzadkie jak kupa słonia

 

W kupie siła! W kupie moc!

 

Nie wiem jak rzadka jest kupa słonia, ale takie zjawisko jest częste. A optymalizacja kodu to właśnie szukanie rozwiązań o najmniejszej złożoności czasowej, a nie maksymalne go skracanie.

Wojna! ^^

 

A jak sprawa wygląda z wczytywaniem zasobów z plików, zdarzają się lagi? ile czasu potrzeba na wczytanie takich zasobów, czy wczytywać na początku gry czy w czasie?

Wtedy kiedy taka grafika jest potrzebna. Najlepiej na początku każdego poziomu wczytywać co jest potrzebne, a po jego zakończeniu zwalniać pamięć.

[krzysio664]

A edytor map?

 

EDIT: Dokładnie mi chodzi o edytor map, zapisanie mapy w plik np. level1.lev oraz wczytanie do w grze.

[Platyna]

A edytor map?

Znacznie zmniejsza to rozmiar pliku wykonywalnego oraz wczytywanie gry na samym początku. Za to dłuższe ładowanie będzie przed każdym levelem, bo zawsze trzeba taki na nowo wczytać.

Ja uważam, że poziomy zapisane w plikach to lepszy pomysł niż w exe w roomach.

[candy]

Jest tylko mały minus. Trzeba plik w jakiś sposób zabezpieczyć przed odczytem.

[krzysio664]

Jest tylko mały minus. Trzeba plik w jakiś sposób zabezpieczyć przed odczytem.

 

Szyfrowanie plików jest w skuteczne, lecz zwiększa objętość .exa

 

 

A kto był by za tym że: Tiles i backgroundy w edytorze jako .lev a objekty wczytywane z plików a w .exe same skrypty. Chyba było by to bardzo skuteczne no nie?

[PsichiX]

Szyfrowanie plików jest w skuteczne, lecz zwiększa objętość .exa

taka zwiększona objętość jak żadna

[krzysio664]

Czyli na razie wygrywa optymizacja kodu i wczytywanie zasobów z plików

 

EDIT: Jeszcze jakieś propozycje??

[Snake]

Znacznie zmniejsza to rozmiar pliku wykonywalnego oraz wczytywanie gry na samym początku.

Nie zgadzam się. Zmiana w rozmiarze raczej będzie niezauważalna a i zmiana długości ładowania gry raczej będzie nikła. Własny edytor poziomów powinno się pisać, jeśli standardowy nie będzie się nadawać do potrzeb gry, chce się umożliwić graczom tworzenie leveli, albo chcesz mieć wygodniejsze narzędzie do tego celu. Bardziej zoptymalizujesz sobie tym efektywność tworzenia gry niż jej działanie :P

 

Co do optymalizacji to inteligentna deaktywacja obiektów i ładowanie zasobów kiedy zachodzi potrzeba to konieczność przy większych grach. Also, GMAPI >:)

A "Optymalizacja kodu" to zbyt ogólne określenie.

[Platyna]

To niech mi ktoś mądry powie, bo mnie to zastanawia czy jest różnica w prędkości wykonywania między rozbijaniem kodu na różne eventy, a wrzucaniem wszystkiego jak leci do Stepa przy pomocy odpowiednich warunków? ; )

 

 

EDIT:

Toś mnie Snake zaskoczył, przyznam. Logiczne mi się wydaje, że znacznie mniejszy będzie rozmiar i czas wczytywania jeśli będzie w exe 5 roomów zamiast 50. Roomy mi się zawsze wydawały tymi najbardziej pamięcio-chłonnymi.

[krzysio664]

Zgadzam się z Platyną.

Plik .exe będzie mieć mniejszy rozmiar i będzie się szybciej wczytywać.

Roomy są jednym z najważniejszych rzeczy w Game makerze i muszą dużo zajmować xD

[Platyna]

Zgadzam się z Platyną.

Plik .exe będzie mieć mniejszy rozmiar i będzie się szybciej wczytywać.

Roomy są jednym z najważniejszych rzeczy w Game makerze i muszą dużo zajmować xD

 

Ale on tego nie kwestionuje wcale. Twierdzi tylko, że różnica będzie niewielka. I po głębszym przemyśleniu jednak się zgadzam. Room to właściwie tylko trochę tekstu. Numery obiektów i ich współrzędne głównie. Bardziej pamięcio-chłonne są jednak z pewnością grafiki.

[Darlix]

Hmmm... optymalizacja kodu jest z deka pracochłonna (w zależności od umiejętności programisty) i przydaje się bardziej przy większych grach. Grafika jak napisał Platyna wyżej, najlepiej wczytywana z zewnątrz (broń Boże duże obrazki, tekstury w *.bmp! Poleciłbym png ale chyba są problemy z przezroczystością), muzyka z resztą też (Mp3, midi, ogg, byle nie wav jak wiadomo częstotliwośc próbkowania jest sporo większa a jakościowo różnicy bodajże nie ma) a skrypty w pliku wykonywalnym można zostawić. Oczywiście to moje zdanie.

[don_soyer]

tak, grafiki, i Snake ma racje że trzeba je tudzież zasoby, wczytywać gdy są potrzebne szczególnie w dużych grach, gdzie tekstury są na pół pulpitu a soundtracki kilkuminutowe .

 

ed. ja uzywam tylko png, nawet do animacji nie używam .gif tylko sklejam png

[Snake]

Ale on tego nie kwestionuje wcale. Twierdzi tylko, że różnica będzie niewielka. I po głębszym przemyśleniu jednak się zgadzam. Room to właściwie tylko trochę tekstu. Numery obiektów i ich współrzędne głównie. Bardziej pamięcio-chłonne są jednak z pewnością grafiki.

 

Yup, tylko, że roomy są zapisane binarnie, więc też mniej bajtów wychodzi. No i potem to wszystko jest kompresowane ZLIBem. A jeszcze co do czasu ładowania, to ile dobrze pamiętam to od GM8 przy ładowaniu runner używa kilku wątków, więc na multi-core'ach jeszcze szybciej może się załadować.

 

Co do skryptu który sam obsługuje eventy, po tym co wczoraj widziałem w kodzie GM-a pomagając Psichixowi to możliwe że będzie to odrobinę wydajniejsze, ale przy małej ilości eventów (przynajmniej w GM8, gdzie GML jest już trochę wydajniejszy). Na dłuższą metę jednak wbudowana obsługa eventów raczej będzie szybsza :P

 

Jeśli chodzi o format obrazów to BMP wydaje się, że będzie się szybciej ładować, ale tylko jeśli gra ładuje zasoby z jakiegoś szybkiego nośnika. PNG i te sprawy po załadowaniu i tak trzeba przerobić na mapę bitową, a na tym ucierpi procesor :P

[PsichiX]

broń Boże duże obrazki, tekstury w *.bmp

nie ma znaczenia jaki format, właśnie takie bmp jest najszybciej ładowalne, bo jest bliskie surowemu formatowi pixeli, a wszystkie obrazki niezaleznie jakiego formatu musza byc konwertowane do formatu surowego (czyli takieog ktory karta graficzna ztrawi), czyli i tak wszystkie grafiki w pamieci zajmuja tyle samo niezaleznie czy to 512x512 png czy bmp, tak wiec PNG czy JPG swoj atut klada na rozmiar pliku, nie na szybkosc czy rozmiar w pamieci

[Bedi]

YXE, czyli używanie formatu BMP będzie najszybszym rozwiązaniem?

 

EDIT: Moje zdanie jest takie. Po pierwsze - obiekty. Deatywuj/usuwaj te co niepotrzebne. Tak jak ktoś wspomniał, że nawet te obiekty, które nic nie robią, zaśmiecają pamięć bo ładują swoje podstawowe zmienne (x, y, sprite_index). Następnie optymalizacja kodu. Wg. mnie kod powinien jak najszybciej wykonywać swoje zadanie, nawet jeśli miałby być trochę długi (ale bez przesady).

A co do tej grafiki i innych zasobów ładowanych z zewnątrz, to wydaje mi się, że gry które się pojawiają na GMClanie, nie wymagają tego ;) Bo coś takiego przydałoby się, gdyby ktoś robił naprawdę realistyczną grafikę + różne efekty graficzne. Do tego dochodzi jeszcze to, że wirtualny świat musiałby zawierać bardzo dużo różnych detali, aby to ładowanie grafiki zrobiło jakąś różnicę. To oczwiście tylko mój punkt widzenia :)

[Platyna]

To zależy czy zależy ci na zmniejszeniu rozmiaru zasobów czy czasu ich wczytywania.

 

EDIT:

Stfu, przeczytałem "najlepszym" zamiast "najszybszym" :P

[PsichiX]

najszybszym dla ładowania tak, jeszcze szybciej na przyklad bylo by dac pliki RAW i je bezposrednio ladowac do karty graficznej, ominie sie wszelkie konwersje przez procesor, no ale GM na nieszczescie na to nie pozwala

[Bedi]

A jeżeli by przez jakiś DLL czy inne cudo ładować obrazy w formacie RAW do karty, a następnie za pomocą jakiegoś wynalazku Snake'a przerzucić je do GMa, dałoby radę ? :D

[PsichiX]

jasne. w sumie wlasnie taka dllke robie, a moglbym zrobic druga z takim ficzerem z teksturami XET (bo ma opcje z pixelami formatu surowego) i by ladowalo szybko do karty, pytanie tylko czy obejscie takie nie bylo by wolniejsze bo musial bym pierw tworzyc pustego sprajta o danej wielkosci (czego sie nie da zrobic, trzeba bylo by napisac wlasna implementacje add_sprite(), a to sporo roboty).

ewentualnie mozna by uzyc tej dllki co robie ale ona ma swoj rendering wiec trzeba by napisac wlasne funkcje na sprajty itp.

tak czy siak w GMie ladowanie to zmora, pozostac lepiej przy bmp

[Snake]

@YXE: Tylko, że jak te pliki będą pofragmentowane (im większy plik tym większa na to szansa) i w dodatku ładowane z jakiegoś wolnego nośnika to może być dokładnie odwrotnie :P I dlatego przydała by się tu wielowątkowość, podczas gdy dysk by był zajęty wczytywaniem (czy zapisywaniem) danych, procek mógłby się zająć czymś innym.