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 (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...
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...
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
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.
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".
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...
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.
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.
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.
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.
Quote from: SplinterGU on October 08, 2008, 09:40:08 PM
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?
el de drumpi, crea y destruye... claro, es mas optimo como dices... con los ejemplos que yo puse va mas optimo...
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.
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 ::)
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.
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!
Joder tio, pues yo de tu motor no me he enterado de nada. Solo veia un tileeditor por ahí.
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.
Ah vale, isométrica normal de toda la vida xD
Sube algún ejemplito, yo estoy deseando echarle un vistazo.
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
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?
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.
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
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...
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
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?
Quote from: Drumpi on September 28, 2009, 12:54:45 PMPor 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)
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
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.
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?
Lt_Henry: Bueno, si no quieres tener tiles de más, puede añadir 0 tiles extra tanto en x como en y ;D Si hago algo, intento fijarme en todos los detalles que puedo (por eso nunca termino nada :D)
Splinter: pues a mi me sonaba lo que comentaba Momia... pero leyendo el código intuía que algo no cuadraba, por eso la pregunta.
Windgate: tienes tres formas sencillas de asociar durezas. La primera es que cada gráfico es una dureza en si (un bloque, una rampa...). La segunda es mezclar los datos (puedes usar los 4bits menos significativos para el gráfico y los más altos para el tipo de dureza... pero tendrías que hacer una modificación al código, distinto según el motor).
Y la tercera sería cargar dos mapas de tiles: creo que en el segundo motor aun usaba un par de punteros globales para guardar la info, y así lo hacía en FenixLand, carganto uno (el de gráficos) en el array de int y el otro (el de durezas) en el array de bytes (básicamente hice copy/paste de la funcion de carga cambiando el array de destino, cosas de no controlar bien aun el tema de punteros.
Pero eso no es necesario en el motor 3, pues puedes cargar los mapas de forma independiente en sendas variables tipo t_mapa, pero sólo usar una para el scroll (o si te atreves, usar la misma variable rellenando uno de los arrays dinámicos que quedan sin usar).
Lo que me recuerda que he cometido un error en la función que te devuelve el valor de un tile dando unas coordenadas de tile: la búsqueda depente de una variable de tipo tscroll en lugar de tmapa.
Creo que venía el ejemplo de uso del zoom, a ver... Sip, el temp.prg, justo después del control de la cámara con las teclas, usando el + y el - del teclado numérico: basta con usar la función tscroll_cambia_zoom pasándole el identificador del scroll y el porcentaje de zoom. Me hubiese gustado haber usado una simple variable, pero creo recordar que había una serie de cálculos y acciones que debían hacerse al modificar el zoom (si, mirando el código, veo que cambiaba el tamaño del array de procesos entre otras cosas). Esto en el motor 3 debería ser mucho más sencillo (no me lo pidais en isométrica, por caridad ^^U)
a lo que puede referirse es que no se refrescaba lo que se estaba viendo en pantalla, pero si el scroll se mueve, se refleja el cambio...
igual eso ahora esta corregido
lo que no suguiero es hacerlo constantemente, porque cuando se modifican graficos se hace analisis de los mismos.
Sólo para los interesados, deciros que el motor de scroll tileado isométrico ya es funcional, pero aun no está terminado.
Tenía que haberlo terminado el lunes, pero entre una cosa y otra... Si incluso he perdido un día buscando un fallo con las variables locales Z y resulta que he localizado un bug horroroso de todas las versiones de Fenix. Tranquilos, Bennu se ha librado.
No está terminado, aun tengo que probar cómo sigue al proceso target (scroll automático siguiendo a un proceso), añadir un par de funciones para obtener tiles de un mapa o coordenadas de pantalla según coordenadas del scroll, e implementar scroll cíclico en un sólo eje. Esto último creo que lo dejaré para después (a menos que alguien le haga falta), porque creo que el único uso que se le dará sin scroll o cíclico en ambos ejes.
De rendimiento va... bueno, el scroll normal es más sencillo, pero obtengo buenos resultados:
-640x480.
-Tiles de 32x16.
-Mapa de 10x15x2 tiles (la capa de arriba sólo tiene algunos).
-AMD athlon 64x2 4800+
·Fenix 093prev9, scroll no cíclico: 119 fps
·Fenix 093prev9, scroll cíclico: 6 fps
·Bennu r106, scroll no cíclico: 219 fps (creo)
·Bennu r106, scroll cíclico: 101 fps
En nada cuelgo el motor para que lo probeis y lo useis si os gusta, tanto el normal como el isométrico, aunque la documentación, aparte de los comentarios del código, tendrá que esperar.
Que sean llamadas sencillitas porfa:
start_scroll ( , , , , , );
scroll [ ].camera = ;
Y a funcionar xD
No te preocupes, windgate, será tan sencillo como hasta ahora (como lo visto en los motores v3, quiero decir, en los ejemplos, los prg, se contemplan todos los casos posibles).