Ejemplo de mapa tileado por procesos con scroll

[darío]

Buenas,

como ya dije, estoy haciendo pruebecillas con bennu. Entre otras estoy haciendo unas pruebas para un futuro motor de tiles con scroll. En principio lo necesito para 320x240 y 16 bbp pero puesto que es configurable se me ha ocurrido probarlo con tiles de 32x32, a 800x600 y 32bpp.

El sistema de tiles es a base de procesos, con reposicionamiento de "los que se salen de la zona visible".

Bueno, lo cuelgo por si alguien quiere hacer alguna prueba. El código no es muy elegante, pero ahí está...
http://www.dariocutillas.es/test.zip

EDIT:
Por cierto, si tarda en cargar al ejecutar es porque el mapa de tiles es de 2000x1000 tiles. Si probáis con menos veréis que tarda mucho menos en cargar.
Si se cambia __DEPTH__ a 16 en lugar de 32 se aprecia una notable mejora en el rendimiento...

[SplinterGU]

Mira estos ejemplos de scroll tileado que hice usando unos tiles de un scroll tileado (hecho por drumpi, un poco mas complejo que estos ejemplos, con listas enlazadas, procesos que se crean y mueren constantemente y otras cosas...)

Fijate que tenes 2 test, tocando un define TEST, y poniendole valor 0 o 1, probas cada uno de los mismos... tambien podes probar el vsync... la velocidad de los scrolls es bastante buena...

El ejemplo, es un ejemplo de scroll tileado con 2 capas... hay un problema con las z en las 2 capas, pero no se me pude poner a ver cual es el problema todavia... si es del ejemplo o de bennu... no lo se, cuando tenga tiempo reviso, pero es posible que sea, Bennu ya que tuve que eliminar una porcion de codigo asociado con las z, y posiblemente algo que corregi se perdio... ya lo revisare cuando tenga algo de tiempo...

No me puse a analizar tu codigo, pero no entiendo por que tarda tanto al prinicipio...

[darío]

Supongo que tarda porque son 2000 x 1000 tiles, 32bpp de profundidad (los png que puse son de 32bpp) y 800x600 y porque el mapa se crea al iniciar el programa (la información de los tiles no está predefinida como en el caso de drumpi).

De todos modos, sólo son unas pruebas. Revisaré más detenidamente el código de drumpi.

Un saludo

[SplinterGU]

No, el codigo publicado no es de drumpi... solo los tiles y la informacion del mapa... el codigo lo hice yo, muy basico, sin nada complicado, queria probar cuanto daba de performance con un codigo lo mas simple y basico posible.

[darío]

Sí, perdona, leí mal.

De todos modos quiero que el motor de tiles soporte algunas cosas como tiles animados, varias capas (un par al menos), transparencias y algunas cosillas más, por eso no puedo hacerlo "tan simple".

[SplinterGU]

los ejemplos que te pase tienen 2 capas... transparencias y animaciones no seria muy complejo... son cambiar flags y graph...

pero vamos, adelente con el experimento, lo mio era solo un ejemplo mas...

[laghengar]

Disculpad por llevar esto aquí, es el mejor sitio que he visto.

Bueno respondiendo: Yo nunca he usado mapas grandes, por eso no he tenido problemas. Una función montaba el mapa y luego un proceso funcionaba como scroll, pequeñito claro.

[Lt_Henry]

Yo hice bastantes en DIV, con un solo proceso, funcionaban bastante bien. En mi opinion, creo que es mejor que dibujes con un solo proceso. De primeras ahorras algo de memoria, y tendria logica que ademas, sea mas eficiente.

[laghengar]

Dicen que no es tan eficiente. Yo la verdad, no lo se, solo hice pruebas con un proceso que era un tipo armado y se movía por un mapa que se desplazaba y giraba. No hacía de scroll vertical ni horizontal, funcionaba como lo hacen los mapas ante una cámara de shoot'em. Eran mapas pequeños montados por tiles, pero bueno. Parece que eso se tiene que llevar a scroll y no a proceso, yo lo llevo a proceso, no se hacerlo de otra forma.

[Drumpi]

Bueno, es que depende hasta qué punto estais dispuestos a optimizar.
En mi caso, cualquier optimización es poca, pues cuento con recursos MUY limitados (200MHz y 16MB de RAM).

Claro que podeis usar un proceso con un mega mapa de extensiones bíblicas, tendríais muchas ventajas, como lo dicho de la rotación y del zoom, por no hablar de efectos especiales cambiando colores en la paleta y cosas así, y es perfecto cuando el mapa es "analógico", es decir, no se puede construir en base a tiles, como el famoso "Castle of Dr Malvado".

Lo bueno de usar tiles es que permite ahorrar memoria al usar menos cantidad de imagen (30 tiles de 32x32 ocupan menos que un mapa de 3000x3000) y hacer mapas más grandes (ya que un byte podría representar 32x32 pixels en 32B de color). Mientras que usar un proceso consume mucha CPU en el hecho de mover el enorme mapa, aunque en realidad sólo mueve y calcula la parte visible; el sistema de tiles consume más CPU en cuestion de mover procesos o redibujar en un gráfico, según el método empleado.

Eso debeis valorarlo vosotros y elegir.

[La momia que fuma]

Mira estos ejemplos de scroll tileado que hice usando unos tiles de un scroll tileado (hecho por drumpi, un poco mas complejo que estos ejemplos, con listas enlazadas, procesos que se crean y mueren constantemente y otras cosas...)

No es mas optimo reutilizar los mismos procesos tile (recolocar y cambiar el gráfico) que crear y destruir constantemente?

[SplinterGU]

el de drumpi, crea y destruye... claro, es mas optimo como dices... con los ejemplos que yo puse va mas optimo...

[Windgate]

Menos hablar del motor de tiles y soltad aquí una versión simple y funcional a ver lo que podemos gorronear de ella :o

Es broma amigos, valoro mucho todo vuestro trabajo, ya sabéis :D

El tileado de scroll me parece buena idea, la mejora del actual mod_scroll para aceptar size y angle me parece otra buena idea... A todo ello le veo el problema en la utilización de map_get_pixel para la detección de durezas, ya que una vez cambiado el size y el angle tenemos operaciones matemáticas complejitas que estarían mejor encerradas dentro de una función, ya que una vez calculadas serían de utilidad global para Bennu.

Creo que para solucionar todo esto haría falta un buen lavado de cara... Ya sea sobre el tileado o sobre el mod_scroll actual.

PD: En cuanto a optimización suelo comprobar en ejecución la RAM consumida y determinar la opción más adecuada, según el tamaño del scroll habrá un punto de inflexión.

[laghengar]

Yo tenía esas operaciones matemáticas, que chorrada, a saber donde tengo eso yo ahora.

De todas formas, si es una operación de una línea de código, se le puede hacer #define, es la mar de cómodo ::)

[Drumpi]

Bueno, yo cree el segundo motor que no creaba ni destruia ningun proceso, pero a cambio tenías un array de procesos que cubría toda la pantalla (dos arrays si usas dos capas, tres con tres capas...) y a poco que uses una resolución moderada con tiles relativamente normales (32x32) el rendimiento no era muy bueno.
Sin embargo, en el tercero creo una lista con un proceso por tile dentro de la región, cuyo gráfico no sea 0, y se mantienen todos mientras la cámara no "salta" de tile. En ese momento volvemos a mirar los tiles dentro de la región que no son 0, y modifico los procesos QUE YA ESTÁN CREADOS, la única modificación es que si hay un número mayor de tiles no nulos, añado procesos, y si es menor, elimino los que sobran.

Puede parecer que con este tercer método hay peor rendimiento, pero no, va a un 150% de velocidad respecto al segundo, sobre todo porque elimino la carga de muchos procesos (en un plataformas hay muchos huecos vacíos, sobre todo en las capas que van por encima). En la GP2X, el mapa de FenixLand con el motor 2.0 iba a 70fps, con el motor 3.0 (cuando conseguí que funcionase) lograba un tope de 120fps... y esto con Fenix, con Bennu el 3.0 sube a 140fps (aun tengo que comprobar la máxima caida de frames).

El motorcillo creo que ya lo publiqué unas cuantas veces, pero pronto volveré a hacerlo, cuando acabe con la isométrica (que más de uno lo andaba pidiendo). Ya he terminado de codear (sigo con la flojera, apenas 5 líneas por día, hoy me he pegado un atracón) y mañana empiezo el debug, que de momento ya tengo un puntero fuera de zona. Y ya de paso, resuelvo un bug que he detectado de la cámara con los mapas no cíclicos.