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
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.
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.
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
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
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
¡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
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
Cita de: "Loover"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)
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.
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
Cita de: "TheAzazel"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
¿los blits a surfaces? Pero sólo se harán aquellos en los que haya cambios. ¿Qué puede haber más óptimo?
eso es lo que intento hacer!
CitarDespué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?
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
Cita de: "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.
Pos na, we will see
25fps en un 700 es demasiado poco. Hay muchísimos juegos isométricos (mayormente RTS) que tiran en 90mhz (por ejemplo, Starcraft), y tienen mas "movilidad" en sus escenarios, así que alguna forma habrá :P
Yo necesito que tire a 30fps en un 400mhz, así que tengo que optimizarlo :P
Por cierto, 2.4ghz será gama baja para id software pero no todo el mundo puede cambiarse de pc cada dos dias eh?
P.D. si que uso alpha blending. bastante :P
Bueno..el starcraft funcionar en un P90 funcionaba pero.... en cuanto hacias unas pocas unidades eso iba lento... yo jugaba en un P233MMX y cuando la cosa se ponia muy muy fea se notaban los tirones.
Si usas mucho alpha blending.. tendras q utilizar superficies en RAM... por narices, ya les vale a los fabricantes de graficas (grrr)
Bueno y q hay del sistema q te dije antes? ese q los objetos unos a otros se "comunican" cuando se debe realizar un volcado? yo lo veo bastante sencillo d implementar y te aseguras q siempre dibujaras los graficos implicados.
No creas q soy de Id (jajaja), ni vendo hardware, tambien soy un "maniaco" de las optimizaciones porque en mi antiguo P233MMX hacia volar un juego a varios cientos de fps a base de pegarme con ASM y MMX aunq ahora con tanto MHZ pienso q optimizar si, pero si y solo si es necesario, el tiempo q se pierde es mucho y anda q no hay cosas q investigar. Aunq si pretendes que funcione en un equipo de esas caracteristicas...si vas a necesitar alguna tecnica... a ver si usando el metodo de los rectangulos o el de comunicacion entre objetos u otro q descubras lo logras...
un saludo y a por el toro!!!
:P
jeje, siempre se me olvida algo ;), el starcraft iba a 640x480 y 8bits... y me imagino q tu como minimo sera eso pero usando 16bits no? para q lo tengas tambien en cuenta, cuando pueda usare el FRAPS para medir los fps del starcraft en el P233MMX q te comente... y te dare cifras concretas.
Ah, otra cosa, yo no uso DDraw... aunq me imagino q tendra soporte para realizar bliteos con alpha blending usando MMX..si no... avisa q en eso si te puedo echar un cable
lo diso, talugooo
Bueno, después de hacer lo que dijo haddd, ha pasado de estar entre 75-100 fps a 200-250, así que creo que prueba superada :D
gracias a todos
No entiendo cómo es que tienes que pintar sólo los tiles con cambios, y más aún para un mapa que cabe en la pantalla sin scroll.
Yo he programado mi primer juego de perspectiva isométrica y scroll a 800x600 con blitzbasic que funciona sobre DirectX: cada frame pinto todos los tiles y objetos (sólo los que aparecerán dentro de de la zona de pantalla) sobre el backbuffer por orden de profundidad, luego el flip, el código de control del juego, y luego se repite todo, y va como una moto.
Exacto Colson. Para cada objeto que dibujes, comprueba con una lista de rectángulos de modificación y haz clipping. Sólo se redibujará lo que hayas marcado antes como zona modificable.
Cita de: "Tyrell"No entiendo cómo es que tienes que pintar sólo los tiles con cambios, y más aún para un mapa que cabe en la pantalla sin scroll.
Yo he programado mi primer juego de perspectiva isométrica y scroll a 800x600 con blitzbasic que funciona sobre DirectX: cada frame pinto todos los tiles y objetos (sólo los que aparecerán dentro de de la zona de pantalla) sobre el backbuffer por orden de profundidad, luego el flip, el código de control del juego, y luego se repite todo, y va como una moto.
Bueno, el juego no es sólo pintar tiles, también otras cosas, y prefiero tener bien optimizada esa parte para dejar espacio a las otras. Además, el juego está programado enteramente en python así que algo más lento que la mayoría de lenguajes compilados.
Por cierto, cuántos fps es "como una moto" ?
Creo que Blitz Basic funciona como máximo a 60FPS ¿Cierto?
Bueno, pues el juego terminado, con scroll, interface, I.A., efectos y música en marcha me rula a 60 fps, y la verdad es que tampoco lo optimicé mucho.
La verdad es que no sé si blitz tiene un límite de fps. De todos modos a partir de cierto numero de fps supongo que da igual ese número que 670 fps. No?
60fps en qué pc? En mi 2.4GHz yo tenía 100fps, aunque ya he dicho que el target pc es un 400.
haddd, parece qe estas bastante confundido con respecto a blitz3d. He visto ya varios post tuyos comentando cosas qe no son. Hace cuanto lo probastes?
qe sepa, blitz no tiene limite de frames, es un simple programa directx7 y como cualqier otro, depende enteramente de tu PC.
y esto en que es?? directdraw o direct3d con los sprites?
Um ... y cuándo dices que enseñaras algo ? XD
cuando haya algo que enseñar :P