Ejemplo de mapa tileado por procesos con scroll

[Windgate]

lol Drumpi suena trabajoso, ¿No tendrás alguna screenshot para ir abriendo el apetito, no?

¿Con isométrica te refieres a modo7???

El scroll tileado con varias profundidades, aplicando correctamente size y angle podría dar muchísimo juego, como emular profundidad "real" por la que puedes desplazarte, y otros efectos curiosos, tremendo!

[laghengar]

Joder tio, pues yo de tu motor no me he enterado de nada. Solo veia un tileeditor por ahí.

[Drumpi]

Windgate: trabajoso era el motor 2, en el que tenía una lista doblemente enlazada de proceos en 3 dimensiones (lo que significa que cada proceso contenía un tile, y una variable para apuntar a cada uno de sus seis vecinos), imagínate, si ya es complicado meter un nodo en un vector, añadir una columna a esto (y depurarlo).
No, el motor 3 es muchísimo más simple, manejo un único vector al que sólo añado procesos a la cola y elimino los últimos. Además, así ahorro muchos cálculos.
Podría meter zoom, como hice cierta vez, pero más adelante si veo que es necesario.

Por cierto, isométrica no es modo7, es una vista pseudo cenital con giro de 45º, como el Batman de Amstrad, el Head over heels, Sonic 3D o Diablo, por citar algunos conocidos.

Laghengar: pues mira que no he dado follón con él ni nada, junto con Venturer y FenixLand es lo único que he hecho en seis años (Sector Gamma y crapjuegos aparte) ;D El tile-editor usaba el segundo motor y es un código muy chapucero, tengo que reacerlo, aunque puedo aprovechar algo de código.

El código aun está verde, pero hoy he depurado mucho (debería haberlo terminado, pero bueno). El motor isométrico ya casi funciona en mapas no cíclicos, como podeis ver en la imagen, pero tiene el mismo bug que el otro. En los cíclicos aun se vuelve loco y falta por probar mapas con más capas (alturas en este caso), no se por qué el código que me une los mapas en uno multicapa me ha fallado. Tambien tengo que ver cómo se porta persiguiendo a un proceso.

[Windgate]

Ah vale, isométrica normal de toda la vida xD

Sube algún ejemplito, yo estoy deseando echarle un vistazo.

[Drumpi]

Mañana salgo de viaje, volveré por la tarde, si no estoy destrozado quizás termine de resolverlo todo y suba el código y unos cuantos ejemplos de uso (aunque ya digo que el motor 3 en ortogonal lo he publicado algunas veces).
Para pasado mañana debería tenerlo terminado, que el día 10 está cerca y aun no he empezado con el juego.

Para el que tenga prisa:
http://www.fenixworld.com/e107_plugins//depot/files/fw75.motortileadov3.zip
http://www.fenixworld.com/e107_plugins//depot/files/fw75.motortileadov32.zip
Creo que esos son los que tenía yo, no se si tendrán algún bug. Los dos son el motor 3, sólo que el segundo, además de cargar en TMF y TPR, permite usar FPGs como si fueran los mapas de tiles (una adaptación para esquivar el problema de memoria dinámica de GP2X). Ojo, están hechos en Fenix, hay que añadir las librerías para usarlo en Bennu.

http://www.fenixworld.com/e107_plugins//depot/files/fw75.compatible_tscroll.zip
http://www.fenixworld.com/e107_plugins//depot/files/fw75.compatible_tscroll_zoom.zip
http://www.fenixworld.com/e107_plugins//depot/files/fw75.graph_tscroll.zip
Y esto como Bonus: los motores V2, los que usan el famoso array de procesos. El primero es el normal, el segundo incluye la función de zoom (lo que no recuerdo es si solucioné cierto fallo de cálculo que determina el número de filas y columnas en cada momento), y el tercero dibuja el scroll sobre un mapa por cada capa (no está ni optimizado, hace un refresco completo cada frame, era un experimento con muy bajo rendimiento pero con muchas posibilidades: rotaciones, zoom, transparencias... y en el VSE no habría tenido precio).

Me piro a dormir, antes de que publique todos los códigos que he hecho ;D

[Lt_Henry]

Yo simplemente usaba un proceso para hacer el tileado. Dibujando solo los tiles visibles en pantalla, ademas, recuerdo que dibujar varias capas no era mucho mas complejo. Es una verdadera tonteria, eso si, no era muy al "estilo DIV", los dibujaba en plan blit. Como se llama la funcion en bennu? put_screen?

[DCelso]

Yo creo que lo suyo sería modificar el actual sistema de scroll de bennu para que solo dibuje en pantalla lo que se está viendo y así poder cargar mapas grandes sin tanto problema de rendimiento. No debe ser dificil y no afecta a nada a la funcionalidad actual de scroll, es solo un cambio interno.

Incluso se podría plantear alguna nueva función de scroll de mas alto nivel, pongamosle mod_scrollext, en el que pasases un gráfico con los tiles y un mapa de datos en vez de directamente el gráfico con el fondo y que éste crease dentro el fondo con las dos informaciones pasadas.

[Windgate]

Ciertamente para el scroll de Bennu actual también había pensado dar un soporte montado "por encima" de start_scroll que permite tener el mapa tileado en trozos "grandes" de al menos la resolución de la pantalla. Con 4 tiles que puedan mostrarse es suficiente en cualquier caso para cubrir la zona visible.

La idea sería mantener la resolución horizontal y vertical de los tiles (Todos deberían ser iguales) en algún punto, yo en su día usé el campo reserved[] de scroll[]. para ello, e ir haciendo start_scroll y stop_scroll a medida que se salen de pantalla.

Es una de tantas miles de ideas.

Muchas descargas nos pones Drumpi guapetón, ahora voy a echar un vistazo a ver si consigues estimularme con tu trabajo ;D

[SplinterGU]

el tamaño del grafico no afecta el rendimiento del scroll actual de bennu, ya que solo dibuja lo que se ve... ya lo dije muchas veces esto...

[Lt_Henry]

Es que, se me hace dificil de creer que alguien intente hacer un blit mas alla de la region de pantalla. Desde luego si usais SDL como backend grafico tal y como dice Splinter da lo mismo el tamaño del mapa en cuestion de rendimiento. Obviamente mapas grandes consumen mas memoria. Sobre lo de modificar el scroll, yo no lo haria. Este scroll sigue teniendo sus aplicaciones, un paisaje, un tablero ... Un nivel completo requiere tirar de otras tecnicas.

Cuanta nostalgia despierta esto de los tiles eh? :-D

[Drumpi]

Hombre, en un scroll que usa un gráfico, dibujar más allá de la pantalla no tiene sentido. Tileando si, pues cada tile no guarda sólo información del gráfico, sino también de si hay un enemigo, si es el camino de alguna plataforma o si es el final del nivel, entonces conviene que los enemigos y demás se generen antes de entrar en pantalla. Yo al menos doy la posibilidad de escoger cuantos tiles extra se quieren añadir en cada coordenada.

Sobre modificar el scroll, tenemos el módulo oficial, y como ya ha dicho splinter, se pueden hacer nuevos no oficiales y usar el que nos venga en gana. Pero yo me he mirado el actual y os aseguro que es óptimo, ya que dibuja sobre la pantalla (no usa un gráfico o una superficie SDL para ello) y sólo el trozo que se ve.
Sería interesante que dibujase sobre un graph por el tema de zoom y rotaciones, o bien hacerlo directamente. ya lo he comentado otras veces, si supiera suficiente C, y a habría hecho mi propio módulo.

Windgate: no son tantas, las dos primeras son el mismo, con un añadido, pero como no se si son las versiones finales. Las otras tres son el motor 2, el primero y el segundo son exactamente iguales... pero añade zoom, y el tercero pinta en gráfico, usa el que más te convenga.

Por cierto, ya que estamos ¿si modifico el gráfico que uso para un scroll, se modifica en el scroll o tengo que detener y volver a arrancar para que se actualice?

[La momia que fuma]

Por cierto, ya que estamos ¿si modifico el gráfico que uso para un scroll, se modifica en el scroll o tengo que detener y volver a arrancar para que se actualice?

Me suena que hay que hacer start_scroll otra vez (creo que no seria necesario stop_scroll, si en start_scroll inicializas el mismo scroll a actualizar)

Digo que me suena porque no probé, pero creo recordar que Coptroner decía hacerlo así en su Goody Remake (En este caso hablamos de Fenix, pero me imagino que si funcionaba allí aquí lo hará también)

[Lt_Henry]

Drumpi, yo en los motores de tiles que he hecho (en el lenguaje que sea), solo he dibujado la region que cubre la pantalla, y una columna y fila mas. Esto es para poder simular el scroll sin que se vea el "salto" del tile. Sin duda, para que la logica del juego siga "viva" fuera de la pantalla lo mas comodo es mantener todo el mapa de tiles en memoria. Pero por mucha metainformacion que quieras guardar en cada tile, hablamos de un consumo minimo

[splinter_work]

los mapas no son copiados a ningun lado ni existe ningun tipo de cache de los mismos... por ende la pregunta se responde a si misma... pero voy a repetirla para no dejar dudas... si se modifica un grafico de fondo del scroll, este cambio se ve reflejado en pantalla.

[Windgate]

He visto tu motor de Tiles Drumpi, y lo de que el scroll no consume más que lo que ocupa en memoria ha quedado claro, gracias Splinter.

El motor de tiles es interesante porque permite tener scrolls monstruosos ocupando muchísimo menos, me interesa, y tengo una pregunta.

Tal y como está ahora, Drumpi: ¿Tiene algún soporte sencillo que permita asociar durezas al scroll tileado? Se me ocurre duplicar el scroll tileado pero usando las durezas de cada tile, ¿Tenías ya pensado algo sobre ello?

Y en cuanto al zoom no he sabido como usarlo, ¿Cómo se prueba eso del zoom, es alguna tecla o hay que tirar de código?