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:
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:
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á...
Quote from: Drumpi on January 10, 2016, 02:10:43 PM
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".
Quote from: Drumpi on January 10, 2016, 02:10:43 PM
Lo siguiente que me ha dicho ha sido:
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).
Quote from: Drumpi on January 10, 2016, 02:10:43 PM
Ahora sí me reconoce el "_ESC", pero me da otro error:
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:
scale_quality = SCALE_NEAREST;o
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í (https://bitbucket.org/josebagar/pixtudio/issues/14/scale_resolution-is-not-honoured) te dejo un enlace al bug que, espero, será fácil de solucionar.Quote from: Drumpi on January 10, 2016, 02:10:43 PM
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.
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.
Quote from: Drumpi on January 10, 2016, 08:20:27 PM
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 (https://en.wikipedia.org/wiki/Image_scaling)).
Reviso lo de la mod_mathi.
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):
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)
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]
Sabía que andaba por algún lado:
http://forum.bennugd.org/index.php?topic=1742.msg30472#msg30472
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?
Quote from: Drumpi on January 15, 2016, 05:22:12 PM
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í.
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
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.
Mucho me temo que en pixtudio no hay paletas ni soporte 8 bits...
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
Quote from: PiXeL on January 21, 2016, 07:17:30 PM
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
+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).
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 (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".
Dame un tiempo para aprender qué es un bug y qué es una feature en PiXTudio y luego ya nos iremos a la cama... digo, empezaré a usar el bug report :D
Es que claro, eliminas las paletas pero ¿Entonces se elimina el soporte de mapas de 8bits? Porque entonces ¿cómo seleccionas el color que pones en cierto pixel? Es decir, si quiero poner un pixel azul en mi mapa de durezas, cómo sé qué color es el azul sin una paleta, aun usando near_color o como se llamase la función.
Pero bueno, estoy haciendo una montaña de un grano de arena. Como he dicho, aun estoy valorando el dar el salto a los 16 bits y esto quedaría en agua de borrajas ^^U
Dejaré esto en stand by hasta que compruebe el impacto en GP2X.
Quote from: Drumpi on January 22, 2016, 12:13:54 PM
Dame un tiempo para aprender qué es un bug y qué es una feature en PiXTudio y luego ya nos iremos a la cama... digo, empezaré a usar el bug report :D
Es que claro, eliminas las paletas pero ¿Entonces se elimina el soporte de mapas de 8bits? Porque entonces ¿cómo seleccionas el color que pones en cierto pixel? Es decir, si quiero poner un pixel azul en mi mapa de durezas, cómo sé qué color es el azul sin una paleta, aun usando near_color o como se llamase la función.
Pero bueno, estoy haciendo una montaña de un grano de arena. Como he dicho, aun estoy valorando el dar el salto a los 16 bits y esto quedaría en agua de borrajas ^^U
Dejaré esto en stand by hasta que compruebe el impacto en GP2X.
Bueno, es que técnicamente en un mapa de 8bpp no hay "azul".
BennuGD lleva incorporada una paleta del sistema que te cambia el color 126 por rgb(232, 212, 184), pero lo que "está" en la imagen es "el número" 126.
Luego ya tú cambias esa paleta y tu arbusto se convierte en nube, pero eso es otra historia.
La paleta del sistema está documentada aquí:
http://wiki.bennugd.org/index.php?title=Palette
Es decir, que tú cuando manejes en memoria un mapa de 8bpp en PixTudio (ya te digo que no lo puedes pintar, pero sí manejar en memoria) pones o buscas el color/valor "126".
¡Ah! Que ni siquiera se muestran por pantalla los mapas de 8 bits. Vale, que yo pensaba que al menos se podían visualizar.
Vale, parece ser que los problemas de portar el proyecto de estos días se debía a que algún inútil estaba leyendo datos de un fichero con Bennu que no existían :D
He probado el proyecto en GP2X, y... la verdad es que se ralentiza un poco. No algo exagerado, a ojímetro va a 40fps de los 50fps programados (tengo que probar a dejarle libre, a ver si así supera los 50fps o es realmente una limitación de la máquina, y no un fallo mío con el port). La buena noticia es que no se aprecia diferencia de velocidad entre 8 bits y 16 bits de color (usando siempre mapas de 8 bits).
Con lo cual, mi siguiente paso será repasar todo el código para modificar el set_mode a 16bits, el 2x_scale a scale_resolution, y los new_map pasarlos a 16 bits, y pintarlos con colores RGB.
Y después, volver a intentarlo con PiXTudio. No habrá pegas de usar el modo de color a 16bits ¿o si?
Quote from: Drumpi on January 29, 2016, 12:44:54 AM
Vale, parece ser que los problemas de portar el proyecto de estos días se debía a que algún inútil estaba leyendo datos de un fichero con Bennu que no existían :D
He probado el proyecto en GP2X, y... la verdad es que se ralentiza un poco. No algo exagerado, a ojímetro va a 40fps de los 50fps programados (tengo que probar a dejarle libre, a ver si así supera los 50fps o es realmente una limitación de la máquina, y no un fallo mío con el port). La buena noticia es que no se aprecia diferencia de velocidad entre 8 bits y 16 bits de color (usando siempre mapas de 8 bits).
Con lo cual, mi siguiente paso será repasar todo el código para modificar el set_mode a 16bits, el 2x_scale a scale_resolution, y los new_map pasarlos a 16 bits, y pintarlos con colores RGB.
Y después, volver a intentarlo con PiXTudio. No habrá pegas de usar el modo de color a 16bits ¿o si?
El modo de 16bits debería funcionar igual que en Bennu, sí.
Quote from: josebita on January 29, 2016, 10:56:01 AM
Quote from: Drumpi on January 29, 2016, 12:44:54 AM
Vale, parece ser que los problemas de portar el proyecto de estos días se debía a que algún inútil estaba leyendo datos de un fichero con Bennu que no existían :D
He probado el proyecto en GP2X, y... la verdad es que se ralentiza un poco. No algo exagerado, a ojímetro va a 40fps de los 50fps programados (tengo que probar a dejarle libre, a ver si así supera los 50fps o es realmente una limitación de la máquina, y no un fallo mío con el port). La buena noticia es que no se aprecia diferencia de velocidad entre 8 bits y 16 bits de color (usando siempre mapas de 8 bits).
Con lo cual, mi siguiente paso será repasar todo el código para modificar el set_mode a 16bits, el 2x_scale a scale_resolution, y los new_map pasarlos a 16 bits, y pintarlos con colores RGB.
Y después, volver a intentarlo con PiXTudio. No habrá pegas de usar el modo de color a 16bits ¿o si?
El modo de 16bits debería funcionar igual que en Bennu, sí.
Pero, en el caso de tener un proyecto de 8 bits y querer migrarlo a PixTudio, ¿daría mas rendimiento pasarlo a 16bits o da igual porque la aceleración va a forzar el modo de video a 32?
PixTudio siempre pone el modo de vídeo a 32bpp, pero las texturas que se muestran por pantalla pueden ser de 16 o 32bpp.
También podéis manejar en memoria mapas de menos profundidad para cosas como mapas de durezas y demás, pero esos no se pueden mostrar.
Pero, en un modo de video de 32bits, ¿el rendimiento sera superior con texturas de 16 bits que de 32?
Algo de rendimiento se va a perder por la conversión de RGB(565) a RGBA(8888) (a pesar de usar desplazamientos de bits), igual que se pierde con la conversión de paletas en modo 16bits.
Mi objetivo es lanzar los juegos en consolas portátiles, así que tengo que usar el modo de video más económico, pero a la vez hacerlo lo más sencillo de cara a los usuarios que quieran diseñar nuevos gráficos (y lidiar con paletas no es sencillo).
Además, por aportar algo a PiXTudio, quiero hacer la prueba de portar el código, en parte para probar lo que hay hecho, a ver si funciona usando un código "complejo", y por otro lado para seguir desarrollando en paralelo y buscar fallos. Obviamente, en el estado en el que se encuentra PiXTudio, dudo que pueda portarlo a Wiz (aunque puede funcionar bien, ya que el juego no tiene muchos requisitos), y menos a GP2X. Lo mismo me llevo una sorpresa pero un modo a 32bits en la negrita, difícil lo veo (además, creo que tenía limitaciones de HW que impedían usar modos de color de 32bits).
Por todo eso, al final, la mejor opción de mi proyecto creo que es usar modos de 16bits, e intentar hacer lo posible para que ande en PiXTudio. No sé si alguien quiere decir algo al respecto.
Primera fase completada: convertir proyecto a 16 bits.
Segunda fase completada: conseguir que el código compile y haga el amago de ejecutarse.
Versión de test: la que publicó Pixel hace un par de semanas o así, la versión ¡¡TRES!!
Síntomas detectados:
- El scale_resolution me ignora completamente, no sé por qué, tengo que comprobar si es porque es una segunda llamada a MODE_SET (se hace una primera llamada al principio del proceso MAIN, y una segunda tras leer el fichero de configuración, y debe hacerse así porque parece que en WIZ y GP2X también da problemas).
- No puedo escribir con la fuente del sistema. Puedo hacer un write_in_map (porque el cursor del menú provisional se hizo con eso y sí se ve), pero ningún "write(0,..." escribe nada.
- Puedo entrar en el "editor de habitaciones", carga y muestra correctamente los FPGs de 16 bits del entorno, pero se cuelga en alguna parte intentando mostrar una ventana de carga de FPGs que he escrito, que es de las primeras operaciones que ejecuta el editor. Sale la ventana de error de Windows adjunta en la imágen.
No entréis en pánico. Como digo es una simple compilación inicial. No he hecho ningún tipo de debug, sólo un "hola mundo" a lo bestia. Luego intentaré ir linea por línea aislando los fallos que vea y os diré si son cosa mía o de PixTudio.
(http://forum.bennugd.org/index.php?action=dlattach;topic=4159.0;attach=3417)
Gracias por la información.
Si puedes aislar el bug, anótalo en bitbucket y lo miraré.
Hala, ya está localizado. Por lo visto es un problema de la mod_dir, concretamente con el comando dirread, que crashea el programa.
Te he anotado el error en el bitbucket, con un código de ejemplo con el error aislado.
Voy a intentar crear una función debug para rodear el problema, a ver si salta algún error más... y si no, a ver si puedo aislar el que me salió con Bennu el otro día.
Si necesitas algún fichero más, me lo dices, pero vamos, que lo que hay es el pxtb.import y un .bat de compilación y ejecución.
Si te parece, seguimos la conversación por Bitbucket (te acabo de contestar por ahí) pero lo he intentado replicar y no soy capaz (que no soy capaz de que casque, vamos).
Mira a ver si me puedes pasar el fichero con los imports, o un zip con el directorio desde el que debo ejecutar el código para que casque.
Quote from: Drumpi on February 05, 2016, 04:50:13 PM
Hala, ya está localizado. Por lo visto es un problema de la mod_dir, concretamente con el comando dirread, que crashea el programa.
Te he anotado el error en el bitbucket, con un código de ejemplo con el error aislado.
Voy a intentar crear una función debug para rodear el problema, a ver si salta algún error más... y si no, a ver si puedo aislar el que me salió con Bennu el otro día.
Si necesitas algún fichero más, me lo dices, pero vamos, que lo que hay es el pxtb.import y un .bat de compilación y ejecución.
Vale, he probado con la versión que has puesto (andaba con la de dos semanas más atrás) y con esa no hay problemas. Y mira que me he leido el código fuente de dirread de Pixtudio a ver si podía localizar el fallo ^^U
Lo que sí me dice es que:
src/controles/jkey.inc:64: error: Undefined procedure ( error in token: "JOY_GETBUTTON" ).
En la wiki aparece y antes no daba error. Voy a mirar en el código a ver si es cosa mía, pero con al v20160110 no fallaba :/
EDIT: vale, olvidadlo. Ya me he leido el código fuente y he visto que ahora se llaman JOY_GET_BUTTON o JOY_GET_HAT, etc...[/code]
Vale, no sé si es el funcionamiento normal o es que hoy estoy muy dormido:
Estoy en modo 16bits. Cuando invoco RGB(255,255,255), este me devuelve -1. Si invoco RGB(255,255,255,16) entonces sí que me devuelve 65535.
Pero no importa lo que haga, porque las imágenes me tapan siempre los textos, o eso creo porque en el menú principal sí que se ven las letras cuando no hay imágenes. He probado a cambiar la TEXT_Z y el color justo antes de invocar a WRITE, y nada.
Otra cosa: veo que se va a eliminar el flag 4, pero ¿El flag 4 (transparencia) no era más rápido que usar alpha = 128?
Quote from: Drumpi on February 07, 2016, 06:08:20 PM
Otra cosa: veo que se va a eliminar el flag 4, pero ¿El flag 4 (transparencia) no era más rápido que usar alpha = 128?
Para PixTudio es indiferente usar flags=4 o alpha=128
Lo otro no lo sé sin mirar el ejemplo: mira cómo se comporta Bennu: no creo haber cambiado nada a posta en ese sentido.
Confirmado: Bennu también da -1 si en modo 32bits se usa RGB(255,255,255) en lugar de RGB(255,255,255,16). ¿Te lo anoto como mejora en el bugtracker?
También está lo de las fuentes, que quedan ocultas por los gráficos, creo. Tendría que hacer una prueba pero me da pereza :P Nah, si tengo un rato te lo miro, pero supongo que en cuanto se solucione lo de las transparencias en los gráficos de 16 bits se arreglará... eso espero ;)
Vale, tras dos horas de pruebas y más pruebas he llegado a la conclusión de que... a las fuentes no les pasa nada, es que simplemente estaba usando una fuente de 8bits ^^U He estado buscando por el disco duro una fuente de 1 bit o de 16 bits que pudiera usar (creía haber guardado la fuente del sistema de Fenix, pero creo haberla encontrado sólo en 8bits) y, eureka, ya funciona.
Ya sólo me falta sustituir los flags = 4 en las imágenes que usan transparencia y ya estará, por lo visto, totalmente portado, a falta de una intensiva batería de pruebas. De momento parece que la lista de strings, que es la parte más crítica, porque usa punteros a nodos que contienen strings, que no son muy estables, funciona bien. Y la lectura de ficheros, con ciertas operaciones a nivel de bits, la búsqueda de ficheros en las carpetas... (nota mental: probar el control con mandos USB, que debería funcionar).
(http://forum.bennugd.org/index.php?action=dlattach;topic=4159.0;attach=3423)
rgb(255,255,255) = blanco solido = RGBA(255,255,255,255) = -1
drumpi es correcto que de ese valor
Pues te tengo que mirar qué valor me devuelve RGB(255,0,0), porque en 16bits me pinta cierto cursor (un cuadrado) de color rojo, pero en PiXTudio me lo deja de color negro.
Por cierto, me temo que el fallo que tengo con el mapa 1001 (http://forum.bennugd.org/index.php?topic=4172.0) se me está reproduciendo en PixTudio. He intentado reproducirlo pero me ha sido imposible. He mirado mi código pero no he visto ningún fallo ni indicio de error, y no quiero ni pensar que sea un puntero mal colocado o un efecto secundario de mi lista de STRINGs.
Voy a seguir mirando, pero si alguien tiene tiempo y curiosidad por verlo, se lo puedo mandar por privado (prometo que esta vez el código está mucho mejor estructurado que con el Echo, con subcarpetas y todo :D).
Si alcanzas algo aislando el bug, avisa y lo reviso.
Lo que me queda por hacer es clonar el proyecto e ir eliminando ficheros de código hasta que quede reducido al editor que me está dando problemas.
En el peor de los casos se quedaría como está, y en ejecución se reduciría a tres procesos en bucle y una veintena de funciones que se ejecutan para generar mapas y listas en memoria, buscar ficheros y cargar la configuración del programa.
En el mejor de los casos, habrá unos diez ficheros de código y habría que depurar en ejecución. Sé la línea exacta donde no se modifica el gráfico, pero no sé si el problema viene de antes o de ahí.
Sé que le estoy dando mil vueltas, pero con el bug de Splinter en el renderer, el que no encontraba, por ahí suelto, y que hizo inestables las últimas releases de Bennu, lo mismo he dado con algo y no quiero descartarlo... y es en parte el mismo bug que tenía con Fenix antes del port a BennuGD, pero Fenix 0.84 era demasiado inestable para que sea el mismo problema.
Quote from: Drumpi on February 16, 2016, 01:04:49 AM
Lo que me queda por hacer es clonar el proyecto e ir eliminando ficheros de código hasta que quede reducido al editor que me está dando problemas.
En el peor de los casos se quedaría como está, y en ejecución se reduciría a tres procesos en bucle y una veintena de funciones que se ejecutan para generar mapas y listas en memoria, buscar ficheros y cargar la configuración del programa.
En el mejor de los casos, habrá unos diez ficheros de código y habría que depurar en ejecución. Sé la línea exacta donde no se modifica el gráfico, pero no sé si el problema viene de antes o de ahí.
Sé que le estoy dando mil vueltas, pero con el bug de Splinter en el renderer, el que no encontraba, por ahí suelto, y que hizo inestables las últimas releases de Bennu, lo mismo he dado con algo y no quiero descartarlo... y es en parte el mismo bug que tenía con Fenix antes del port a BennuGD, pero Fenix 0.84 era demasiado inestable para que sea el mismo problema.
Mil gracias por mirarlo, hombre :)
Por cierto, me alegro de que ya esté funcionando :) .
Te puedo exportar la fuente del sistema en 32bpp, si quieres. Me da la impresión de que ha perdido algo de calidad, pero bueno, ya lo arreglaremos :)
He intentado reducirlo lo máximo posible, pero me han quedado 38 ficheros de código (por suerte, la mitad ni vas a tener que mirarlos, y de los restantes, un tercio son de declaración de tipos y variables, con extensión .h).
De todas formas, te he incluido un txt con los pasos a seguir para probar el programa y reproducir el fallo, y una explicación del código hacia donde se hace la llamada de pintado en el mapa, con números de línea y todo. Espero que sea suficiente para llegar a la raiz del problema. Ya digo, sin acceso al buffer de la imágen o a un sistema de trace con el código fuente de Bennu/PiXTudio, no puedo hacer más.
Dime dónde te mando el fichero, son unos 150KB nada más, pero no sé si es buena idea subirlo al foro.
Otra cosa, si encuentras el fallo, lo mismo es aplicable a BennuGD, creo que el código es compatible y repite el mismo error, así que ten al tanto a Splinter de los hallazgos.
Por cierto, sí, sí que se ha perdido calidad en la fuente del sistema :D . Al menos en 16bits la mitad de los pixels son "grises". Yo tengo la fuente del sistema, pero no sé si la tengo a 8bits o a 16bits. La de 8bits no se ve en PiXtudio (aun) y la de 16bits no me la carga... pero claro, los conversores de fuentes que tengo no funciona ninguno ^^U He usado otra fuente que tenía por ahí de 16bits. No se ajusta a los gráficos, pero por lo menos sirve para testear.
Quote from: Drumpi on February 16, 2016, 07:12:48 PM
He intentado reducirlo lo máximo posible, pero me han quedado 38 ficheros de código (por suerte, la mitad ni vas a tener que mirarlos, y de los restantes, un tercio son de declaración de tipos y variables, con extensión .h).
De todas formas, te he incluido un txt con los pasos a seguir para probar el programa y reproducir el fallo, y una explicación del código hacia donde se hace la llamada de pintado en el mapa, con números de línea y todo. Espero que sea suficiente para llegar a la raiz del problema. Ya digo, sin acceso al buffer de la imágen o a un sistema de trace con el código fuente de Bennu/PiXTudio, no puedo hacer más.
Dime dónde te mando el fichero, son unos 150KB nada más, pero no sé si es buena idea subirlo al foro.
Otra cosa, si encuentras el fallo, lo mismo es aplicable a BennuGD, creo que el código es compatible y repite el mismo error, así que ten al tanto a Splinter de los hallazgos.
Por cierto, sí, sí que se ha perdido calidad en la fuente del sistema :D . Al menos en 16bits la mitad de los pixels son "grises". Yo tengo la fuente del sistema, pero no sé si la tengo a 8bits o a 16bits. La de 8bits no se ve en PiXtudio (aun) y la de 16bits no me la carga... pero claro, los conversores de fuentes que tengo no funciona ninguno ^^U He usado otra fuente que tenía por ahí de 16bits. No se ajusta a los gráficos, pero por lo menos sirve para testear.
Tengo pensado cambiar la fuente del sistema de PixTudio a una monoespaciada de 32bits, ahora que las puedo renderizar bonicas.
Mándame el paquete a josebaPUNTOgar ___ARROBA___ gmailPTOcom (yo creo que no hacía esto desde 2008)
Okis, ya te lo he mandado. Ya me contarás si ves algo.
Por cierto, te he tenido que quitar los ficheros .bat para compilar y ejecutar porque no me deja el servidor de correo. Te lo escribo aquí:
set PIXTUDIOROOT=c:/Pixtudio
set VERSION=pixtudio-beta20160126
set JUEGO=montezuma
set PATH=%PIXTUDIOROOT%/binarios/%VERSION%/;%PATH%
pxtb -g %JUEGO%.prg
pxtp %JUEGO%.dcb
¿2008 sin mandar un email? ¿en qué siglo vives? :D :D :D
Desde 2008 sin poner mi dirección en público con ARRIBA y cosas así, hombre :D
Buenas noticias.
Solucionado el "problema" del mapa 1001 (tan sencillo como borrar los mapas 1001 de los FPGs, ¡¡ojo al usar FPGEditor!!), he vuelto a probar y el "juego" funciona de lujo, exactamente igual que en Bennu (salvo el tema de que los gráficos en 16bits no tienen transparencias y que la fuente usada es diferente). Tendría que hacerle un test de rendimiento para comparar cuál es más rápido, pero en principio parece qe no hay nada roto: la asignación de punteros va bien, el paso de parámetros en ambos sentidos funciona, la lectura de ficheros es correcta en casi todas sus funciones (LOAD/SAVE y FOPEN/FREAD/FWRITE/FCLOSE, no he probado más), la lista de strings no se ha quejado ni una vez, el motor de scroll tileado y de detección de durezas tileadas funciona a la perfección...
Si te hace falta el código completo para probar, o quieres que testee nuevas versiones, no dudes en pedírmelo.
Nota mental: probar la última revisión con el "heissenbug".
Tengo un plan para el heissenbug.
Por cierto, Drumpi. ¿Por qué no pruebas el nuevo soporte para TTF en PixTudio?.
Píllate una fuente monoespaciada bonica y prueba con ella, debería ir bien.
Puedes meter la parte de la carga de la fuente en un #if tal que así:
#if __PXTP__
fnt = ttf_load("ttf/monospaced.ttf");
ttf_set_size(fnt, loquetoque);
#else
fnt = fnt_load("fnt/guarever.fnt");
#endif
Por lo demás debería ir igual.
Quote from: josebita on February 18, 2016, 09:28:02 PM
Tengo un plan para el heissenbug.
En 2016 un comando compuesto por cuatro de los mejores bugs del PiXTudio fueron notificados por un segmentation fault que no podía ser "debugeado". No tardaron en fugarse de la prisión en la que se encontraban recluídos. Hoy, buscados todavía por Josebita, sobreviven como soldados de fortuna. Si tiene usted un problema y se los encuentra, quizá pueda contratarlos: El Equipo H
XD XD XD
Quote from: josebita on February 19, 2016, 09:41:04 AM
Por cierto, Drumpi. ¿Por qué no pruebas el nuevo soporte para TTF en PixTudio?.
Píllate una fuente monoespaciada bonica y prueba con ella, debería ir bien.
Puedes meter la parte de la carga de la fuente en un #if tal que así:
#if __PXTP__
fnt = ttf_load("ttf/monospaced.ttf");
ttf_set_size(fnt, loquetoque);
#else
fnt = fnt_load("fnt/guarever.fnt");
#endif
Por lo demás debería ir igual.
Vale, te lo puedo ir mirando en algún rato que tenga. Lo del port era más experimento que utilidad al final, ya dije que el proyecto inicialmente ha sido diseñado para Wiz, y quiero mantenerlo así todo lo posible (ya descarté lo del set de gráficos de 32x32 pixels en favor de simplificar las cosas :P).
Otra cosa es que salga port de PiXTudio a Wiz, o que se haga una versión para PC/Android usando PiXTudio pero manteniendo la compatibilidad de lo que se genere (habitaciones, niveles...) con la versión de BennuGD. Este fork me ha pillado a pie cambiado y no termino de decidirme :D
Pero sí, algo para probar las fuentes puedo hacer. Quizás podría intentar de nuevo crear un conversor de FNTs/TTFs o algo así, que todavía no he encontrado ninguno que funcione bien :D :D :D
Bueno, lo de generar un fnt a partir de TFT tengo previsto integrarlo, pero me refería a que probarás a usar el ttf directamente, que debería ir bien y no sé si lo ha probado alguien aún...
Ok, puedo cambiar load_fnt por load_ttf con la fuente original de la que saqué la que tengo ahora... o buscar una fuente del sistema para copy/paste.
Además, me gustaría encontrar una fuente pixelada para mis videos. Usé la que utiliza kubuntu para la consola de comandos, pero al ponerla de tamaño 40 se ha redondeado y no se ha ensanchado :(
Lo que te digo: puedes meter el código específico de PixTudio en un ifdef y así no metes incompatibilidades en el código.
Aquí hay una, pero me han salido un montón en gugel:
http://jelloween.deviantart.com/art/Font-CHARRIOT-31137793
Es una de mis asignaturas pendientes, las directivas esas del compilador no las termino de entender.
Mensajes atrás has puesto:
#if __PXTP__
¿__PXTP__ es una etiqueta, una variable o qué? ¿Y dónde está definida? ¿Y cómo sé que existe ese valor?
Quote from: Drumpi on February 20, 2016, 06:17:13 PM
Es una de mis asignaturas pendientes, las directivas esas del compilador no las termino de entender.
Mensajes atrás has puesto:
#if __PXTP__
¿__PXTP__ es una etiqueta, una variable o qué? ¿Y dónde está definida? ¿Y cómo sé que existe ese valor?
Lo puse de cabeza y no es correcto.
La sintaxis correcta sería algo así:
import "mod_say"
Process main()
Private
string str;
Begin
#ifdef __PXT__
str = "You're running PixTudio";
#endif
#ifdef __BGD__
str = "You're running BennuGD";
#endif
say(str);
EndLas variables de preprocesador se definen, por lo general, mediante la línea de comandos al llamar al compilador, pero hay algunas que las predefine BennuGD/PixTudio.
De esa forma, lo que pongas dentro del bloque #ifdef __PXT__ sólo se ejecutará en PixTudio y lo que esté dentro del otro sólo se ejecutará en Bennu.
Es decir: no son como variables normales que el intérprete evalua. Éstas hacen que el compilador sólo tenga en cuenta ciertas partes de tu código.
De esa forma, puedes hacer:
import "mod_say"
import "mod_video"
import "mod_text"
import "mod_map"
import "mod_key"
Process main()
Private
int fnt;
Begin
#ifdef __PXT__
fnt = ttf_load("font.ttf");
ttf_set_size(fnt, 40);
#endif
#ifdef __BGD__
fnt = fnt_load("font.fnt");
#endif
set_mode(800, 600);
write(fnt, 400, 300, 1, "Hello, world!");
while(!key(_esc))
FRAME;
end
End
Ok, le he echado un ojo a estas directivas en otros lenguajes, y más o menos lo he entendido.
Lo que tenia que saber era eso, que algunas viene predefinidas por el lenguaje, sólo necesito encontrar dicha lista.
Le echaré un vistazo a ver qué se puede hacer, pero no las tengo todas conmigo. La última vez que intenté manejar cierto código entre dos lenguajes, quedó todo embarullado y lleno de bugs.