No puedo pintar en gráfico 1001

[Drumpi]

Hola a todos:

Me está pasando una cosa rarísima. Tras pasar mi proyecto a 16bits, de pronto he dejado de poder dibujar sobre el gráfico 1001, es decir, el primer graph generado con NEW_MAP.
Sí, he comprobado que sea un gráfico de 16 bits, incluso he intentado usar CLEAR_MAP directamente sobre el mapa a modo de prueba y no ha habido forma de que cambiase. La posición era correcta, los flags, el alpha... Sé que no es en el código porque el gráfico se genera al entrar en un editor, y si salgo y vuelvo a entrar, entonces sí que puedo pintar sobre el nuevo mapa, es concretamente con el NEW_MAP con el código 1001.
Lo he probado con la r263 y la r307 y sucede en ambas.

¿Hay algún fallo conocido? puedo intentar aislarlo pero me va a llevar bastante tiempo, más que nada, porque es posible que al eliminar otra parte del código empiece a funcionar de nuevo, pero quiero saber si alguien ha visto algo similar antes de ponerme varios días a borrar código.

[SplinterGU]

el primer mapa es 1000, no 1001.

por lo que cuentas me supongo que estas hardcodeando ese valor (1001), tienes que obtener ese valor de new_map.

aunque un ejemplito seria genial.

[Drumpi]

No, hombre, Splinter, que no nací ayer :D
Sí, me he confundido, es el segundo (no había contado el gráfico del write_in_map del menú principal). Símplemente digo el 1001 porque es el código del gráfico que me falla, y lo sé porque he comprobado que se crea correctamente (es uno de los tres gráficos que genero para editar un mapa de tres capas).

Me gustaría poner un ejemplo, pero no puedo. Como digo, no puedo reproducir el error en otras condiciones fuera de mi proyecto, por lo que sospecho que es algo mal que debo estar haciendo con algún puntero, pero he revisado el código y no veo nada raro (salvo lo que tú decías con mi "lista enlazada de strings", tendría que probar a cambiarlas por char[]). Es eso o que hay algún bug muy concreto en el renderer que no se ha detectado hasta ahora.

Voy a probar a cambiar las strings por chars en el type que he creado para los nodos de la lista, a ver si soluciona algo. Por cierto ¿A cuantos caracteres estaban limitadas las strings?
No quiero usar CHARs porque más adelante me tocará crear cadenas con información de las herramientas, y algunas pueden contener textos bastante largos (al menos, más largas que un tuit :P). Y por favor, no me digas que la solución es crear una lista enlazada en cada nodo de la lista enlazada, que me da un patatús.

[Drumpi]

Bueno, pues he hecho el siguiente cambio:

Code Select Expand

type string_node
    string_node pointer sig;
    string sn_string;
end

por este:

Code Select Expand

type string_node
    string_node pointer sig;
    char sn_string[300];
end

Y me sigue dando el mismo fallo, o sea, que no son de las strings pisando ninguna zona de memoria. El compilador me da un:
warning: implicit conversion (CHAR to STRING)
en la linea:

Code Select Expand

temp_string+=ss_string[cont];
Siendo ambas variables de tipo string, pero ya está.

Luego, esta es la parte en la que se generan los mapas:

Code Select Expand

//Generación de las capas a editar
    re_imagen_capa[0] = new_map(320,240,16); //durezas
    re_imagen_capa[1] = new_map(320,240,16); //fondo
    re_imagen_capa[2] = new_map(320,240,16); //frente
    re_id_imagen_capa[0] = editor_imagen(0, re_imagen_capa[0], re_x0+160, 120,  0, 1);
    re_id_imagen_capa[1] = editor_imagen(0, re_imagen_capa[1], re_x0+160, 120, -1, 1);
    re_id_imagen_capa[2] = editor_imagen(0, re_imagen_capa[2], re_x0+160, 120, -2, 1);
La que no se ve es la imágen de las durezas. Editor_imagen es un proceso que toma el gráfico, las coordenadas, la Z y la región que se les pasa por parámetro y permanece congelado todo el tiempo.
Sin embargo, he alterado el orden de generación de los mapas así:

Code Select Expand

//Generación de las capas a editar
    re_imagen_capa[1] = new_map(320,240,16); //fondo
    re_imagen_capa[2] = new_map(320,240,16); //frente
    re_imagen_capa[0] = new_map(320,240,16); //durezas
    re_id_imagen_capa[1] = editor_imagen(0, re_imagen_capa[1], re_x0+160, 120, -1, 1);
    re_id_imagen_capa[0] = editor_imagen(0, re_imagen_capa[0], re_x0+160, 120,  0, 1);
    re_id_imagen_capa[2] = editor_imagen(0, re_imagen_capa[2], re_x0+160, 120, -2, 1);
Generando las durezas en tercer lugar, pero en esta ocasión es el mapa de fondo el que no se ve. Está claro que es el mapa 1001 el problemático. En todas las ocasiones, un clear_map a blanco, por ejemplo, tampoco ha servido para que se vea.

He comprobado los valores, pero esto es lo que he sacado de la consola de debug:


Ya no sé qué más mirar.[/code]

[SplinterGU]

bueno hombre, tu has dicho primero 1001 y en base a eso respondi posibles cosas que podrian pasar... vale, ahora en base a lo que dices te pregunto...

algun set_mode entre la creacion del primer 1001 y la 2da vez? si te entendi dijiste que la 2da vez que lo creas funciona.

[Drumpi]

No, no hay ningún set_mode entre medias.
Y al decir la "segunda vez", me refiero a la segunda vez que entro en el editor, pero claro, entonces se crean nuevos mapas, no se "vuelve a crear" ningún gráfico con el código 1001.

Le he preparado un paquete a Josebita, para que lo mire en PiXTudio, que sé que tiene más tiempo que tú, pero vamos, que si quieres, te lo mando a ti también. En teoría creo que funcionaría en Bennu sin cambiarlo (bueno, el PXTB.IMPORT habría que renombrarlo a BGDC.IMPORT, algún nombre de función, y los tres SET_MODE que hay). Son 38 ficheros de código, pero la mitad son de configuración de teclas, de lectura y creación del fichero de configuración, de los textos de pantalla... y he incluido un txt explicando cómo funciona el programa, el código, y cómo reproducir el error y las posibles líneas problemáticas.

[SplinterGU]

me gustaria, gracias... :)

[Drumpi]

Ok, creo que te lo acabo de mandar. Me ha costado pero creo que he encontrado tu correo en un viejo e-mail.
Lo que no incluyo es el .bat de compilación, porque no me deja el servidor de correo... pero seguramente lo probarás en Linux, así que... ^^U
Incluyo el fichero de texto para que puedas reproducir el fallo. Si lo necesitas en código Bennu, dímelo y te hago una versión exclusiva para ti :D

[FreeYourMind]

No me ha llegado nada  ;D

[Drumpi]

Tu a callar, que aquí no estamos compartiendo roms de PS2 :D :D :D

[FreeYourMind]

jaja y eso ? nadie esta compartiendo eso, mas bien hd's de mame  ;D

[josebita]

Algo veo.
En algún punto se está liando con los códigos de los FPGs. Tienes un gráfico que viene del FPG grafs/editor/editor.fpg con el código 1001 y con tamaño 1x1.
Cuando haces un map_xput, BennuGD/PixTudio tratan de pintar en él en lugar de en el mapa 1001 de "file=0".

Voy a ver por qué.
[Edito] Yo diría que el problema está en grlib_newid() en modules/libgrbase/g_grlib.c que devuelve 0 para la primera librería cargada.
[Edito 2] BennuGD/PixTudio asumen que si el código de un mapa es > 999 o < 1 entonces el gráfico está en la librería gráfica del sistema (la "0").
La función que añade un gráfico a una librería (grlib_add_map() en modules/libgrbase/g_grlib.c) comprueba eso y, si el código del mapa cumple el criterio, independientemente del número de librería que le hayas dado te lo añade a la librería del sistema, en lugar de a la que toca.
Entonces lo que está pasando es que cuando intentas cargar el gráfico 1001 del FPG, las rutinas de carga del FPG llaman a grlib_add_map() para añadir el mapa con código 1001 al FPG que estamos cargando pero, en lugar de eso, la función descarga el gráfico que tú (Drumpi) has creado con map_new() y pone éste en su lugar. Nada falla porque el gráfico es válido pero, como el gráfico 1001 que cargas de tu FPG tiene tamaño 1x1, cuando vas a pintar en él no se aprecia nada.

Entiendo que éste no es un comportamiento adecuado. Luego lo cambiaré, pero básicamente haré que el código de la primera librería cargada sea el 1, en lugar del 0.

[SplinterGU]

los fpg tienen la limitacion por definicion 1 a 999, fuera de esto no debe permitirse, lo que hay que hacer es que graficos con codigos 1001 y demas, no sean cargados.

ya que no siguen la especificacion de formato.

[darío]

No se si el FPG en cuestión tiene algún gráfico con un código mayor a 999 ni con qué herramienta se ha generado, pero descubrí el otro día que los FPGs creados con FPG Edit tienen un "footer" de 64bytes después del último gráfico que logicamente no es conforme al estándar definido en Bennu.


Puesto que los FPGs se cargan hasta "que ya no queda más información que consumir", pudiera ser que está información extra al final del archivo esté originando un "falso gráfico" con un código no válido.


Un saludo,
Dar¡io

[josebita]

Gracias a los dos por vuestras respuestas.

Haré que PixTudio se niegue a cargar gráficos de un FPG si el código es superior a 999 y, ya que estoy, haré que los códigos de FPG empiecen en 1.