2012-01-18 11 views
9

Sono completamente nuovo in OpenGL, quindi scusa se si tratta di una domanda stupida. Inoltre non ho idea se faccia la differenza, nel caso, sto usando OpenGL ES 1.1.OpenGL ES 2D - ordinamento z, buffer di profondità e disegno nell'ordine

Attualmente sto disegnando sprite in ordine di texture, come ho letto è meglio per le prestazioni (ha senso). Ma ora mi chiedo se sia stato l'approccio giusto perché ho bisogno che certi sprite siano di fronte agli altri, indipendentemente dalla trama.

Per quanto ne so, le mie opzioni per l'ordine z potrebbero essere quelle di abilitare il buffer di profondità e utilizzarlo oppure di cambiare l'ordine di disegno in modo che gli sprite siano disegnati nell'ordine di un valore z.

Ho letto che il buffer di profondità può essere un colpo di prestazioni, ma così cambierebbe l'ordine. Quale dovrei fare?

+1

Poiché ogni applicazione OpenGL ragionevole utilizza il depth-buffer (eccetto forse un semplice "disegnare un singolo 2D-texture" -esempio), immagino che dovresti relativizzare un po 'questa affermazione "performance hit" (se anche vera) . –

+0

Un'opzione è quella di spostare lateralmente l'intero problema e utilizzare un framework come Cocos2D. Ti porterà via il peso di OpenGL. Supporta lo z-ordering degli sprite e può riutilizzare le trame con gli sprite usando CCSpriteBatchNode. (Non c'è modo di intercalare le legature di texture in batch e le variazioni di ordine z, però.) –

+0

Sto facendo il gioco più per l'apprendimento di qualsiasi altra cosa, quindi ho deciso di iniziare da zero – Dan2552

risposta

9

La risposta breve è, ordina gli sprite.

Sembra che tu stia creando qualcosa che è realmente basato su 2d, e mentre uno z-buffer può essere uno strumento molto utile, può essere un notevole risultato in termini di prestazioni se l'hardware non lo supporta, e se tu " in realtà non usando oggetti 3d che possono intersecarsi tra loro, non ha molto senso per me.

Inoltre, se si dispone di sprite parzialmente trasparenti, ovvero con pixel con un valore alfa diverso da 0 o 255 (o 0,0 o 1,0 se si utilizza il virgola mobile), occorre comunque ordinare.

Come nota a margine, credo che le prestazioni perse quando si cambiano gli "sprite" si verifica solo quando si sostituiscono le superfici e solo raramente. Un modo per mitigare questo problema consiste nel mettere tanti sprite diversi in una sola immagine, su una griglia, e utilizzare piccoli pezzi delle superfici come sprite.

+0

Poiché OpenGL è principalmente destinato al 3D (anche ES), Suppongo che un hardware che non supporta un buffer di profondità dell'hardware, beh, non supporti l'OpenGL ES accelerato dall'hardware, vero? –

+0

Non penso che nessun dispositivo iOS non lo supporti (potrei sbagliarmi, immagino). Hai sollevato comunque un buon punto, perché si tratta di un gioco basato su tessere, tutte le tessere si troveranno in una singola mappa tilografica - per questo motivo, il rendering nel problema dell'ordine non dovrebbe influire su di esso? – Dan2552

+0

Esatto, il problema di velocità a cui si fa riferimento quando si passa da una superficie all'altra si applica solo quando si cambia l'immagine dalla quale si sta lavorando. In realtà è solo un problema quando si esaurisce anche la memoria video. Il vero problema è quando opengl esaurisce lo spazio e deve scaricare le immagini dalla memoria video, quindi caricare nuove immagini. –

Problemi correlati