Version beta del motor tileado V3

[Drumpi]

Hola a todos:

Como voy a estar un par de semanas sin poder pasarme por aqui, voy a dejar el código de mi nuevo motor de scroll tileado, para que lo mire Puck a ver si puede resolver el problema que me da el intérprete de GP2X. Puede que sea fallo mío, así que si alguien lo encuentra, que me lo diga, aunque lo dudo mucho, ya que en windows funciona perfectamente.
El fallo en cuestion se encuentra en el código que carga los archivos de mapas de tiles, en uno de los .inc (es fácil dar con él), incluso he puesto unos cuantos SAY para que se vea por el fichero de salida.txt la linea exacta donde falla (un alloc).

Por lo demás, salvo fallo en algún test, el motor es 100% funcional, así que si alguien quiere usarlo en windows, adelante, solo debe quitar las instrucciones SAY que he usado para depurar. Solo tiene dos pegas: stop_scroll no funciona correctamente con versiones oficiales de Fenix anteriores a la 092a, y que no hay más documentación que los ejemplos (temp.prg, temp2.prg y temp3.prg) pues aun es una beta (ni siquiera puedo decir la mejora obtenida en gp2x, pero en PC ahora va al doble de velocidad respecto a la version 2). Intentaré arreglarlo para la version final.

Para cualquier duda, estaré por forum.divsite.net, que si me dejan entrar.

Drumpi Motor tileado V3 (http://www.fenixworld.com/e107_plugins//depot/files/fw75.motortileadov3.zip)

NOTA: la version que me he traido no contiene los fuentes, fallo mío. Tan pronto como pueda volveré a subir el archivo en la misma dirección, avisaré en el foro de divsite.

[animanegra]

DRUMPI ha subido nueva version del motor de tileado con el codigo fuente(esta todo en el mismo link). Ya podeis fusilar sus ideas cambiar el autor y venderlo :P

No ha podido escribir el porque le tienen vetado el acceso desde donde suele navegar a esta site. :D

Aupas.

[Drumpi]

Muy bien, muy bonito, así que aprovechando que desaparezco para hacer apología del M$, pues que sepas que ya puedo entrar a leer mensajes, aunque no a responderlos...

Jejeje, bromas aparte (;)) pues eso, ahi esta el motor, ya funcionando 100% en PC, no tengais miedo de probarlo, ya os subiré un tutorial (supongo que los ejemplos no quedan muy claros), y cuando puedas, Puck, le echas un vistazo (seguramente no antes de diciembre, con eso de la Wiz...)

[Hokutoy]

Pues muchas gracias!
Intenta colgar algun ejemplo/tuto más... piensa que muchos usando fenix somos bastante novatos así que cuanto mas/mejor explicado mucho mejor.
Gracias!

[Drumpi]

Lo haré, tan pronto funcione en la negrita y ponga la version definitiva.
De todas formas, di la noticia y puse un micro-tutorial en forum.divsite.net, en la seccion de proyectos, no puedo reproducirlo aqui por falta de tiempo, lo siento. Chao, hasta la semana que viene.

[chemaris]

cuando tenga tiempo le dare un vistado, que puede que mas adelante lo necesite, gracias por compartir tu trabajo :brindis:

[masteries]

Lo voy a empezar a estudiar desde ya, lo necesito como agua de mayo y por eso te lo agradezco 1000 veces, pero van a ser 999 porque lo necesito rulando en gp2x y creo haber leído que en la portátil dá un error.

Y por cierto, ¿cómo prefieres aparecer en los créditos? Tal vez con un "powered by Drumpi´s tile engine" estaría bien.

[Drumpi]

Hola, sorpresa, me puedo conectar (al menos hoy) desde la facultad ^^ ¿Habré encontrado algun bug o será el día de suerte?

Bueno, pues para empezar, si, es cierto, en gp2x no va (en PC si). Ya le he puesto un aviso a Puck en el reporte de errores, pero sospecho que hasta que no termine el port a wiz vamos a tener que andar esperando. Tampoco descarto que sea fallo mio, visto lo visto cuando empecé con la GP2X (me daba error leyendo ficheros... hasta que descubrí que estaba leyendo de un fichero que no era ^^U)

Lo de los créditos, de momento, lo dejo a eleccion tuya, porque no le he puesto nombre al motor de tiles (se admiten sugerencias). Como si quieres poner "programación adicional" y ya de paso añades a Puck por el port de Fenix, y al Fenix Team por el propio Fenix :P

[jean la montard]

¿Existe alguna posibilidad de que hagas algo parecido a un tuto sobre como se usa o a los negados nos tocara sacarnos el graduado fenixero correspondiente para poder usarlo ?

PD: Im back...[wei2]

[Drumpi]

Intenta colgar algun ejemplo/tuto más... piensa que muchos usando fenix somos bastante novatos así que cuanto mas/mejor explicado mucho mejor.
Gracias!


Lo haré, tan pronto funcione en la negrita y ponga la version definitiva.
De todas formas, di la noticia y puse un micro-tutorial en forum.divsite.net, en la seccion de proyectos, no puedo reproducirlo aqui por falta de tiempo, lo siento. Chao, hasta la semana que viene.

Welcome back! :D:D:D

En fin, como sigo con la cuenta atrás en la ventanita de abajo, os hago un copia/pega del foro de divsite, ya que veo que os resulta más cómodo:


si alguien le da pereza leerse el tocho del temp1.prg:
-"Incluir" tmapa.h, tscroll.h y tscroll.inc.
-Si no tienes un código propio para cargar mapas, incluir load_tmap.inc (se puede tomar como ejemplo para crearse uno su propio tipo de mapa)
-Carga un mapa con load_tmf o load_tpr, según el tipo de mapa que uses (si no sabes cual es, usa identifica_mapa)
-Llama a start_tscroll, los parámetros están en tscroll.inc bien comentados.
-Si has usado un tmf, tendrás que cargar manualmente un fpg con los tiles, hazlo sobre el campo tsfile de la estructura usada para iniciar el tscroll.
-Usa los campos camera_x y camera_y para mover el scroll, o asigna el id de un proceso a target para que lo siga.
-Si quieres meter un proceso dentro del scroll, con tscroll_get_screen_position, dándole las coordenadas dentro del scroll, devolverá en las otras dos variables dónde debe posicionarse en pantalla.
-Al acabar usa stop_tscroll.

Eso es lo más importante a señalar de los tres ejemplos, algunas cosillas son opcionales, espero poder hacer algo más detallado en la version "final para gp2x" o lo antes posible si veo que me aburro.


Si quereis hacer algun TMF o TPR o simplemente no os apetece crearos vuestro propio formato, aquí os indico el enlace de mi TILEMAP EDITOR (http://www.fenixworld.com/e107_plugins//depot/files/fw75.tilemapeditor050907.zip). Aviso que el programa funciona con la primera version del motor de scroll tileado, y a poco que se haga grande el mapa el rendimiento cae en picado (y que hay algunas cosas que no funcionan aun). Cuando le meta este nuevo, esto se va a disparar, y no habrá más problema que el tamaño de vuestra RAM ;)

[Drumpi]

Hola de nuevo:
Estoy que trino, se me ocurrió el otro día probar una solución alternativa mientras aparece la nueva version, y fue la de crear un puntero nuevo en el proceso de carga, guardar los datos ahi, y luego pasarselo a la estructura que guarda los datos, pero incomprensiblemente me sigue fallando EN LA FUNCION ALLOC (y no en la asignación a la estructura, como cabría esperar), una función que en FenixLand va perfectamente sobre una variable global.

No se si es cosa de que hay diversos compiladores de la 092a, de que estoy mezclando versiones de ufenix, o no se. Como tengo poco tiempo para probarlo, aquí os dejo la versión de uno de los includes que, teóricamente, debería funcionar.
Podeis sustituirlo por el original. O cambiar la linea de los .prg que pone "#include "load_tmap.inc";" para que cargue este, y ya me contais.
En PC sigue funcionando perfecto, sin pérdidas de rendimiento ni nada apreciable.

[masteries]

Ta vez sea una respuesta un poco tonta, pero a mi como lo de alloc se suena al malloc; he supuesto que lo que haces es "capturar" ram para algo; no será que la de la gp2x es muy limitada... yo ahora ando metiendo como 5 o 6 megas de cosas y se queda escaso, al menos la función que muestra la memoria libre me dice que quedan unos 880 KB libres (divido el resultado que da por 1024 obviamente) en mi juego en fenix para la gp2x.

[Drumpi]

Si, alloc lo que hace es reservar memoria para un puntero, y si, he comprobado la cantidad de memoria que quiero reservar: si lo ejecutas, en salida.txt hay una linea en la que sale un número, catorce mil y pico, que son los bytes que intento reservar. Creo que 14KB si que quedan libres, y es más, los ejemplos cargan el mismo mapa que en FenixLand usando la mitad de procesos, así que creo que es que se le está yendo la pinza a mi negrita, y por eso pido vuestra ayuda.
Si os funciona a vosotros creo que va siendo hora de desactualizar el firm.

[masteries]

Pues con 14 kb si que debería ir perfectamente, lo pruebo ahora dentro de un ratillo y posteo el resultado.

Edito porque soy bueno y no quiero hacer doble posting:

Ya lo he probado, por supuesto con el load_tmap_gp2x.inc, también he cambiado la línea del include del programa temp1.prg para que cargue el .inc correcto. Y lo he vuelto a compilar.

Resultado:

No funciona, lo único que he apreciado en las 3 veces que he intentado ejecutar el temp1.dcb es que en la parte superior aparece una línea roja de tamaño 1/3 de la pantalla aprox. , el resto de la pantalla se queda en negro y al segundo o cosa así vuelve al menú de la consola.

Pongo la salida de error.txt

SDL_GP2X: CreateDevice
SDL_GP2X: VideoInit
SDL_GP2X: Physical screen = 320x240 (ilace = 0, pol = 0)
SDL_GP2X: InitHWSurfaces
SDL_GP2X: InitHWSurfaces scratch = 0
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x440968 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5242624 bytes @ 0x440980
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x41110000
SDL_GP2X: Looking for a mouse
SDL_GP2X: No mice found
SDL_SYS_JoystickInit
SDL_GP2X: SYS_JoystickName(0)
SDL_GP2X: ListModes
SDL_GP2X: Setting video mode 320x240 16 bpp, flags=0
SDL_GP2X: Freeing cursor 0x440968
SDL_GP2X: SurfaceManager freeing 256 bytes @ 0x41110000 from bucket 0x4400d8
SDL_GP2X: merging with next bucket (0x440980) making 5242880 bytes
SDL_GP2X: FreeHWSurfaces
SDL_GP2X: Freeing bucket 0x4400c0 (size 17825792)
SDL_GP2X: Freeing bucket 0x4400d8 (size 5242880)
SDL_GP2X: InitHWSurfaces
SDL_GP2X: InitHWSurfaces scratch = 0
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x440968 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5242624 bytes @ 0x440980
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x41110000
SDL_GP2X: SurfaceManager allocating 153600 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5089024 bytes @ 0x441078
SDL_GP2X: SurfaceManager allocated 153600 bytes at 0x41110100
SDL_GP2X: Freeing cursor 0x440968
SDL_GP2X: SurfaceManager freeing 256 bytes @ 0x41110000 from bucket 0x4400c0
SDL_GP2X: VideoQuit
SDL_GP2X: FreeHWSurfaces
SDL_GP2X: Freeing bucket 0x4400d8 (size 17825792)
SDL_GP2X: Freeing bucket 0x4400c0 (size 256)
SDL_GP2X: Freeing bucket 0x440980 (size 153600)
SDL_GP2X: Freeing bucket 0x441078 (size 5089024)
SDL_GP2X: FreeHWSurface 0x4409b8
SDL_GP2X: SurfaceManager freeing 5242880 bytes @ 0x40010000 from bucket 0x43ff84
SDL_GP2X: DeleteDevice
SDL_GP2X: CreateDevice
SDL_GP2X: VideoInit
SDL_GP2X: Physical screen = 320x240 (ilace = 0, pol = 0)
SDL_GP2X: InitHWSurfaces
SDL_GP2X: InitHWSurfaces scratch = 0
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x441160 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5242624 bytes @ 0x441178
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x41110000
SDL_GP2X: Looking for a mouse
SDL_GP2X: No mice found
SDL_SYS_JoystickInit
SDL_GP2X: SYS_JoystickName(0)
SDL_GP2X: ListModes
SDL_GP2X: Setting video mode 320x240 16 bpp, flags=0
SDL_GP2X: Freeing cursor 0x441160
SDL_GP2X: SurfaceManager freeing 256 bytes @ 0x41110000 from bucket 0x4400c8
SDL_GP2X: merging with next bucket (0x441178) making 5242880 bytes
SDL_GP2X: FreeHWSurfaces
SDL_GP2X: Freeing bucket 0x4400b0 (size 17825792)
SDL_GP2X: Freeing bucket 0x4400c8 (size 5242880)
SDL_GP2X: InitHWSurfaces
SDL_GP2X: InitHWSurfaces scratch = 0
SDL_GP2X: Creating cursor 16x16
SDL_GP2X: Allocated WMcursor @ 0x441160 (32)
SDL_GP2X: SurfaceManager allocating 256 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5242624 bytes @ 0x441178
SDL_GP2X: SurfaceManager allocated 256 bytes at 0x41110000
SDL_GP2X: SurfaceManager allocating 153600 bytes
SDL_GP2X: SurfaceManager adding new free bucket of 5089024 bytes @ 0x46e898
SDL_GP2X: SurfaceManager allocated 153600 bytes at 0x41110100
Y el resultado de salida.txt,


Pantalla tactil encontrada
Patching MMU ... OK!
iniciando
cargando mapa
Tipo mapa: 1
Magic leido
Datos de TMF leidos 2
15200
entra
También puedes probar a no utilizar los alloc y fijar el tamaño pensando en el peor caso posible.

[Drumpi]

Perdon por no haber respondido antes: sin internet, ya sabeis.

Pues te pasa lo mismo que a mi, por lo que ya he descartado que fuese un fallo de versiones. Tambien he probado otras combinaciones para el alloc, pero me sigue fallando. Sigo sin entender por qué funciona bien en otros juegos.

Emmm ¿Cual es el peor caso para guardar un mapa de tiles? fijate que este mapa son 15200KB y me parece pequeño: el que quiera hacer un Sonic necesitaría la RAM entera XD

No, en serio ¡Puck, yo te invoco!

PD: se me acaba de ocurrir que podría probar el motor con la 084, aunque creo que daba algun pequeño problema de cuelgues.

[masteries]

Pues sí habrá que ver que dice sobre esto el maestro Puck.

Aún con esto he estado haciendo pruebas en el PC con tu motor de tiles, utilizando color de 8 bits; rinde de una forma estupenda, y he comprobado que se pueden utilizar diferentes capas. Cuando funcione en la gp2x va a ser la solución definitiva al pobrísimo scroll de fénix, mira que no tener incluído un scroll de tiles... me parece rarísimo.

A voz de pronto el peor caso para guardar el mapa de tiles puede ser la mitad de la memoria disponible para fénix en la gp2x (siempre permitirá mapas mucho más grandes que el scroll básico).

[Drumpi]

Hombre, tanto como sustituir al scroll de fenix, lo dudo mucho, ten en cuenta que este scroll, ademas de por SW, está hecho con el propio Fenix. Llevo tiempo dándole vueltas a crear una dll o a integrarlo en el propio Fenix (algo así como una versiona 092a+d :P) pero mis conocimientos no llegan a tanto ^^U

Lo cual me recuerda que por ahi tengo ESTE (http://www.fenixworld.com/e107_plugins//depot/files/fw75.graph_tscroll.zip) tscroll, que dibujaba sobre un gráfico. Está basado en el segundo motor y con ligeros cambios se podía hacer que dibujase todo el mapa en un MAP y luego usarlo en el scroll normal de Fenix... aunque lo dudo, por la memoria que ocuparía, no saldría rentable en GP2X.

En fin, a ver si le meto mano a la programación avanzada y me pongo a crear librerías para Fenix (empezaré portando, supongo). Pero es como lo del WIFI: va para largo.

[masteries]

Eso son grandes aspiraciones Drumpi, pero si te ves y sientes capacitado, ya sabes. Y desde el resto de nosotros, pobres mortales, no podemos hacer más que ofrecerte nuestro apoyo.

[Drumpi]

Eh! que yo no soy más Dios de lo que fue Ulises en su odisea (tambien me tendré que enfrentar a los dioses XD)
Simplemente supongo que sabiendo algo de C, leyendo los códigos fuente de Fenix y aprendiendo a manejar el entorno (materia pendientísima desde que "aprendí programación") se podría hacer "algo". Según he leido, una dll internamente no son más que funciones que se llaman desde un programa, que en el caso de Fenix, deben integrarse usando las declaraciones del propio lenguaje si se quieren usar funciones internas. Pero bueno, seguramente me de el batacazo padre y se me bajen las ilusiones a la altura de un topo ^^U

[masteries]

Yo preferiría enfretarme a Circe.

Básicamente una dll es eso, aunque las únicas que yo he manejado, las del juego Enemy Territory, el gratis no el quake wars; prácticamente las dlls (la de cliente, la de servidor y la de interfaz) son el juego en sí y el ejecutable (que prácticamente es el ejecutable de quake 3), lo que contiene son las llamadas a opengl y el procesamiento de unas matrices de datos donde las dlls van colocando lo necesario para hacer fotogramas.
Una dll puede contener cualquier tipo de código ejecutable, y a veces incluso otras cosas.

De hecho el ejecutable que hace de servidor, es la dll de servidor cambiada de nombre a .exe y arrancada con el parámetro -game_server 1 -mapa -jugadores -bots ...etc.

Pero ya me pierdo bastante en el código de ET (es C lineal sin concurrencia de procesos ni nada parecido, tampoco creais que crea procesos hijo de la forma en que se pueden crear en C ) como para meterme en otro código, aunque el código de Fénix seguro que es otro lío impresionante de líneas, ficheros .h y .c. En definitiva, mi capacidad de programación decrece con el tamaño del código.:confused:


EDITO: He probado el scroll fw75 tuyo, del que has puesto enlace, cambiando cosas para que en la gp2x vaya a 320x240x8bits; compilado para el ultimate fénix, alcanza 15 fotogramas, lento. He visto el código y veo que también se utiliza la función "alloc", por lo que deduzco que el fallo se encuentra en un uso muy concreto de alloc. Alguna pequeña peculiaridad, supongo.

[Drumpi]

Normal que vaya lento: redibuja cada frame el mapa de 320x240 :D:D:D Igual, con acceso directo al buffer del gráfico, o quitándome de encima la capa de interpretación de código Fenix... o simplemente si pudiera desplazar todo el gráfico y luego añadir los tiles de los borde (lo intenté, pero el desplazamiento de memoria se hace en un sentido, y si desplazo en el mismo, se me repiten los pixels) quizás podría ir más rápido, pero bueno ^^U

Lo más curioso es que creo que el .inc que carga el mapa (el que usa el alloc) es exactamente el mismo en ambas versiones. Me lo tendría que mirar bien, pero juraría que es el mismo.

Del código de Fenix solo me interesaría mirar el scroll.c, que es donde va todo el meollo del asunto de scrolls, para hacer algo similar, pero en lugar de usar un mapa, usando los tiles.

PD: A lo mejor te tengo que pedir ayuda para que me digas cómo leches se compila una dll ^^U Hasta ahora, con DevC++ sólo he compilado "console aplication" :P

[masteries]

He estado mirando por encima el g_scroll.c del código fuente del fenix092a; he podido deducir que lo que hace es cargar el gráfico entero (esto es obvio jeje) y posicionar la pantalla respecto del gráfico (o quizá el gráfico respecto de la pantalla, que lío) mirando los valores de x0 e y0. Es esta parte:



(línea 320)
scrolls[n].posx0 = data->x0 ;
scrolls[n].posy0 = data->y0 ;
scrolls[n].x0 = data->x0 % scrolls[n].graph->width ;
scrolls[n].y0 = data->y0 % scrolls[n].graph->height ;
if (scrolls[n].x0 < 0) scrolls[n].x0 += scrolls[n].graph->width ;
if (scrolls[n].y0 < 0) scrolls[n].y0 += scrolls[n].graph->height ;


y otro tanto igual para el fondo, al que llama scroll[n].back

Ahora viendo todo el trabajo que has hecho, veo posible que crees un nuevo código de nombre g_tscroll.c, basándote en la práctica totalidad de tu código y viendo como llaman a las "cosas" en g_scroll.c y como utilizar todo aquello que permanece "oculto" cuando usamos fénix. Es mi humilde opinión, por cierto que el código fuente viene preparadito para el visual studio. Por cierto que encuentro grandes similitudes entre este código y el de los comandos de consola de quake 3; claro los comandos de consola son un lenguaje interpretado que ejecutan una función en C.

El código en su conjunto no es tan inmenso como me esperaba, claro que esto no quiere decir que me encuentre plenamente capacitado, espero poder acallar con esto algunas voces chillonas que puedan surgir. [chuck1]