Portando proyecto Montezuma a PiXTudio

[Drumpi]

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.

[josebita]

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".

[Drumpi]

¡Ah! Que ni siquiera se muestran por pantalla los mapas de 8 bits. Vale, que yo pensaba que al menos se podían visualizar.

[Drumpi]

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?

[josebita]

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í.

[warrior_rockk]

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?

[josebita]

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.

[warrior_rockk]

Pero, en un modo de video de 32bits, ¿el rendimiento sera superior con texturas de 16 bits que de 32?

[Drumpi]

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.

[Drumpi]

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.

[josebita]

Gracias por la información.
Si puedes aislar el bug, anótalo en bitbucket y lo miraré.

[Drumpi]

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.

[josebita]

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.

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.

[Drumpi]

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:

Code Select Expand

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]

[Drumpi]

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?