Drumpi se complace en anunciarles:
EL NUEVO Y MEJORADO MOTOR DE SCROLL TILEADO V3.2
Ha costado pero ya lo tenemos entre nosotros.
Son un conjunto de códigos que crean un scroll basado en tiles, en el que cada uno de ellos es un proceso, y aun así, obtenemos un buen rendimiento para ser código Fénix/BennuGD.
El motor funciona en todas las versiones de Fénix y de Bennu que he probado: Fenix 083b, 084, pre084b, 092a, 093preview9, UFenix, Bennu r106, BennuGP2X r107.
Como muestra de la eficacia, un scroll normal, en GP2X (320x240, a 16 bits, con una CPU ARM a 200MHz) usando tiles de 32x32 y 2 capas, ha funcionado entre 60 y 110 fps en UFenix, según la carga de tiles, y entre 65 y 135 fps en BennuGP2X.
Un scroll tileado isométrico, que tiene el doble de tiles por capa, ha ido bastante más lento, 5 fps en UFenix y 32 fps en BennuGP2X, pero en mi PC ha superado sin problemas los 100 fps. Y estamos hablando de tiles relativamente pequeños.
Esta versión tiene muchísimas mejoras de rendimiento respecto a su homóloga 2.0, y es más independiente y modularizada, fácilmente extensible y sencilla de comprender.
Incluye un completo manual en htm en el que se explican todos los conceptos y ejemplos incluidos con el motor. Echadle un vistazo porque me ha llevado casi tanto como el propio motor ;D
Espero que lo disfruteis y que os simplifique mucho la vida (y si sirve para darle ideas a alguien para hacer un módulo en C, pues mejor :D)
Descargar motor de scroll tileado v 3.2 (incluye motor isométrico) (http://www.fenixworld.com/e107_plugins//depot/files/fw75.motortileadov32.zip)
------------------------------------------------------------------------------------------
MENSAJE ORIGINAL
------------------------------------------------------------------------------------------
Hola a todos:
Me estoy empezando a desesperar, porque todavía sigo programando lo que debería llevar ya una semana hecho. Si sigo así no llego al concurso.
Bueno, pues os traigo una version en fase alfa del motor de scroll tileado, para que vayais abriendo boca. Incluye lo siguiente:
-El motor de scroll tileado normal, que debería funcionar al 100% sin problemas (aun estoy por añadir una opción para añadir "profundidad progresiva", es decir, distinta Z según posición Y). Si queréis usar una versión antigua de Fenix (<0.92a) hay que hacer una ligera modificación para esquivar un "error".
-El motor de scroll tileado isométrico, que no va nada mal, pero que aun tengo problemas con las Z, y que no se puede hacer el scroll cíclico "sólo en X" ni "sólo en Y" (en el último parámetro sólo funciona el flags a 0 ó a 3).
-Cinco (si, cinco) ejemplos de uso. Desde temp1.prg hasta temp5.prg. En el documento "guías de test" se indica qué hace cada uno. Tres de scroll normal, y dos de isométrico.
Es una versión Alpha, por lo que aun está en desarrollo. La parte de scroll normal ya podría ser una Beta preparada para buscar fallos. Digo esto porque de momento no hay documentación ni guía de uso, PERO los ejemplos creo que son bastante claros, y en los includes y los .h hay información de uso de cada función.
Lo importante es que sepais que se crean dos tipos nuevos de datos (uno para cargar mapas y otro para manejar el scroll), se añaden variables locales nuevas (X2, Y2 y Z2 para almacenar la posición respecto al scroll), y que sólo vais a necesitar las funciones:
-Identifica_mapa: por si no conoceis el formato del fichero de mapa de tiles que quereis cargar.
-Load_tmf, load_tpr o load_tmg para cargar el mapa de tiles, según su formato.
-Start_tscroll/start_isometric_tscroll: inicia el scroll con los datos que se le pasa.
-Ts_actualiza_tiles/ts_actualiza_tiles_isometricos: fuerza un refresco total del scroll, sólo necesario (quizás) al arrancar o al hacer modificaciones "serias" (como mucho, lo usareis como en los ejemplos).
-Stop_tscroll/stop_isometric_tscroll: detiene el scroll.
-tscroll_get_screen_position/isometric_tscroll_xget_screen_position: Si se les da unas coordenadas relativas al scroll, este devolverá coordenadas relativas a la pantalla.
-isometric_tscroll_get_screen_position: si se le da la id de un proceso, leerá sus valores X2,Y2 y Z2 y lo situará dentro del scroll. Una de las funciones problemáticas con las Z.
-tscroll_obtener_tile/tscroll_obtener_isometric_tile: devuelve el valor del tile de una posición. Sólo sirve con el mapa del scroll.
-obtener_tile: devuelve el valor del tile de una posición. Funciona con cualquier mapa cargado, se use o no en el scroll.
Dentro de la estructura Tscroll, os interesan los campos:
-ts_file: guarda el ID del FPG con los tiles (gráficos) que va a usar el scroll.
-id_target: guarda el ID del proceso a seguir con la cámara
Me interesaría que si alguien encuentra el fallo que hay con el tema de las Z en el motor isométrico, me lo comente. Las líneas críticas están en la función isometric_tscroll_get_screen_position de isometric_tscroll.inc y en add_iso_tile/add_iso_tile2.inc en la asignación de Z al nuevo tile. Las dos últimas creo que son las que están bien, es la asignación de isometric_tscroll_get_screen_position la que no termino de hallar.
Por lo demás, espero que lo disfruteis, que os sea útil, y que me recordéis un poquito al hacer los créditos ;D Espero vuestras sugerencias, críticas, ayudas y jamones.
Muchas gracias, como ya te comente antes por Gp32spain, cuando me ponga con el juego de plataformas Skull Man (no la proxima versión, pero otra que haré más adelante) ya mirare tus motores de Tiles a ver si me pueden facilitar lo de crear nuevos niveles para el juego.
Animo con ello, insiste que llegaras.
WOW, karma++
Bueno, al final he perdido los nervios y me he salido por la tangente.
Resulta que no hay forma de que me salgan bien los cálculos de las z, y sólo falla en la función que calcula la posición de los procesos (es una operación matemática, en teoría simple, pero que por ciertos redondeos no me sale), así que he hecho lo más fácil: determinar la Z por la posición vertical de pantalla. El algoritmo es muy sencillo y funciona de fábula, pero esto hace que los cubos se comporten como figuras 2D, es una aproximación decente, perfecta si no se traspasan como si fueran fantasmas.
Intentaré perfeccionarlo, pero con más tranquilidad, que anoche tuve una pesadilla en la que me veía programando el motor y no podía parar, me desperté con un dolor de cabeza tremendo :S
Encima, se me quejan tanto Bennu como Fenix en mi GP2X y hacen cosas raras: ahora el motor funciona en Fenix y no lo hace en Bennu, para pegarse un tiro.
En fin, haré lo de los flags cíclicos y trataré de documentar el código, porque las fechas que son no llego al concurso ni matándome a trabajar.
;D animo crack karma up;D ;D ;D no eres el unico un un motor de tildeado isometrico ;D ;D ;D ;D
Que sepas que me lo baje! pero aún no he podido probarlo.
Veamos, a ver si saco un respiro y lo pruebo a fondo, nunca he programado nada isométrico :P
Dcumpi, había sacado un ratillo para probarlo, pero veo que necesitaré importar los DLL necesarios.
¿Cómo tienes configurado Bennu en tu maldito PC para que te compile? A mí me ha dado error de entrada porque no reconocía O_READ, y es porque le falta importar el mod_file.
Supongo que habrá una forma más sencilla de hacerlo correr que ir añadiendo los DLL necesarios a medida que el compilador me va protestando...
¡¡¡Ilústrame, o partícipe de la sabiduría incólume!!!
Bueno, básicamente, para hacer las pruebas tengo un bgdc.import con todos los módulos de que dispongo en la versión de bennu, y un .bat para hacer la compilación y ejecución usando las librerías, módulos y ejecutables desde otra carpeta...
Pero claro, eso es en la versión de pruebas, cuando tenga la final ya haré uno exclusivo con las libs necesarias.
Si te hace falta, yo te paso el bgdc.import y el .bat, pero básicamente lo que falta en lo que subí es que, al estar probando en Fenix (si, aun lo sigo usando, quiero que sea retrocompatible), pues no importé los módulos, así que eso es lo que falta.
Mientras, para que tengais algo con lo que trabajar en serio (porque dudo que useis los flags 1 y 2 por separado) os paso la corrección del proceso problemático. Hoy he estado de descanso y no he picado código.
function isometric_tscroll_get_screen_position (tscroll pointer ts_struct,int gsp_id)
//***************************************************************************
// FUNCION: isometric_tscroll_get_screen_position
// se le pasa el ID de un proceso y este lo situa en pantalla en
// funcion de sus coordenadas isométricas X2 e Y2
// PARAMETROS: ts_struct: estructura con los datos del scroll donde queremos situarnos
// gsp_id: id del proceso a colocar en pantalla.
//***************************************************************************
private
temp_x;
temp_y;
//temp_x2;
//temp_y2;
begin
if (exists(gsp_id))
temp_x=gsp_id.x2-[ts_struct].camera_x;
temp_y=gsp_id.y2-[ts_struct].camera_y;
gsp_id.x=[ts_struct].ini_reg_x+temp_x+temp_y;
gsp_id.y=[ts_struct].ini_reg_y+((temp_y-temp_x)/2)-gsp_id.z2;
//cálculo de la z
//Algoritmo de cálculo de Z super simplificado. No es realista pero se aproxima bastante.
//hallamos la posición y del tile superior izquierdo
temp_y=[ts_struct].tileador_posy - ( ([ts_struct].camera_y_tile - [ts_struct].camera_x_tile) /2);
//buscamos la distancia vertical respecto a ese tile
temp_y=gsp_id.y-temp_y;
//y calculamos la z
gsp_id.z=-( (temp_y/([ts_struct].tmapa[0].alto_tile/2))*2 ) - 1 -
(((gsp_id.z2/[ts_struct].tmapa[0].desplaz_tile)+1)*[ts_struct].n_filas) +
4*((gsp_id.z2/[ts_struct].tmapa[0].desplaz_tile)+1);
end
end
Cualquier otra cosa, aqui estoy.
Bueno, creía que podía dar por finalizado el encodeo pero aun hay un par de cosas por pulir.
Finalmente he implementado dos métodos para el cálculo de Z: el básico es que cada capa tapa completamente a la anterior, por lo que los sprites sólo pueden estar sobre una de ellas y no entre medias (podría estar entre medias de una única capa, pero no lo he implementado así), y la otra es que los tiles más cercanos tapan a los que están más alejados, simulando unas 3D con algunas pegas (los tiles de suelo pueden tapar al sprite si están más cerca a la cámara, aunque estos estén más bajos en el mundo 3D). Estos modos se pueden seleccionar mediante uno de los flags, igual que el scroll cíclico en X y en Y.
Pero me he dado cuenta de que si se usa el método de capas no tiene mucho sentido que los tiles se desplacen hacia arriba una altura por cada capa. Estoy por dejarlo así, porque el desplazamiento por la altura puede ser complicadillo en cuanto la altura del tile no tenga una relación 1:1:1 respecto al resto de medidas (o sea, no sea un cubo, si la altura es la mitad del ancho y el largo). Se puede hacer, pero eso implica más cálculos y no se cómo se lo tomará la GP2X (lo mismo ni se nota).
La otra cosa es por el tema de las Z. Dado que el mayor problema es que el suelo, cuando el personaje se acerca a la parte inferior del tile y el pie se esconde debajo del siguiente, había pensado crear una funcioncilla que detecte ese tile problemático y le cambie la Z respecto al personaje. Aun tengo que sopesar los inconvenientes si hay dos sprites chocando con el mismo tile problemático.
Y es que el tema este de las Z es muy complejo, y no se puede implementar correctamente si no cojo todos los sprites del scroll, los ordeno por Zs y luego dibujo los tiles entre medias, por lo que para no complicar en demasía el código (y porque no corre ahora demasiada prisa implementar scrolls tileados en 3D) he decidido implementrar este método aparte (así quedarían 4 motores para esta versión 3: normal, isométrico, normal3D e isométrico3D).
Bueno, comentadme lo que os parece lo de los desplazamientos en altura y según lo que se diga me pongo ya a documentar o no.
Gente, necesito una respuesta o tomaré por la tangente, y el modo "cada capa cubre todo lo que hay debajo" no usará el desplazamiento por altura.
Quote from: Drumpi on October 17, 2009, 03:49:01 PM
Gente, necesito una respuesta o tomaré por la tangente, y el modo "cada capa cubre todo lo que hay debajo" no usará el desplazamiento por altura.
Ponlo como opción :)
En un fichero .ini por ejemplo :)
Perdona por no contestar Drumpi... Sinceramente, me asustó la idea (Y también estaba ocupado estos días).
Yo soy partidario de que nos dejes una versión beta y/o una demostración, que se vea fácilmente interfaceable (Dentro de lo posible) para que podamos usarla sin tener que meternos demasiado a ver el código por dentro... Entonces podríamos empezar a hablar de errores que veamos.
Recuerda que el propio programador no es capaz de probar su propia aplicación, hay que dejársela a un usuario estúpido, que aporree el teclado, que torture tus FUNCTIONS con parámetros inverosímiles, porque sólo él descubrirá errores que tú jamás descubrirías.
Drumpi encontré el post xD +1 de karma (aunque siga sin saber que son xDDD). Cuando tenga todo listo le echo un ojo al motor :) intentaré probar algo para ver si puedo ayudarte con algunos test jejejeje
Quote from: TRaFuGa on October 22, 2009, 02:17:17 PM
Drumpi encontré el post xD +1 de karma (aunque siga sin saber que son xDDD). Cuando tenga todo listo le echo un ojo al motor :) intentaré probar algo para ver si puedo ayudarte con algunos test jejejeje
pues karma +1 un pulsa
(http://forum.bennugd.org/Themes/default/images/post/thumbup.gif)
El karma es un mero indicativo del amor que sentimos unos por los otros, en este foro somos un poco truchones :-*
Jejeje. Nada, tranquilo.
El motor está, pero no se como meter el parche (porque sería un parche puntual, en plan chapuza) para "alejar" los tiles que deben ser tapados por los "sprites" aunque estén más cerca.
Ahora estoy liado con la documentación, para que luego no me digan que no se sabe cómo usarlo, y estoy siendo exahustivo... quizás demasiado (pero bueno, así lo tenéis fácil para modificarlo si quereis añadir alguna funcionalidad).
Está en htm (así de paso aprendo a manejar frontpage, aunque sea).
Aha, pero ¿has pensado en ponerle un factor de transparencia a los tiles que se quedan por encima del personaje?
Muchos motores en isométrica actuales hacen eso para poder ver a tu pive cuando está detrás completamente y se supone que no lo verias, ahora me viene a la imagen que lo usaba dungeon keeper, pero ya no se decirte si sí o si no.
Pues lo cierto es que no, más que nada porque pocos juegos he visto que lo hagan, siempre se han hecho escenarios abiertos de cara a la cámara, y si había algo que tapase al personaje era un puente o un sprite.
Sería un poco complicado implementar eso. Hombre, actualmente se pueden saber qué tiles están más lejos o cerca de la cámara (porque se dibujan de lejanos a cercanos) y la altura, pero dependería de la posición de los sprites y de la cantidad de tiles que se vean por encima (pueden haber varios tiles en la misma posición de pantalla), y como ya dije, este motor no integra a los sprites (más adelante haré otro basado en este que los tenga en cuenta).
No obstante, se puede acceder a la lista de procesos tile para hacerle todas las perrerías que se os ocurran (ottia, que no he hecho nada para que se puedan identificar ^^U).
PD: acabo de caer en la cuenta de que en ortogonal es muchísimo más sencillo, y en isométrica si se usa el modo de "capas cubren enteramente a las de debajo" tambié se le podría definir un grado de transparencia por capa. Lo pensaré para esos modos.
PD2: Finalmente, para la quedada de ayer, hice las pruebas definitivas del scroll: el isométrico con la pantalla a 320x240, con tiles de 32x16 y 2 lineas/columnas extra ha funcionado a 5 míseros fps con UFenix (32 si se quedaba quieto)... ¡¡y 32 fps con Bennu!! En teoría podría mover medio Sonic 3D, lo cual creo que es bastante.
Eso si, el scroll normal, con el nivel de FLand va entre 67 y 125 fps según la carga de tiles (casi sin tiles se dispara a más de 135). Y porque no sé cómo overclockear la consola.
ostis, 5 fps, te da tiempo a ver una peli en lo que se mueve un objeto :D
Señores, me place anunciaros que el nuevo motor de scroll tileado, incluyendo isométrica está terminado:
DESCARGA (http://www.fenixworld.com/e107_plugins//depot/files/fw75.motortileadov32.zip)
He actualizado el primer mensaje (aunque no se si ha quedado muy bien, porque ya estoy bastante cansado de escribir).
He metido los códigos, cinco ejemplos y gráficos para probar (el compilador y el bgcd.import lo poneis vosotros ;) ) y una guía de uso en htm que espero resuelva vuestras dudas e inquietudes mejor que los típicos leeme que metía antes.
De todas formas, el motor no está probado a fondo, porque si no ya tendría un juego hecho :D Así que cualquier cosa que veais que va mal o que falta, avisadme.
Buf, que respiro acabar cosas, ya veía tiles hasta en las baldosas de la casa. Ahora tengo que ponerme con "los V days".
;D ;D karma up +++ felicidades :)
ostras tu, que complicado, nomentero de na. :(
Primeramente necesitaría saber qué necesito para usarlo, es decir, imagínate que soy torpe torpón y no se lo que es un juego y supongamos que yo tengo un montón de tiles en formato imagen (digamos png) y un personaje en 8 imágenes(dos para cada direccion)
A ver:
Primero: como y con qué creo un mapa con mis tiles y como y con qué guardo el archivo o archivos.
Segundo: como abro el archivo o archivos con el motor
Tercero: como creo el personaje para que interaccione con el mapa y que ficheros necesito crear o usar.
Cuarto: como lo inserto en el mundo para verlo moverse.
Quinto: como interactuo con el mundo, necesitaré saber si crear un mapa de durezas o bien cada tile tiene un tipo para ello o bien necesito un mapa de durezas por tile.
Esto sería un buen tuto para personas que quieran usarlo sin mucha idea en nociones de juegos 2d.
enhorabuena ^^ ¡¡¡con el tiempo que llevabas ahi lidiando con el!!! Yo algun dia terminare alguno de los proyectos personales que empiezo, pero hablo en un futuro muy incierto y lejano. ^^ La multiproyectitis es una enfermedad chunga que tenemos que superar mucha gente :D
ya te digo.
Quote from: DCelso on October 27, 2009, 03:50:48 PM
ostras tu, que complicado, nomentero de na. :(
Primeramente necesitaría saber qué necesito para usarlo, es decir, imagínate que soy torpe torpón y no se lo que es un juego y supongamos que yo tengo un montón de tiles en formato imagen (digamos png) y un personaje en 8 imágenes(dos para cada direccion)
A ver:
Primero: como y con qué creo un mapa con mis tiles y como y con qué guardo el archivo o archivos.
Segundo: como abro el archivo o archivos con el motor
Tercero: como creo el personaje para que interaccione con el mapa y que ficheros necesito crear o usar.
Cuarto: como lo inserto en el mundo para verlo moverse.
Quinto: como interactuo con el mundo, necesitaré saber si crear un mapa de durezas o bien cada tile tiene un tipo para ello o bien necesito un mapa de durezas por tile.
Esto sería un buen tuto para personas que quieran usarlo sin mucha idea en nociones de juegos 2d.
Respondiendo:
Primero: bueno, para crear los mapas tienes cuatro opciones. Si eres muy novato usar ESTO (http://www.fenixworld.com/e107_plugins//depot/files/fw75.tilemapeditor050907.zip), que soporta los formatos por defecto del motor. Si sigues usando DIV o eres capaz de crear maps y fpgs de 8 bits, usarlos. Si eres usuario medio, buscarte un programa de edicion de mapas de tiles y crearte tu función de carga (tienes tres ejemplos en el motor). Si eres avanzado, crearte tu propio editor.
Segundo, tercero y cuarto: leyéndote lo que ha retrasado la salida del motor cuatro días, está dentro.
Quinto: eso depende de ti. Lo normal es que uses un mapa de tiles con las durezas, o si no el propio mapa de tiles. Tienes funciones de sobra para obtener las durezas en cada posición del mapa. El motor es como el scroll de Bennu.
El motor está preparado para que puedan usarlo aquellos que ya han programado algun otro juego en Fénix/Bennu. Es ligeramente más complicado que desarrollar un juego con scroll normal. Cualquiera que haya implementado un matamarcianos con scroll puede hacer uno con los tiles.
¿O es que la ayuda que he puesto no es lo suficientemente clara? :(
Por lo visto había dos pequeños errores en un par de ficheros. Los he corregido y lo he vuelto a subir.
Avisadme si os da algún problema más.
A ver yo me refería a que sería muy bueno poder tener un manual de programación de juegos usando el motor este. Haciendo minijuegos, porque así se entienden mejor las cosas, sobre todo para los no muy entendidos en materia.
Descargando, a ver si es tan complicado como decis xD
Eso si, ahora si lo veo "humanamente aplicable" te ganas mi bendicion, un karma y te invito a una cerveza virtual :-X
Hombre, un manual como el que dices, DCelso, no me llevaría cuatro días ¡me llevaría cuatro meses! (y eso contando con que llegue a acabarlo).
Pero básicamente, sería el mismo manual que se usa para entender cómo funciona start_scroll, y creo que, a menos que windgate haya concluido el suyo, no hay más que los de DIV.
En fin, si veis que es complejo, os puedo hacer el típico juego de una nave que debe moverse por un escenario sin chocarse con las paredes... o el de un submarino llamado "el Ballena Azul" (referencia a juego paperactivo).
Se agradecería mucho, por mi parte te voy dando el karma por adelantado, a ver si te presiona un poco :D.
Lo estoy probando porque quiero empezar un proyecto con scroll tileado (No isométrico). Una pregunta: ¿Por qué no pones la lista de DLLs a importar?, ¿Cómo haces que te funcione sin ellas?
Antes de que me humilléis, me he puesto a compilar todas las tempX.prg y me falta importar mod_file en todas ellas de entrada, ¿Me dejo algo?
Ya dijo que tenemos que poner nosotros el archivo "bgdc.import".
Así que él, actualmente tendrá un archivo bgdc.import en el mismo directorio del prg principal con todos los mods o bien tendrá este archivo en la ruta del bgdc.exe.
Es similar a tu archivo imports.prg pero sin tener que poner la palabra import ni las dobles comillas, simplemente una lista de los modulos línea por linea.
En tu caso, creo que puedes solventar la papeleta para poder usar el motor poniendo include "prgs/import.prg" en tu prg principal.
Efestivamente: yo he hecho las pruebas por "fuerza bruta", un bgdi.export con todas las libs.
No lo he puesto por dos razones: la primera es porque cada juego requiere incluir unas librerías distintas, según lo que vaya usando, y es posible tambien que se re-declaren algunas librerías si el usuario no conoce mi método de añadirlas; la segunda es porque he quitado (o tratado de quitar) todos los archivos que hagan referencia a un lenguaje concreto, si no, hubiera ido con Fenix 092a y los códigos ya compilados ;)
Respecto al juego, pues nada, ya iré pensando algo, pero de momento tendrá que esperar, si no, ahora verás cuando pase por offtopic...
¡Leches! ¡y que tengo que ir haciendo el PFC! ;D
Quote from: Drumpi on October 28, 2009, 02:00:13 PM
Efestivamente: yo he hecho las pruebas por "fuerza bruta", un bgdi.export con todas las libs.
No lo he puesto por dos razones: la primera es porque cada juego requiere incluir unas librerías distintas, según lo que vaya usando, y es posible tambien que se re-declaren algunas librerías si el usuario no conoce mi método de añadirlas; la segunda es porque he quitado (o tratado de quitar) todos los archivos que hagan referencia a un lenguaje concreto, si no, hubiera ido con Fenix 092a y los códigos ya compilados ;)
Respecto al juego, pues nada, ya iré pensando algo, pero de momento tendrá que esperar, si no, ahora verás cuando pase por offtopic...
¡Leches! ¡y que tengo que ir haciendo el PFC! ;D
error! nunca se redeclaran las funciones... hay un chequeo que si ya esta importado un modulo no se vuelve a importar.
Pues me dan problemas los ejemplos....el 1º y el 2º, me saltan en cuanto toco algo (con el error de procedimiento no activo), el 3º es el único que me funciona bien, el 4º me vuelve a dar el mismo fallo, y el 5º funciona pero....no hace nada, solo veo un tile negro que no se mueve ni a tiros...no veo que os haya pasado a ningún otro, que hago mal?
En todos los que fallan no se ve tile ninguno (en el 3º un solo tile azul a lo pared de ladrillos, no se si es el ejemplo asi o tambien falla algo), solo el recuadro blanco y las cifras, aunque en el 4º al arrancar a veces llego a ver un atisbo de un frame del mapa isométrico.
¿En qué version de Fenix/bennu te sucede eso? Es raro que te pase eso, probé todos los ejemplos antes de comprimir.
Mira si es que no carga algun fpg por estar en otra carpeta.
Nada, actualizé a RC10 y ya va bien ;D, aunque con la que me petaba creo que era la RC9, asi que no deja de ser raro, tanta diferencia no puede haber...
Pues es raro, rarísimo, y más teniendo en cuenta que el motor v3 original ya funcionaba cuando Bennu no era capaz ni de cargar FPGs, pregúntale a Splinter ;)