optymalizacja gry

[smartboy]

Robie od czasu do czasu mojego gniota pseudo 3D i gdy w roomie mam więcej elementów to mi strasznie FPS spada.W roomie mam tylko obiekty np trawa,chodnik i budynku pseudo 3D jako czworokąt.

Teraz moje prymitywne wnioski,wnioski człowieka,który chce zrobić prostą gre z zamiłowania do GM ale mało czasu mu poświęcam,bo jestem starym koniem.

Ogólnie optymalizację mogę uzależnić od kamery.

1.gdy dystans jest większy niż ileś tam od kamery visible=0 (to nic nie daje,nie wpływa na FPS)

2.obiekty w roomie,bardziej się opłaca zrobić np trawnik powiedzmy boisko w jednym kawałku niż nakładać w roomie obiekty trawy po 128 x 128

3.dezaktywacja i aktywacja,tego nie ogarniam,byłem na jakiś tam dystans i się obiekty poza zasięgiem dezaktywowały ale jak się zbliżyłem to nie wróciły

To moje głupie wnioski,moze wy macie jakieś rady,żeby dobrze zoptymalizować ten projekt.Czekam na wasze uwagi wynikające z doświadczenia. :D

[Threef]

1. visible wyłącza tylko event draw w obiekcie. Cały kod w step, kolizje i wszystko inne wciąż jest przetwarzane, więc nie jest to dobre rozwiązanie.

2. Wszystko zależy. Warto dzielić wielkie obiekty na kilka po to aby móc je dezaktywować, ale jak zrobisz łąkę i każde źdźbło będzie obiektem to będzie to bardzo nie optymalne bo obiekty w GM mają za dużo własnych wbudowanych właściwości. Nie zdziwiłbym się gdyby każdy obiekt co step poruszał się o speed nawet gdy ten jest równy 0.

3. Kod aktywacji miałeś w dezaktywowanym obiekcie. Jeżeli obiekt jest dezaktywowany to nie wykonuje eventów, jeżeli nie wykonuje eventów to nie może sprawdzić warunków i się ponownie aktywować. Najlepiej robić 1 obiekt kontrolujący aktywację/dezaktywację (może ty być np gracz).

 

I gratis:

4. 3D nigdy nie będzie optymalne w GM.

[szmalu]

Co do tego ostatniego, to on mówi że to pseudo 3d, pamiętasz te jego screeny? Więc takie coś przejdzie w GM

[gnysek]

2. Wszystko zależy. Warto dzielić wielkie obiekty na kilka po to aby móc je dezaktywować, ale jak zrobisz łąkę i każde źdźbło będzie obiektem to będzie to bardzo nie optymalne bo obiekty w GM mają za dużo własnych wbudowanych właściwości. Nie zdziwiłbym się gdyby każdy obiekt co step poruszał się o speed nawet gdy ten jest równy 0.

 

Zdecydowanie masz rację. Jeśli vspeed i hspeed są wyliczane wcześniej, to dodanie ifa sprawdzającego czy speed > 0 zajęłoby tyle samo czasu, co dodanie do x i y wartości hspeed i vspeed (mówimy o kodzie maszynowym, czyli CMP+JMP vs. 2x ADD)