Skocz do zawartości

Wydajność i Optymalizacja w grach


krzysio664

Wydajność i Optymalizacja w grach  

23 użytkowników zagłosowało

  1. 1. Jaką metodę optymalizacji używasz?

    • Wszystko do .exe + deactivate
      3
    • Wczytywanie zasobów z plików
      9
    • Edytor map który zapisuje dany level w jeden plik
      2
    • Zapisanie levela lub mapy w kafle
      0
    • Optymalizacja kodu
      9


Rekomendowane odpowiedzi

bez "Długich rozpisków"

co to znaczy?

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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ęć.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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?

Odnośnik do komentarza
Udostępnij na innych stronach

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

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

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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.

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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 :)

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

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

Odnośnik do komentarza
Udostępnij na innych stronach

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się
  • Ostatnio przeglądający   0 użytkowników

    • Brak zarejestrowanych użytkowników przeglądających tę stronę.
×
×
  • Dodaj nową pozycję...