Portando proyecto Montezuma a PiXTudio

[Drumpi]

Hola de nuevo:

Bueno, para no ensuciar otros hilos, voy a crear este, para ir añadiendo los problemas que me van surgiendo para pasar mi proyecto de BennuGD a PiXTudio (va a pasar el código por más lenguajes que la Piedra de Roseta).
Siguiendo con lo dicho en el hilo de ¡¡elCompiladorrrrrr!!, que me daba un fallo de que no se reconocía "_ESC", he decidido ir por dos vías diferentes: tener una carpeta para portar a través de ¡¡elCompiladorrrrr!!, y otra para hacerlo a mano. Así podemos ver las dificultades de un método u otro y cruzar resultados.

Bien, pues en la compilación a mano he incluido el bgdc.import en el .prg, y en lugar de dejarlo como una lista de módulos, le he tenido que añadir "import" al principio de cada línea, y poner comillas antes y después del nombre de cada módulo (vamos, usar el comando import de toda la vida).
Lo siguiente que me ha dicho ha sido:

Code Select Expand

D:\Pixtudio\Proyectos\Montezuma\desarrollo\bgdc.import:8: error: Library "mod_mathi.fakelib" not found ( error in token: "mod_mathi" ).
Así que he sustituido la mod_mathi por la mod_math. Espero que no se rompa nada, todos los cálculos los hago usando enteros (nunca me han gustado los float, su imprecisión pasan factura cuando, por ejemplo, 1+1 = 0.999999999, y al convertirlo a INT el resultado ha sido 0).

Ahora sí me reconoce el "_ESC", pero me da otro error:

Code Select Expand

D:\Pixtudio\Proyectos\Montezuma\desarrollo\src/configuracion/fich_configuracion. inc:29: error: Unknown identifier ( error in token: "SCALE_NOFILTER" ).
Esa es la constante para el 2xScale sin filtrado de ningún tipo ¿Se le ha cambiado el nombre?

Por cierto ¿Existe algún tipo de documentación? Aunque sea el nombre y los tipos de variables de las funciones de PIXTUDIO.

Continuará...

[josebita]

Bien, pues en la compilación a mano he incluido el bgdc.import en el .prg, y en lugar de dejarlo como una lista de módulos, le he tenido que añadir "import" al principio de cada línea, y poner comillas antes y después del nombre de cada módulo (vamos, usar el comando import de toda la vida).

Ahora se llama "pxtb.import".

Lo siguiente que me ha dicho ha sido:

Code Select Expand

D:\Pixtudio\Proyectos\Montezuma\desarrollo\bgdc.import:8: error: Library "mod_mathi.fakelib" not found ( error in token: "mod_mathi" ).
Así que he sustituido la mod_mathi por la mod_math. Espero que no se rompa nada, todos los cálculos los hago usando enteros (nunca me han gustado los float, su imprecisión pasan factura cuando, por ejemplo, 1+1 = 0.999999999, y al convertirlo a INT el resultado ha sido 0).

La librería mod_mathi está ahí (según comentaba Splinter) por compatibilidad con DIV, pero en el FAQ ya puse que no es un objetivo necesario de PixTudio mantener esa compatibilidad (de hecho me falta por romper alguna cosa más antes de estabilizar el API de los módulos).

Ahora sí me reconoce el "_ESC", pero me da otro error:

Code Select Expand

D:\Pixtudio\Proyectos\Montezuma\desarrollo\src/configuracion/fich_configuracion. inc:29: error: Unknown identifier ( error in token: "SCALE_NOFILTER" ).
Esa es la constante para el 2xScale sin filtrado de ningún tipo ¿Se le ha cambiado el nombre?

He quitado los modos de escalado que se establecían con scale_mode. Ahora puedes establecer la variable scale_resolution y poner que no quieres filtro con la nueva variable global:

Code Select Expand

scale_quality = SCALE_NEAREST;
o

Code Select Expand

scale_quality = SCALE_LINEAR; //por defecto.

PERO por lo que estoy viendo hay un bug que hace que el valor dado en scale_resolution no se esté respetando. Aquí te dejo un enlace al bug que, espero, será fácil de solucionar.

Por cierto ¿Existe algún tipo de documentación? Aunque sea el nombre y los tipos de variables de las funciones de PIXTUDIO.

Es algo pendiente y necesario sí, pero aún no existe.

[Drumpi]

Anotado lo del import.
¿Compatibilidad? Si la memoria no me falla se mantuvieron ambas porque mod_math trabajaba con floats y mod_mathi trabajaba con enteros, tanto como datos de entrada como de salida. Más que nada por lo que comentaba de los fallos de redondeo. Si con float se va a comportar exactamente igual que con enteros, no hay problema.

SCALE_NEAREST creo que es la que yo necesito ¿no? la que no hace ningún tipo de filtro de suavizado... ¿o funcionaban ambos métodos igual en el reescalado hacia arriba? (x2, x3, x6...).
Veo entonces que tendré que modificar el sistema de guardado de configuración y de "set_mode". Mañana le tendré que echar un par de horitas.

Gracias.

[josebita]

SCALE_NEAREST creo que es la que yo necesito ¿no? la que no hace ningún tipo de filtro de suavizado... ¿o funcionaban ambos métodos igual en el reescalado hacia arriba? (x2, x3, x6...).
Veo entonces que tendré que modificar el sistema de guardado de configuración y de "set_mode". Mañana le tendré que echar un par de horitas.

Sí, eso lo que hace es el modo de escalado "sin filtro" (en realidad, escalado con nearest neighbour).

Reviso lo de la mod_mathi.

[Drumpi]

Por si acaso, esto es lo que me lanzaba el programa (o comando, no recuerdo) que extraía las cabeceras de las funciones de las DLL de BennuGD (versión 181):

Code Select Expand

Module Describe v1.1 (Build: Jul  6 2009 00:43:01)
Copyright (C) 2009 SplinterGU
This utility comes with ABSOLUTELY NO WARRANTY.
moddesc -h for details

Module name: mod_math.dll

Constants:

INT PI = 180000


Functions:

FLOAT ABS(FLOAT)
FLOAT POW(FLOAT, FLOAT)
FLOAT SQRT(FLOAT)
FLOAT COS(FLOAT)
FLOAT SIN(FLOAT)
FLOAT TAN(FLOAT)
FLOAT ACOS(FLOAT)
FLOAT ASIN(FLOAT)
FLOAT ATAN(FLOAT)
FLOAT ATAN2(FLOAT, FLOAT)
INT ISINF(FLOAT)
INT ISNAN(FLOAT)
INT FINITE(FLOAT)
INT FGET_ANGLE(INTEGER, INTEGER, INTEGER, INTEGER)
INT FGET_DIST(INTEGER, INTEGER, INTEGER, INTEGER)
INT NEAR_ANGLE(INTEGER, INTEGER, INTEGER)
INT GET_DISTX(INTEGER, INTEGER)
INT GET_DISTY(INTEGER, INTEGER)

Code Select Expand

Module Describe v1.1 (Build: Jul  6 2009 00:43:01)
Copyright (C) 2009 SplinterGU
This utility comes with ABSOLUTELY NO WARRANTY.
moddesc -h for details

Module name: mod_mathi.dll

Constants:

INT PI = 180000


Functions:

FLOAT ABS(FLOAT)
FLOAT POW(FLOAT, FLOAT)
FLOAT SQRT(FLOAT)
FLOAT COS(INTEGER)
FLOAT SIN(INTEGER)
FLOAT TAN(INTEGER)
FLOAT ACOS(INTEGER)
FLOAT ASIN(INTEGER)
FLOAT ATAN(INTEGER)
FLOAT ATAN2(INTEGER, INTEGER)
INT ISINF(FLOAT)
INT ISNAN(FLOAT)
INT FINITE(FLOAT)
INT FGET_ANGLE(INTEGER, INTEGER, INTEGER, INTEGER)
INT FGET_DIST(INTEGER, INTEGER, INTEGER, INTEGER)
INT NEAR_ANGLE(INTEGER, INTEGER, INTEGER)
INT GET_DISTX(INTEGER, INTEGER)
INT GET_DISTY(INTEGER, INTEGER)

Parece que la diferencia está en el tipo de dato que se le pasaba a las funciones trigonométricas, nada más. Creía que había más cambios :?[/code]

[josebita]

Sabía que andaba por algún lado:
http://forum.bennugd.org/index.php?topic=1742.msg30472#msg30472

[Drumpi]

Una cosa ¿el scale_resolution no tenía un impacto muy negativo en el rendimiento? Sólo por curiosidad.
Y por otro lado ¿cómo es que es una variable a la que hay que pasarle un valor XXXXYYYY, en lugar de dos variables o una función de seteo?

[josebita]

Una cosa ¿el scale_resolution no tenía un impacto muy negativo en el rendimiento? Sólo por curiosidad.
Y por otro lado ¿cómo es que es una variable a la que hay que pasarle un valor XXXXYYYY, en lugar de dos variables o una función de seteo?

En Bennu sí tiene impacto, pero en PixTudio es muy pequeño porque se encarga la tarjeta gráfica.
Ni idea, está así por compatibilidad con Bennu, pero al paso que van los fabricantes de monitores pronto no valdrá. Estoy pensando en moverla a set_mode o crear un set_virtual_mode o algo así.

[Drumpi]

Me lo imaginaba. Le estoy dando vueltas al asunto, así que voy a pensar en voz alta para aclararme.
En principio, el juego funcionará a 320x240 en todos los dispositivos, salvo que sean 16:9, que lo harán a 400x240. El problema son los dispositivos con pantallas más grandes, que de momento sólo son PCs, los cuales no tienen problemas para mover el juego como unas 1000 veces a la vez. La cosa es ¿existe alguna plataforma con mayor resolución que 320x240 con una CPU menor a 500MHz y sin tarjeta gráfica?
Sí, con PiXTudio la gráfica me quitaría el tiempo extra del scale_resolution, pero aun me queda la incógnita de si funciona en Wiz y GP2X, si usa su aceleración HW (Wiz la tiene) y si el código es 100% portable de BennuGD a PiXtudio (dado que aun está en pañales). Podría llevar las dos versiones adelante, aunque requeriría más trabajo ^^U

Y ya ni siquiera estoy seguro de si quiero usar set de tiles de 16x16 y 32x32, sería trabajo extra para los que quieran crear gráficos propios para usar con el "juego", y habría que cambiar la generación de archivos de preview (uno de ellos, guardado en uno de los ficheros de datos), crear ventanas el doble de grandes...


Respecto a lo de los fabricantes de pantallas, yo no lo veo tan problemático: el 4K es bastante reciente, y muy pocas máquinas soportan aun esa resolución (las consolas apenas pueden llegar al fullHD con un framerate >=30fps). Incluso en los últimos años hemos dado dos pasos atrás: cuando la gente empezó a comprar portátiles en lugar de equipos de sobremesa, y cuando la gente ha empezado a comprar Android y ha vuelto a dispositivos de 800x480 (incluso Apple tuvo que bajar la resolución de uno de sus iPhone porque la GPU no tenía potencia para pintar toda la pantalla).
Siempre se puede sustituir INT scale_resolution por STRING scale_resolution, que aparte del formato xxxxyyyy acepte los valores VGA, QVGA, HD, FULL_HD, _4K... o que siga admitiendo ints, pero que aquellos valores inferiores a 10000 los tome como constantes (1 = VGA, 2 = QVGA, 3 = 800x600, 4 = 4K, 5 = 8K...).
O yo que sé, que sea inteligente y en lugar de dividir y hacer el módulo por 1000, que calcule cuántas cifras tiene el entero, coja la primera mitad para el ancho y la segunda para el alto, y en caso de que sea impar... ¿que compruebe el aspect_ratio?

Necesito dormir un poco... o programar un buen rato ^^U

[Drumpi]

Vale, primer escollo insalvable. Tras la inestimable ayuda del comando "reemplazar en todos los archivos abiertos" de notepad++, me ha pasado que el comando load_pal no lo pillaba, pero es que el comando pal_load tampoco. ¿Se ha suprimido? ¿Se ha cambiado de librería? ¿Falta por implementar? ¿Tengo que mandar a Drumpi castigado de cara al firewall?

Y eso, que ¡¡EL COMPILADOORRRRR!!! tampoco me ha cambiado los nombres de la otra versión del proyecto en conversión. Yo metí todos los ficheros de código en la carpeta src y le di al botón, pero no sé si es porque tenían la extensión .inc/.h o porque estaban en subcarpetas, o porque hice algo mal, pero no hubo conversión.

[La momia que fuma]

Mucho me temo que en pixtudio no hay paletas ni soporte 8 bits...

[panreyes]

Hay algo de soporte de 8 bits. Yo lo uso para mapas para durezas, pero no puedes mostrar mapas por pantalla en 8 bits porque OpenGL no deja. Pal_load ha muerto y mucho... pero es que estamos en el año 2016 xD

Llamadme terrorista, pero las paletas de colores, si bien sirven para hacer que el mismo gráfico de arbusto te sirva como nube, o para hacer pequeños efectos o animaciones, son cosa del pasado. De hecho, dudo que las t. gráficas soporten eso.

El futuro son los shaders! xD

[JaViS]

Hay algo de soporte de 8 bits. Yo lo uso para mapas para durezas, pero no puedes mostrar mapas por pantalla en 8 bits porque OpenGL no deja. Pal_load ha muerto y mucho... pero es que estamos en el año 2016 xD

Llamadme terrorista, pero las paletas de colores, si bien sirven para hacer que el mismo gráfico de arbusto te sirva como nube, o para hacer pequeños efectos o animaciones, son cosa del pasado. De hecho, dudo que las t. gráficas soporten eso.

El futuro son los shaders! xD

De eso no hay duda, pero es un feature lindo para contar, cuando quieres cambiar de color graficos en pixelart es muy util

[Drumpi]

+1. Yo contaba con ellas para diversos efectos gráficos, como cambiar de color a personajes, crear ciclos dia/noche, o reducir el uso de recursos en máquinas pequeñas.

No voy a decir que no me planteara de antes pasarme a los 16bits con este proyecto, pero es que entonces no puedo hacer un port rápido, porque todo el proyecto está elaborado para 8bits (GP32).

[josebita]

Como bien dicen Momia y Pixel, los gráficos a 8bpp no están soportados para el dibujado y por tanto las paletas tampoco, sorry. Símplemente es mucho jaleo para lo que me aportan ahora mismo (recordad que PixTudio está todavía en fase de cambios por todos los lados).

PERO mi objetivo es que el renderizador final no esté basado en SDL->OpenGL sino en OpenGL directamente. Cuando tenga eso, podré volver a implementar soporte para paletas (y otras muchas cosas) mediante shaders.

El código de soporte de paletas no lo he quitado, sólo el acceso desde PixTudio. No quería dejar funcionalidad rota que no tengo posibilidad de arreglar pronto.

Si os parece, os agradecería que me pusiérais un bug report aquí:
https://bitbucket.org/josebagar/pixtudio/issues?status=new&status=open
Os voy a contestar lo mismo que por aquí, pero dejaré el bug abierto y quedará como "TODO".