2013-01-23 9 views
5

Sto realizzando un gioco 2D in XNA. Quando si utilizzano componenti di gioco estraibili, quale è meglio per le prestazioni?Come evitare di disegnare componenti XNA quando è fuori dallo schermo?

1. Quando un componente non si trova sullo schermo, rimuoverlo dall'elenco dei componenti e quando viene aggiunto sullo schermo.

2. Quando i suoi fuori campo Dont Run sua funzione draw (utilizzando un "sveglio" bool campo e un if intorno tutto in funzione di disegno)

sto usando il metodo 2 in questo momento ed è funziona bene. La sua comoda manina il mazzo di componenti non cambierà (se rimuoverò e riaggiungerli lo farà, e avrò bisogno di più codice per gestirlo) In realtà mi è appena venuto in mente che se non è nella lista dei componenti aggiornamento e ho bisogno di qualcos'altro per tenere traccia di se è sullo schermo o no ..

Anche io non ho la versione di fantasia di Visual Studio con il profiler, quindi sto solo chiedendo qui cosa pensa la gente dalla loro esperienza

+1

Non è necessario un profiler costoso per determinare quale sia più veloce in un test "Cronometro" è abbastanza buono per quello. Il profiler aiuterà a spiegare * perché * uno è più veloce dell'altro (vale a dire, quali parti di questo algoritmo sono lente, cosa consuma più memoria, devo preoccuparmi di ottimizzare questa sezione, ecc.). – Servy

+2

Vorrei credere che la scelta 2 sarebbe più veloce. – Cyral

+2

Quanti 'DrawableGameComponent's usi? Se ne stai usando molte, probabilmente lo stai usando male. –

risposta

5

Un concetto a volte trascurato delle prestazioni della CPU durante l'utilizzo di SpriteBatch è il modo in cui si esegue il batching degli sprite. E l'uso di componenti di gioco disegnabili non si presta facilmente a creare sprite in modo efficiente.

Fondamentalmente, la GPU che disegna gli sprite non è lenta & la CPU che organizza tutti gli sprite in un batch non è lenta. La parte lenta è quando la CPU deve comunicare alla GPU ciò che deve disegnare (inviandogli le informazioni sul lotto). Questa comunicazione da CPU a GPU non si verifica quando si chiama spriteBatch.Draw(). Succede quando chiami spriteBatch.End(). Quindi il basso apporto di frutta all'efficienza chiama meno spriteBatch.End(). (ovviamente questo significa chiamare Begin() anche meno spesso). Inoltre, usa spriteSortMode.Imediate con molta parsimonia perché fa immediatamente in modo che la CPU invii ciascuna informazione sprite alla GPU (lenta)).

Quindi, se chiami Begin() & End() in ogni classe di componente di gioco e hai molti componenti, ti stai facendo perdere un sacco di tempo inutilmente e probabilmente risparmierai più tempo con uno schema di batch migliore di preoccuparsi degli sprites fuori schermo.

A parte: la GPU ignora automaticamente gli sprite offscreen dal suo pixel shader. Quindi, l'eliminazione degli sprites su schermo nella CPU non salverà il tempo della GPU ...

+0

Grazie mille! molto informativo .. Inoltre, solo fyi, il mio gioco ha livelli generati proceduralmente di stanze. Ho fatto uno stress test con 140 stanze prima di avere qualcosa di codificato per le prestazioni ed è stato hellah lento.Poi l'ho fatto in modo che solo la stanza in cui sei attualmente sia disegnata (metodo 2 nel mio post) E le prestazioni sono tornate perfette, alla luce della tua risposta che era tutta la CPU, il che ha senso quando è in esecuzione su un craptop che lotta con lo studio visivo! :) Penso che seguirò il tuo consiglio e re-architetto un po 'per rendere le mie dichiarazioni di inizio e fine tenere molto di più –

+0

Mi piacerebbe dire che solo perché stai usando drawablegamecomponents, ciò non significa che non puoi usa lo stesso spritebatch.begin(). Se posizioni il tuo base.draw nello spritebatch, puoi chiamare il file di gioco principale, quindi eseguire tutto il disegno nei componenti, quindi spritebatch.end nel file di gioco. – TopHatHacker

+0

@TopHatHacker Ho pensato di menzionarlo, ma non l'ho fatto quando ho capito che se ci sono alcuni componenti 3D disegnabili e alcuni componenti 2D, allora non funzionerebbe. –