Dudas sobre tiles

[gecko]

Saludos a todos!

Bueno, resulta que estuve viendo unos ejemplos sobre Scrolls tileados (...los incluidos en el bennu pack), y hay 2 formas que mas o menos entendi como funcionan.

La primera es tener un proceso por cada tile del mapa, e ir moviendo esos tiles/procesos a medida que se mueve el jugador.

La segunda es directamente dibujar los tiles visibles en el fondo de la pantalla con put() en cada frame.


Cual de las 2 seria mas eficiente?
cual de las 2 seria mas sencilla?

Recomiendan estas o alguna otra tecnica?


A simple vista la segunda parece mas simple, pero tengo mis dudas con el rendimiento, en scrolls con mucho movimiento, o manteniendo fps altos... no se...

[DCelso]

A ver si he entendido bien.
La primera opción es tener un proceso llamado mapa en el que antes del bucle creas un gráfico completo del mapa usando los tiles, y después vas desplazándo éste mapa gigantesco por la pantalla.

La segunda opción es tener un proceso llamado mapa en el que justo dentro del bucle, al principio, dibujas la parte del mapa que se va a ver en la pantalla.

Pues vamos por partes, ambas tienen sus pros y sus contras, depende como quieres que se comporte tu juego.

En la primera opción gastas más memoria, osea que en sistemas limitados de RAM podría ser un problema, como ventaja puedes crear un mundo en el que los enemigos, o personajes que interactuan con el mapa (actores) pueden hacer cosas prácticas o no mientras el personaje principal se encuentre en otro lado del mapa, date cuenta que en la segunda opción, como no hay mapa dibujado en secciones fuera de la pantalla pues no podrían interactuar los personajes que estén fuera de la pantalla, (bueno podrían hacerlo, no directamente, pero habría que ir complicando la lógica)

En la segunda opción, pues surgen otros poblemas, no puedes dibujar simplemente los tiles que se ven en pantalla, porque normalmente el personaje no se mueve discretamente de tile a tile, sino que lo hace progresivamente, así que en pantalla los tiles de los bordes no son tiles completos sino medios tiles o tiles a medias, por consecuencia tienes que dibujar siempre más tiles que los necesarios para llenar la pantalla, es decir si son tiles de 32x32 y tienes una pantalla de 320x320 la lógica nos dice que con 10x10 tiles es suficiente, pero en realidad no lo son porque la pantalla se mueve suavemente con el personaje y no encaja la pantalla exactamente con los 10x10 tiles, así que tendrías que pintar 12x12 tiles siempre, hay formas de complicar la lógica para no tener que dibujar 12x12 tiles que sería pintar la parte que se ve de los tiles del borde pero claro siempre hablando de ir complicando cada vez más el código.
Luego el otro problema es que tus enemigos deberán de ser bobos (o no existir) hasta que no se vean en pantalla :D.

Por último, ya existen motores para gestionar todo esto, por ejemplo el de uno de los foreros al que no voy a nombrar para que no le piten los oídos :D.

[Drumpi]

Me pitan los oidos ;D

No, DCelso, lo has entendido mal: el primer método consiste en usar un proceso por cada tile que haya en pantalla, y el segundo es pintar los tiles en el fondo.
En ambos casos te puedo dar datos por experiencia propia... en Fenix.

El sistema de proceso por tile puede ser tan simple o complejo, tan eficiente o ineficiente como se quiera. El mejor método es tener un proceso que controle todos los procesos tile, que son procesos CONGELADOS, de forma que los cálculos los lleve un único proceso a base de incrementos (las multiplicaciones consumen mucho más). Luego hay variantes como la de crear tantos procesos como caben en pantalla, que es la más fácil, o sólo procesos para aquellos tiles visibles no nulos. También está el tema de crear/destruir procesos.

El de poner tiles en el fondo es muy sencillo, y basta con tener un único proceso. La parte fácil es la de poner los tiles visibles, la complicada es la de borrar esas partes en las que ya no hay tile. Yo sólo he implementado un sistema en el que se dibuja el fondo una vez en cada frame, que es más eficiente que hacer dos pasadas (clear_screen + put_tiles) y menos que modificar sólo los pixels que cambian: basta con poner los tiles visibles, y en las zonas no visibles pintar un cuadrado de color 0.

VENTAJAS, INCONVENIENTES Y RENDIMIENTO:

Con proceso por tile, la cosa puede ir de muy lento a realmente rápido. Pierdes rendimiento al tener muchos procesos en pantalla, y el cálculo de todos ellos puede pasar factura en sistemas de bajo rendimiento, sobre todo si te dedicas a matar y crear procesos. Lo bueno es que te permite aplicarle efectos independientes a cada tile, como rotaciones, alpha, animaciones, generar otros procesos y borrar el tile (como hago en Echo, para crear los enemigos). E incluso puedes usar tiles no cuadrados, de distintos tamaños, y asignando bien las z, no se tapan los unos a los otros.

El de pintar en la pantalla... no te se decir, pero las funciones put, como bien sabes, siempre han sido lentas. Splinter les ha dado un buen empujón en Bennu, pero en Fenix el rendimiento de pintar una pantalla a cada frame era muy bajo (3fps en GP2X frente a los 20fps del proceso por tile en la versión 2 de mi motor). Quizás trabajar con el buffer del mapa agilice mucho las operaciones, sobre todo si consigues hacer un desplazamiento de los pixels y repintas sólo la parte nueva del scroll. Las ventajas también son importantes: es mucho más fácil de hacer, y le puedes aplicar los efectos que quieras al mapa, como rotaciones para jugar dos personas en los extremos de la WIZ, escalados para un efecto Sonic2-multiplayer, alphas, e incluso usarlo para suelos de modo7 (lo que te permite hacer mapas de modo7 gigantescos), texturas para otras librerías (bennu3d no se, pero en VSE, u otros efectos 3D)...

Yo te pediría que probases el rendimiento de dibujar sobre la pantalla (es muy sencillo), pero por lo que he probado yo, el proceso por tile funciona mejor en la consola portatil y en entornos de poca CPU.
Evito hacer spam, pero ahi está para el que lo necesite ;D

[DCelso]

tienes razón, pues sí que he leído yo mal el post, ahora leyéndolo por segunda vez lo entiendo :D.

Y una tercera opción de crear un proceso llamado mapa con un graph que sea la composición de todos los tiles para crear el mapa?

[Drumpi]

Eso si que no lo he entendido yo ¿te refieres a hacer un gigantesco map con todos los tiles ya puestos? Eso ahorraría espacio en disco, y requeriría poca CPU a la hora de ejecutar (la optimización de Splinter de dibujar sólo la zona visible del mapa es muy buena), pero requeriría una cantidad enorme de RAM, anchoxalto en mapas de 8 bits, el doble en mapas de 16.
No digo que no se pueda usar, de hecho, en el Camelot Warriors de GP2X es el sistema usado, pero el tamaño del nivel quedaría muy limitado.

Hay otro método que aun no he probado: consistiría en crear un mapa vacío algo más grande que la pantalla, pintar sobre él parte del mapa, y a medida que avanzamos vamos pintando la nueva fila/columna de tiles. Este mapa lo usamos en un scroll normal pero cíclico tanto horizontal como verticalmente, de forma que, al llegar al extremo del mapa (por ejemplo, el derecho), seguimos pintando desde el otro extremo (el izquierdo) y ya se encarga el scroll del resto.
Creo que es un sistema muy eficiente, pero presenta graves problemas cuando hacemos movimientos muy bruscos con el scroll (hay que tener en cuenta si hay que repintar una fila, dos, tres o toda la pantalla).
También que, o clonamos mapas o usamos map_xputnp.

[DCelso]

sasto, a eso me refería.

[gecko]

ese ultimo sistema parece muy muy bueno... Mas en mi caso que estoy bastante acostumbrado al scroll "normal" de bennu...

Por lo que veo parece que hay bastante bastante para debatir y aprender sobre tiles.

creo que voy a probar con el scroll, y sino con el pintado del fondo, ya que manejar tantos procesos lo veo como algo un poco mas complicado para empezar.

Otra cosa drumpi, tu motor es relativamente simple para adaptar a un plataformas y/o un RPG? viene con durezas y tiles especiales incluidos o maneja solo la parte grafica de los tiles?

Gracias a ambos por las ayudas y sugerencias, es muy muy interesante esto de discutir/comentar tecnicas para determinadas cosas.

[Drumpi]

Mi motor sólo representa la parte gráfica, nada más, pero es compatible con casi cualquier cosa que quieras hacer (scrolls cíclicos, no cíclicos, siguiendo a un proceso, adelantar o retrasar la cámara respecto a este en cualquier dirección, múltiples capas).
La pega es que usa un formato propio, pero es sencillo crearte tu propio cargador.

Verás, hay un par de includes que te permiten cargar en memoria mapas de tiles. Definen un tipo especial de estructura de datos, entre los que hay un puntero (no te asustes, si miras como se cargan los formatos propios verás que es muy simple de usar). Esos mapas de tiles puedes usarlos como mapas de durezas, o asignarlos a un scroll tileado o hacer lo que quieras.

El control de Z es un poco extraño en el scroll isométrico, por eso tiene dos modos: típico (cada capa cubre completamente al anterior) o pseudo-3d (los procesos dentro del scroll pueden ser cubiertos parcialmente según la posición en 3D, hay ejemplos para que los veas).
Viene todo muy documentado.

Sobre tiles sí que hay mucho que discutir, pues no estamos programando en C. Si fuera así, dibujaríamos directamente sobre el buffer y listo, pues es rapidísimo, pero aquí estamos una capa por encima y hay que adaptarse a las "limitaciones" y saber aprovechar al máximo las capacidades del lenguaje.
Vamos, no creo que sea muy difícil adaptar el scroll de Bennu a un scroll por tiles, pero yo, por ejemplo, no he sacado tiempo para ello.