Optimizar El Renderizado De Un Motor Isométrico

[CoLSoN2]

 Estoy haciendo un juego 2D isométrico pero todavía no me había parado a optimizarlo, y con no muchas cosas en el escenario ya baja de 100fps (en un P42.4GHZ con 768MB de RAM..) y quería ver como optimizarlo un poco.
El escenario tiene gráficamente forma de rombo de NxN celdas. Hay 2 tipos de tiles: estáticas (muros y demás) y dinámicas (personaje y enemigos). Esta última es la única que puede moverse. Sin embargo las otras también pueden cambiar visualmente, ya sea porque están animadas o porque los muros, al haver una entidad dinamica detrás, se ponen medio en alpha y con una imagen distinta (más baja) para ver mejor al personaje de atrás.
Lo tengo montado como una lista de sprites ordenada, cada uno con su campo image (lo que bliteo), rect (la zona de pantalla que actualizo) y dirty (indica si ha cambiado o no desde el ultimo render).
Mayormente el problema es que unos se superponen a otros y demás. Entonces he hecho algunos métodos para los sprites como isBehind o isBeyond que indican si la entidad cuyas coordenadas se pasan como parámetro es tapada por el sprite, o al revés.
Es más que nada para saber si para cada entidad estática, los personajes que faltan por blitear, tengo que renderizarlos antes o después (para que lo tape o no) que la entidad actual.

No sé si me he explicado. A ver si alguien tiene alguna sugerencia brillante sobre cómo montarlo un poco todo, porque siempre acabo con poco rendimiento o con parpadeos, cosas que desaparecen y demás xDD

Edit: por cierto, también tengo el problema de que el cursor del ratón al pasar me borra todo lo que no renderizo en ese frame, y hacer listeners a todas las entidades para ver si al moverse colisiona con ella o algo me parece muy bruto no? XD

[Tyrell]

 Simplemente hay que renderizarlos por orden de profundidad: primero fila a fila y luego nivel a nivel. Así no hace falta detectar ninguna colisión.

Tyrell.

[CoLSoN2]

 ya lo hago. pero sólo quiero renderizar los que se hayan actualizado. y partiendo de esta base, si renderizo alguno que esté detrás de otro que no se renderiza, éste se superpondrá, y obviamente no quiero eso.

[Loover]

 Pues no se me ocurren sino las cosas más obvias que fijo que ya has tenido en cuenta, pero bueno:

A ) Si no se mueve ninguna unidad móvil, no se redibuja nada (a no ser que ocurra B )

B ) No se mueve ningún móvil, pero se mueve el ratón: dibujamos las unidades (estáticas) encima de las cuales pasa el ratón y a este mismo tb. Para no hacer muchas comprobaciones (aunque la verdad, si tenemos 12x12 tiles y unos 4 objetos como máximo (tile suelo, pared y 3 cosas colgando de ella = 720 objetos estáticos + unos 10 móviles = 730. 730 en el peor caso, que no se cumplirá nunca. La media rondará menos de la mitad, los 250 / 300; pues tampoco son demasiadas para hacerlas frame a frame) aunque siempre puedes dividir la pantalla en sectores, cada uno con una lista o vector de unidades, ver en que sector se encuentra el ratón y hacer solo con esos la comprobación.

C ) Se mueven solos algunas unidades, otras no. Bueno, este es el caso mas complejo, pero creo que podría resolverse tb con sectores, ver en que sectores está esta unidad móvil y redibujar solo esos en cuestión haciendo las comprobaciones necesarias por si cierto objeto de ese sector no necesita redibujarse porque no está ni delante ni detrás del móvil.

D ) Se mueven algunas unidades y además el ratón. Vamos, el 99,9% de las veces. Pues más sectores, tanto para el ratón como para las unidades. Usar B + C

Resumen: ¡sectores!

Un saludo Colson! ¡ Y sigue currando tan duro como hasta ahora campeón ! :D

[CoLSoN2]

 si por sector te refieres a un rectangulo, es lo que hago. Lo que quiero tener bien hecho es como bien dices, el peor caso XD osea varias cosas moviendose de sitio, animandose, el raton pululando, etc.
El problema es que si un objeto cambia y tiene que renderizarse:
afecta a los que tenga detrás, ya que no es todo opaco , tiene zonas alfa que ocupa el de atrás, y si no renderizo este se ve un vacio y por lo tanto un agujero en el objeto de atrás.
También afecta a lo de alante porque si renderizo un objeto que está detrás y no el de delante, el de atrás se superpone y no puede ocurrir eso. También si un objeto cambia de sitio tengo que pintar y actualizar todo lo que está tanto en el anterior rect/sector como en el nuevo. También todo lo que toque el bitmap del cursor (antiguo y nuevo). Por lo que, si quiero hacerlo bien tengo que tener un buen puñado de listas y hacer mil iteraciones, pero prefiero eso a tener glitches o blittear cosas innecesariamente

[Loover]

 Sector = rectángulo sí, pero no el rectángulo que rodea a la unidad. Me refiero a dividir la pantallas en NxN sectores rectangulares, dentro de las cuales hay X unidades (o x casillas de rombo). Y solo redibujar los sectores en las que una unidad se haya movido. Si es lo que ya haces, realmente no sé que más puedes optimizar :D.

Porque en el peor caso, sería que en cada uno de los sectores hubiese una unidad moviéndose, pero vamos, eso no ocurrirá nunca, o casi nunca.

Si divides el mapa en... yo que se, 20x10 trozos o lo que sea. Y hay 5 enemigos. Lo mismo 3 de ellos están en un mismo sector y el ratón en otra... luego tenemos: 2 unidades+ 1 (3 en esta) + 1 raton... solo hay que redibujar 4 sectores. Y ni siquiera los sectores enteros, pq mirarás dentro y harás comprobaciones pues puede que objetos de esos sectores no se vean afectados por la unidad móvil.

Repito, si ya lo haces así... no sé que más quieres optimizar :D

[Haddd]

 ¡Yo no haría nada! Si haces scroll, aunque sólo sea un pixel, ya cambia todo, y un juego de tiles, normalmente, está haciendo scroll! Así que el caso más común en un 95% es que todo se tenga que redibujar.

Por tanto, optimiza otras cosas, como por ejemplo los accesos a los VertexBuffer, si es que haces, o cambios de State y de textura

[CoLSoN2]

 Uso 2D "puro": surfaces y demás. Así que no hay switch de Vertexbuffers ni texturas, sólo blits que tengo que ahorrar, y eso es lo que intento xD
además, este es un juego isométrico pero el mapa no scrollea, se ve todo entero, así que por suerte no tengo ese problema xD

[CoLSoN2]

Repito, si ya lo haces así... no sé que más quieres optimizar :D

no lo hago así, yo manejo rect's que envuelven a los objetos. Pero hay el mismo problema con tu sistema. Si los sectores son pequeños, casi todo objeto ocupará más de un sector y por lo tanto sigo teniendo que redibujar los de atrás y adelanate para que se vea bien. Y si son muy grandes no me sale a cuenta porque para redibujar un objeto necesito redibujar todo el sector al que pertenece (sin contar que pertenezca a dos sectores)

[Haddd]

 Es decir, que utilizas mapas isométricos fijos y los tiles pueden ser transparentes. Bien, pues que más da que sea isométrico, utiliza rectángulos, porque al final dibujas en 2D.

Mira lo que se debe modificar cada frame lo metes en una lista de rectángulos.

Después renderizas normal, pero con clipping sobre estos rectángulos y problema resuelto, sólo dibujarás lo que se modifica.

[TheAzazel]

 Buenas!
tengo un par de preguntas... utilizas DirectDraw...bien.. +-100fps... superficies en memoria de video o en RAM? que resolucion? que color? el tema, si usas la memoria de video..cuando utilizas alpha... reduces la velocidad tremendamente...pero si te da unos 100fps o bien es a baja resolucion(digamos 640x480) o creo q no se da este caso porque la cosa bajaria a unos miseros 20-30. Es una lastima que la aceleracion 3D cortara en seco el desarrollo de las caracteristicas de las aceleradoras 2D..digo yo...cuanto trabajo le costaria a nVidia,Ati y demas..incorporar soporte alpha blending por hardware? en fin...q me voy de tema :)
Si usas la memoria RAM para almacenar las superficies... la cosa no va mal y ahora es donde viene mi mayor consejo, q a base de darme  (nooo) se acaba aprendiendo: NO OPTIMIZAR NADA HASTA EL FINAL!!! ES PERDER TIEMPO!!!. Imagina por un casual q al final la cosa a lo "bruto" se queda en 80fps, pues de lujo, si a lo "bruto" con todo el juego..corre a 80fps..genial! despues...añades un control de tiempo para refrescar la pantalla cada 60fps(q ya estara muy bien y la cosa se vera suave) y te encontraras con que la CPU se arrascara la barriga en ratos tremendos...pq no es lo mismo tener que andar mandando los graficos a la tarjeta de video que realizar operaciones aritmeticas... ademas... un 2,4 en P4 es un equipo medio-bajo, para cuando termines todo el mundo tendra minimo eso o mas...asi que...para que perder tiempo optimizando algo que no esta terminado???
supongo que nadie escarmienta en cabeza ajena..pero ese es mi mejor consejo!
ya nos contaras como va el tema, un saludo y a ver cuando vemos algo!!
bye

[CoLSoN2]

un 2,4 en P4 es un equipo medio-bajo, para cuando termines todo el mundo tendra minimo eso o mas...asi que...para que perder tiempo optimizando algo que no esta terminado???
supongo que nadie escarmienta en cabeza ajena..pero ese es mi mejor consejo!

2.4 NO es un equipo medio bajo, ni de coña. Igualmente la idea es que corra bien (30fps minimo) en un 300 o 400mhz, de ahí las ganas de optimizar. Lo de no optimizar hasta el final, en cierto modo tienes razón, pero es que ya el motor está prácticamente acabado, lo demás va a ser lógica de juego y poco más, y claro, mejor dejarlo finiquitado ahora (aunque no descarto dejarlo para más adelante si me da mucha guerra).
Haddd eso sería lo fácil, lista de rects de lo que se actualiza, y renderizar todo. Así fijo que va, pero los blits a surfaces, aunque luego no se actualicen en la pantalla, también tienen un coste nada despreciable, y es eso lo que quiero evitar

[Haddd]

 ¿los blits a surfaces? Pero sólo se harán aquellos en los que haya cambios. ¿Qué puede haber más óptimo?

[CoLSoN2]

 eso es lo que intento hacer!

Después renderizas normal, pero con clipping sobre estos rectángulos y problema resuelto, sólo dibujarás lo que se modifica.

Pensaba que te referias a la hora de hacer el update de la pantalla, pasarle esa lista de rectangulos. Tu te refieres a que, para cada objeto que tenga que renderizar, renderice solo la parte de su rect que colisione con uno o mas rects de esa lista?

[TheAzazel]

 Colson2:
q hay acerca de las especificaciones q te pregunte? usas alpha blending? es que aunq parezca una tonteria... 100 fps puede ser mucho o poco depende de lo que estes haciendo.
Antes se me olvido pero...yo como Haddd tiendo a no complicarme mucho la vida...dibujaria todo de golpe y encima si esperas que corra a 25fps...lo tienes muy facil.
Dices q tu objetivo es q funcione en un 300-400mhz (perdona q sea pesado pero..quien tiene eso hoy en dia? jaja y los P4 a 2,4 para mi concepto del hardware se trata de una CPU media(y de los del medio tirando a bajo) pero es q soy muy exigente con el hardware asiq..no me hagas mucho caso ;) )
Pienso q un objetivo mas realista podria ser que funcionara a 25fps en un 700Mhz y para arriba y sigo insistiendo... termina todo y despues lo pones a correr en una maquina q cumpla tus requisitos minimos y si va bien de lujo...si no...ya puedes optimizar el sistema grafico.
Ahora...si lo que quieres es optimizar tu engine porque si.. ya me callo :lol: y si lo que quieres es terminar el juego (q no es lo mismo q el engine).. sigue pa'lante como los de alicante ;)
Por si quisieras optimizar pq si... no se como tienes implementado el volcado de cada sprite... si lo tienes como objetos que se vuelcan "solos"... no seria dificil volcar a uno cdo haya tenido movimiento y comprobando su tamaño..si se sale de su box...q mande una peticion de redibujado a un posible objeto... con este sistema te ahorras mucho volcado.
Pos na, we will see