Qué forma de dibujo es más optimo para la librería...

[Hechelion]

Cumpliendo la agenda, me encuentro nuevamente avanzando sobre Dhu Nun y dentro de este proceso me encuentro optimizando el mapa y quería consultar algunas cosas para tratar de mejorar el rendimiento.

¿Qué es mejor para la librería, pasarle todas las llamadas agrupadas por imagen de origen, o pasarle las llamadas de dibujo agrupados por canal Z?, por si no ha quedado claro, me explico con un ejemplo.

Vamos a suponer que tengo 2 PNG, que cargo como imagen "A" e imagen "B", con estas 2 imágenes pinto el escenario, el cual tiene 3 planos de profundidad (canal Z) que llamare 2, 1 y 0, y supongamos que en cada canal voy a usar partes de la imagen A y partes de la imagen B.

¿Qué sería más óptimo para la librería?
Pasar cada llamado de dibujo para A y luego para B, de la siguiente manera: A2, A1, A0, B2, B1 y B0

o

Pasar cada llamado de dibujo por canal Z independiente de que imagen venga: A2, B2, A1, B1, A0 y B0

Por lo que recuerdo de leer en diferentes post, me parece que lo más óptimo sería la primera opción, pero me gustaría confirmarlo antes de rearmar esta parte del juego, que por cierto, sigue avanzando y espero luego poder liberar algunas mejoras en varias herramientas que estoy utilizando, como una nueva clase para generar partículas, un editor de animaciones bastante más avanzado que el actual (permite animaciones tipo muñeco de papel con diferentes niveles de profundidad) y una versión nueva del editor y clase de mapas de tiles.

Por último, si conocen algún consejo sobre como mejorar la optimización serán bienvenidos, aunque tengo claro que la optimización es todo un mundo y depende en buena medida de cada programa, a saber si hay algún consejo de tipo general, como por ejemplo agrupar las llamadas de dibujo por imagen o por canal Z, etc.

[[EX3]]

Si no he entendido mal (disculpame que ando algo espeso estos dias xD) la pregunta es si te merece mas la pena dibujar todas las llamadas de dibujo referentes a una misma textura (entiendo que un tileset) o agruparlas por llamada de profundidad (su coordenada z).

Respondiendo a lo facil, el tema de la coordenada Z no deberia preocuparte ya que dx_lib32 lo que hace es generar una lista de llamadas y parametros cada vez que llamas a cualquiera de las funciones de dibujo y este organiza toda esa informacion en lo que vendria a ser un arbol donde cada rama es un nivel de Z. Esto significa que hasta que no llamas a la funcion Frame() no se procesa toda esta cola de parametros en el render interno de la libreria. El render luego tiene mecanismos para optimizar ligeramente algunas funciones como son evitar redundancias a la hora de seleccionar texturas si se va a dibujar la misma consecutivamente (no realiza la operacion de seteo de textura en la tarjeta si esta ya esta seleccionada) y esto tambien se aplica al sistema de RenderStates y similares que usa dx_lib32 para los filtros de efecto y demas. El resto es pintar consecutivamente cada rama del arbol desde Z +8 a Z -8. El dia que libere el codigo de la libreria vais a flipar un poco por como esta montado este sistema que hoy dia he visto que podria hacer de otra forma algo mas sencilla y legible en codigo xD

Sobre el otro tema. Si contamos que dibujas en la misma Z (la capa de tiles que forman las plataformas del juego por ejemplo) y estas pertencen todas a una o un par de tilesets (y no a chorrocientas texturas sueltas) pues eso evitaria lo que comentaba antes en el render de la libreria, cambios innecesarios de textura a la hora de dibujar ya que la textura seria la misma en la mayoria de las llamadas y eso deberia evitar perdida de rendimiento.

Esta claro que estas buenas practicas de optimizacion, dentro de lo bien o mal que haya programado yo la libreria por dentro, se notaran si la carga de dibujo es muy elevada, que seguramente en un juego como el tuyo se da el caso :)

Salu2...

[Hechelion]

Discúlpame a mi, por no usar los términos técnicos correctos.

Efectivamente hablamos de texturas y por lo que he entendido, la librería los agrupa y "ordena" por Z, pero no hace ninguna otra gestión, o en otras palabras, si yo hago las llamadas a Draw en el siguiente orden:

EJEMPLO 1
Orden de ejecución en el programa
Img_A con Z0, Img_B con Z1, Img_A con Z0

Ejecución en la librería.
Img_B con Z1, Img_A con Z0, Img_A con Z0 (óptimo)


EJEMPLO 2
Orden de ejecución en el programa
Img_A con Z0, Img_B con Z0, Img_A con Z0

Ejecución en la librería.
Img_A con Z0, Img_B con Z0, Img_A con Z0 (NO óptimo)

EJEMPLO 3
Orden de ejecución en el programa
Img_B con Z0, Img_A con Z0, Img_A con Z0

Ejecución en la librería.
Img_B con Z0, Img_A con Z0, Img_A con Z0 (óptimo)


Para que no queden dudas, en el ejemplo 1, por la forma de trabajo de la libreŕia, el resultado sería el más óptimo, en el caso 2, no, por lo cual mi trabajo como programador sería reordenar las llamadas a Draw para que quedaran como en el ejemplo 3 que sería el más óptimo.


Otra pregunta, ¿como se calcularía la memoria de GPU usada al cargar texturas?, si por ejemplo, cargo un PNG de 1024*1024 que pesa 300K, en memoria (asumo que se carga en la memoria de tarjeta gráfica, a la cual por abreviar y comodidad le diré genéricamente GPU), me consume 300KB o me consume el equivalente a 1024*1024*4 = 4MB.


Como comentario aparte, la librería es bastante liviana y me ha funcionado bastante bien, pero como estoy complicando algunas partes de la lógica (como las animaciones) quiero reducir al mínimo el costo de otras áreas, como el dibujo, en la versión 0.1.0 que liberé la otra vez, usaba cerca de 10 capas que en promedio deberían superar las 1000 llamadas Draw por ciclo de programa (solo en el pintado del escenario), ahora estoy reorganizando los gráficos para reducir el número de capas por nivel a unos 5 o 6 y de esa forma puedo agregar tranquilamente un control más complejo en las animaciones o meter partículas y que el juego siga corriendo en un equipo pequeño, como era la meta desde el inicio, a ver si ahora que libere la versión 0.2.0 lo pruebas, yo esperaría que corriera incluso en tu antiguo MAC.

[[EX3]]

Efectivamente hablamos de texturas y por lo que he entendido, la librería los agrupa y "ordena" por Z, pero no hace ninguna otra gestión

Correcto :) La verdad, si existe forma logica de por programacion reagrupar llamadas por textura y respetando el orden de llamada por Z lo desconozco pero asi de primeras me resulta algo imposible.

Otra pregunta, ¿como se calcularía la memoria de GPU usada al cargar texturas?, si por ejemplo, cargo un PNG de 1024*1024 que pesa 300K, en memoria (asumo que se carga en la memoria de tarjeta gráfica, a la cual por abreviar y comodidad le diré genéricamente GPU), me consume 300KB o me consume el equivalente a 1024*1024*4 = 4MB.

Sinceramente, no recuerdo bien como funciona esto en la memoria de la tarjeta pero puedes comprobar, que yo recuerde ahora de cabeza, el temaño individual de cada textura en un campo de la estructura GFX_Info, y en total, con la funcion de dx_GFX_Class que devolvia memoria en uso y memoria total, todo esto son mecanismos propios de Direct3D por lo que deberian ser fiables supongo :)

Como comentario aparte, la librería es bastante liviana y me ha funcionado bastante bien, pero como estoy complicando algunas partes de la lógica (como las animaciones) quiero reducir al mínimo el costo de otras áreas, como el dibujo

La verdad que el render grafico podria ir muchisimo mas ligero, sinceramete, hay muchas chapuzas que se podrian haber implementado mejor y eso se notaria en rendimiento al meterle caña a la libreria. Yo en verdad, donde he tenido mas problemas de rendimiento en mis ultimos desarrollos ha sido con el calculo de colisiones principalmente (mi motor de fisicas colisiones era una chapuza del quince, todo sea dicho :P).

yo esperaría que corriera incluso en tu antiguo MAC.

En el Macbook con Dual 2 Core a 2.2 y la Intel GMA 950 va a correr sobradamente ya que la libreria no exige mucho de la grafica (mi problema en el otro post iba en relacion a XNA que si exige mas ya que es mas dependiente de la GPU), incluso en el miniportatil que tengo la ultima version del TLSA.Engine en VB6.0 (donde se desarrollo practicamente) iba sobrado con un Intel Atom 1.6 y la Intel GMA 950, yo no me preocuparia demasiado :)

Salu2...