GameMaker Italia Forum

Torno con questioni di ottimizzazione:
se c'è uno script che deve essere chiamato in oggetti tutti figli di un oggetto avente date variabili, e devo usare quelle variabili nello script (esempio: width, height) è più efficiente far riferimento alle variabili esistenti oppure passarle come argomento della funzione?
Intendo: vs

Anche se facesse differenza, si tratterebbe di tempi trascurabili. In genere ti conviene passare le variabili come argomento, in quanto ti svincoli dal dover chiamare necessariamente lo script in un oggetto in cui quelle variabili sono definite. In questo modo, lo script risulterà riutilizzabile anche in altri contesti a cui magari non avevi pensato inizialmente.

Si tratta di scripts che vengono sicuramente chiamati su oggetti che hanno parent comune e quindi hanno per certo quelle variabili

Barnack ha scritto:Si tratta di scripts che vengono sicuramente chiamati su oggetti che hanno parent comune e quindi hanno per certo quelle variabili

Penso si tratti di un dettaglio trascurabile (stando a quello che ho studiato).

In base alla mia esperienza, le cose che possono causare rallentamenti in Game Maker sono le seguenti:
- Funzioni contenenti cicli (andrebbero analizzate caso per caso).
- Chiamate a funzioni "pesanti" di Game Maker.
- Effetti particelle (sono lenti da disegnare).
- Se il livello è realizzato con le tile, più la view inquadra una porzione grande della room, più aumenta il numero di tile che devono essere disegnate, e questo potrebbe causare rallentamenti.
- Troppe istanze possono risultare pesanti da disegnare. Se le istanze sono invisibili, no problema. Ma, se si mettono degli eventi collision, si attiva il test delle collisioni, e questo può rallentare il gioco se le istanze con eventi collision sono tante.
- In generale, se ci sono tante istanze con codice (es. nell'evento Step), quel codice verrà eseguito per tutte le istanze nella room. Quindi bisogna fare in modo che questo codice sia performante.
(magari mi dimentico qualcosa)

Per quanto riguarda la 3D, d3d_model_draw ad esempio è pesante. A parità di numero di poligoni, è più conveniente disegnare meno modelli composti da tanti poligoni piuttosto che tanti modelli composti da pochi poligoni (testato).

Nota: Game Maker studio è più veloce, in quanto il codice viene compilato, non interpretato (testato anche questo!).

Alv ha scritto:Una nota: Game Maker studio è più veloce in quanto il codice viene compilato, non interpretato! (testato anche questo)

Questo è un dato di fatto vero per qualsiasi software, non c'è neanche da testarlo altrimenti perché Java farebbe schifo a prescindere?

Quelli che mi sto ponendo ora sono problemi di micro-ottimizzazione, alleggerire ogni dettaglio possibile. (è per la "libreria" di gui che sto facendo, voglio ottenere le massime performances possibili, ed è anche il motivo per cui ci sto mettendo molto, ma voglio dare il meglio)

Uhm... non so in GM, ma se fosse in ANSI C posso rispondere.
Nel caso di funzione con gli argomenti dovresti:
- accedere alla memoria per leggere il valore delle variabili 8per usarli come parametri
- pusharli nello stack della function
- accedere al push dello stack della funzione quando li usi nella function

nel caso di argomenti non passati, e di utilizzo di variabili del tuo oggetto
- accedere alla memoria per leggere il valore per usarli dentro i calcoli della funzione

Quindi direi che è "meglio" il secondo caso. AMMESSO che tu li usi solo una volta dentro la funzione (altrimenti bisognerebbe capire se è più rapido l'accesso allo stack o più rapido l'accesso alle variabili).

CMQ: questa NON è ottimizzazione, è disquisizione filosofica. Non stai scrivendo un driver o altro codice di bassissimo livello, e almeno che tu non sappia di implementare un algoritmo con complessità fattoriale (o comunque molto alta) l'effetto finale sarebbe totalmente trascurabile.
Questi problemi sono importanti per chi implementa un compilatore ad esempio.