Scroll tileado ¿final round?

[Drumpi]

Hola a todos:

Finalmente, me doy por vencido, no salgo al concurso del tower defense por falta de tiempo, y no, algo más de tiempo no lo arreglaría porque necesito un descansito.
Y la causa es que he estado mejorando mi ya clásico y viejuno motor de scroll tileado.
He corregido un fastidioso bug con la colocación de la cámara en coordenadas negativas, y lo más raro es que ahora funciona en UFenix, y no he tocado nada, pero no quiero echar las campanas al vuelo: las anteriores pruebas también funcionaban hasta que se ponía en práctica en FL.
En fin, sólo informaros que aun me queda un poco para terminar, pues le voy a terminar de añadir un par de cosas que había postpuesto por el concurso, pero ya no merece la pena, así que quedará bastante bien el nuevo motor para tiles isométricos.

Calculo que me queda una tarde de programación, y tres de documentación, así que espero poder subirlo pronto. Eso sí, según las pruebas, si quereis ser "bestias" y llenar la pantalla de tiles isométricos en scroll cíclico, os recomiendo encarecidamente que paseis a Bennu, en PC es la diferencia entre 5 fps y 110 fps (sí, yo tambien he flipado con la mejora, debe ser algun caso muy puntual).

[masteries]

Eso me suena muy bien y lo voy a necesitar para las fases 3 (scroll horizontal tileado), fase 4 (scroll tileado multidireccional, es una fase con scroll tipo secret of mana, secret of evermore) del Viaje al centro de la Tierra; y también para otro proyecto que voy a mantener en secreto pero que va a llenar de acción la GP2X, sólo diré que se pueden conducir vehículos, con scroll del tipo secret of mana.

Había pensado hacer el código de los scrolles yo mismo, pero si alguien como Drumpi ya me lo da hecho, ahorro una cantidad de trabajo y de cansancio mental enorme. Así el desarrollo irá muy deprisa.

Drumpi, mantenme informado en este hilo, (con enlaces si puedes) sobre el motor de tiles y el Bennu, de todo lo que me haga falta para usarlo en la GP2X. Y mis felicitaciones por tus avances.

[Rivroner]

¿Y qué pasa con el scroll que viene en el proio Fenix, chupa muchos recursos para proyectos grandes?

Yo tengo pensado hacer un juego de plataformas con un scroll parallax de 4-5 capas y 3-4 enemigos como mucho a la vez en pantalla, ¿me irá lento en Wiz?

[romeroca]

Ten en cuenta que el scroll de fenix se aplica a bitmaps. Imagina que si tuvieras un mapa de 16000x16000 puntos, tendrías que tener una imagen de ese tamaño en memoria.

El problema radica en crear mapas de forma que ocupen poco en memoria. De ahí que Drumpi se esté pegando el gran trabajo de hacer un scroll por tiles.


¿Y qué pasa con el scroll que viene en el proio Fenix, chupa muchos recursos para proyectos grandes?

Yo tengo pensado hacer un juego de plataformas con un scroll parallax de 4-5 capas y 3-4 enemigos como mucho a la vez en pantalla, ¿me irá lento en Wiz?

[Rivroner]

Ya, si eso me lo imaginaba (y ya lo había leído hace tiempo del propio Drumpi) pero en mi caso no creo que haga pantallas más grandes de 3200 por ejemplo.Y si necesito algo más grande pues simplemente me invento como un cambio de nivle y descargo ese mapa y cargo el nuevo tb como mucho de 3200. :D

Ya sé que para ciertos juegos es necesario algo más bruto, yo entiendo lo que quiere hacer Drumpi, pero yo creo que con un poco de imaginación no hace falta cargar/hacer un mapa entero y de golpe tan grande.

Pero vamos, si él lo necesita para su juego lo veo perfecto, y así otros nos podemos aprovechar del asunto algún día. :)

[Drumpi]

Muchas gracias por el apoyo.
En el foro de Bennu ya hay una descarga disponible para los más ansiosos (aunque no creo que los haya :D) pero me he dado cuenta de que tiene un fallo enorme el actual método de cálculo de Z (la profundidad de dibujado) y tendré que reescribirlo, o sea, hacerlo bien como intentaba desde un principio.

De todas formas, Rivroner, hay más razones para usar el scroll tileado, no sólo hacer mapas grandes, y es que no creo que sea complicado añadirle zoom al scroll normal (ya lo hice una vez, el isométrico tendría que revisarlo bien), y si soluciono el tema de las Z se podrían diseñar mapas tileados con 3 dimensiones para el scroll normal (si, con altura real, no la simulada de los motores de SNES, hablo de poder superponer 400 capas como si fueran 400 puentes a distintas alturas). Incluso mejorar el rendimiento en esos juegos de mapas gigantescos en los que el prota no puede tocar las paredes y queremos usar collision para comprobarlo.

Pero claro, esto aun no es una realidad... de momento. Estoy más cerca que nunca, y aun le queda algo de trabajo, pero creo que podré ir pensando en FL seriamente en cuanto consiga un editor de mapas de tiles :D:D:D

[Rivroner]

A ver cuando vas acabando y sacando los jueguecicos que tienes casi acabados mamona. :quepalmo:

Lo que está claro es que usarán el mejor motor de tiles del mundo mundial. :D

[Drumpi]

Si lo dices por el "eso con Spirus" (el único que tengo en la lista de la firma casi acabado) aun falta casi todo el apartado sonoro, y lo componen un sordo y un manco, así que imagina. Del resto, esperaba tener este motor para ponerme en serio, que ya visteis el FL: a unos tristes 30 fps, y sólo mover el escenario y al prota...

[darionapole]

suena interesante el proyecto, ta interesante la idea de los mapas de tiles, se ve muy util.
La mejor de las suertes o mejor aun ojala te ganes una loteria ^_^

[masteries]

Drumpi, como editor de mapas de tiles utilizo el Mappy; es fantástico, permite múltiples capas, te da los tiles en un archivo .bmp y es bastante práctico.

Yo incluso utilizo tiles que no se dibujan para indicar dónde van los sprites decorativos y de enemigos en la fase 2 del Viaje, haciendo esto ahorras muchísimo en programación. Vamos, que con un poquito de ingenio transformas el Mappy en el editor de escenarios para cualquier juego 2D, también permite mapas de tiles isométricos.

[Drumpi]

Creo que ya lo vi hace tiempo, pero lo que necesito es un formato de salida fácil de entender para luego hacer un conversor a mi formato, y creo que este hacía una compresión con un algoritmo raro, o no se :S
Tengo el mio, pero tengo que cambiarle el motor por este, para que sea aun más rápido.

Bueno, y ahora necesito ayuda, símplemente tomar una decision:

Me he dado cuenta de que con el actual sistema de Zs, si un personaje mide dos tiles de altura o sube, será tapado por cualquier tile que esté una "planta" por encima (digo planta porque ancho y alto los uso para referirme al plano horizontal).

Así que necesito volver al sistema primitivo, pero me surge un par de ideas, y como debo tener el cerebro totalmente simétrico o algo así, pues no me decido.
Os comento: en el espacio isométrico, cuanto más abajo se pinte el tile, más cerca está de la cámara y menor será su Z ¿correcto? bien. Cuando queremos poner un tile a una altura superior, este debería tener la misma Z que los tiles que hay en su vertical, pues su distancia a la cámara es la misma.
Pues eso no debe ser así, porque los tiles de mayor altura deben tapar a todos los tiles que hay por debajo, por lo que deberían tener una Z menor.

Y aquí surge el problema: ahora tengo al personaje que mencionaba antes, de dos tiles de altura, y cuando está más cerca de la cámara debería verse por encima de ambos tiles, por lo que su Z es aun menor que la del tile de más altura. En teoría creo que puedo implementar este sistema, pero debería dejar varios valores de Z entre fila y fila de tiles, y esta diferencia dependería de la altura del mayor gráfico que vayamos a usar (y para no pillarme los dedos debería ser del número de filas que cabe en pantalla + 1). Es un sistema complejo pero no tiene el inconveniente del siguiente.

El otro es hacer que todos los tiles de la misma vertical tengan la misma Z. Lo bueno de este sistema es que entre fila y fila puedo dejar una diferencia de 2 unidades de Z para que estén los procesos moviéndose, y simplifica mucho el código. La pega es esa, que todos los tiles de una "columna vertical" tienen la misma Z, y se vería el flickering o como se llame a la superposición aleatoria de ambos procesos, y sería trabajo del diseñador impedir que dichos tiles se solapasen; no es nada difícil pero sería una cosa bastante importante a tener en cuenta, y al usar más tiles no se podría aprovechar el mismo mapa como durezas sin complicar demasiado el código, necesitarías cargar otro mapa (hacerlo es sencillo, el problema es ocupar más memoria).


Así que esas son mis dos alternativas, creo que en la primera puedo hayar algo que me simplifique algunos cálculos, pero quiero saber vuestra opinión, y qué creeis que valoraría más el novato que quiera usar el motor de tiles.
Gracias.