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.
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.
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.
Bueno, pues he hecho el siguiente cambio:
type string_node
string_node pointer sig;
string sn_string;
end
por este:
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:
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:
//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í:
//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:
(http://forum.bennugd.org/index.php?action=dlattach;topic=4172.0;attach=3432)
Ya no sé qué más mirar.[/code]
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.
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.
me gustaria, gracias... :)
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
No me ha llegado nada ;D
Tu a callar, que aquí no estamos compartiendo roms de PS2 :D :D :D
jaja y eso ? nadie esta compartiendo eso, mas bien hd's de mame ;D
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 (https://bitbucket.org/josebagar/pixtudio/src/f2a8f2123caf3e449255db0954bb28b456a5f9a9/modules/libgrbase/g_grlib.c?at=bigmap&fileviewer=file-view-default#g_grlib.c-259)() 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.
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.
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 (https://bitbucket.org/dacucar/smart-fpg-editor/issues/4/critical-error-when-opening-fpg-edit) 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
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.
Quote from: darío on February 18, 2016, 05:35:28 PM
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 (https://bitbucket.org/dacucar/smart-fpg-editor/issues/4/critical-error-when-opening-fpg-edit) 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
genial! gracias por el dato! lo voy a revisar... :)
Quote from: josebita on February 18, 2016, 05:43:45 PM
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.
me parece que no es necesario... ademas, se me ocurre muchos juegos que esperan 0 como fpg cuando hay 1 solo fpg... pero adelante con el fork... :)
Donde he dicho 64 es 68 lo que yo vi.
Es facil de ver con un editor hexadecimal pprqie pone algo asi como FPGEdit y la version. En el link que puse hay dos fpgs de ejemplo (uno de fpgedit y otro de smart fpg editor).
Ottia!!! Ahora recuerdo por qué dejé de usar FPGEditor. Había un bug que al guardar los mapas, te creaba un "mapa 1001" fantasma. Siempre he usado FPG EDIT 2005, y quería ir moviéndome a las nuevas herramientas, y no recordaba esto.
Lo siento a los dos por haceros perder el tiempo de forma tan lamentable. Si lo hubiera visto ni os lo decía :(
Paso a borrar todos los mapas 1001 de los FPGs y a ver si así ya funciona todo bien.
PD: Lo que no recuerdo es si LOAD_FPG devolvía algún valor de error cuando fallaba. Todas las versiones que recuerdo de DIV devolvían 0 en caso de error, que es un valor válido de FPG cargado.
Quote from: darío on February 18, 2016, 05:35:28 PM
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 (https://bitbucket.org/dacucar/smart-fpg-editor/issues/4/critical-error-when-opening-fpg-edit) 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
dario, exacto! el FpgEdit.fpg hace que se cargue un grafico 1001... ahi esta el bug... hay que fixear entre otras cosas un chequeo de integridad de formato... este supongo que ni carga toda la estructura... ya lo vere... gracias!
Podeis agradecermelo convirtiendoos todos a Smart Fpg Editor! Jajaja
Yo lo que hago en mi nueva libreria bennulib.Net es cargar tantos graficos como sea posible hasta que algo no cuadre (eof, codigo invalido, tamano invalido). Por tema de compatibilidad con öa de archivos generados con fpg edit que deben existir x ahi...
Quote from: darío on February 18, 2016, 06:03:45 PM
Podeis agradecermelo convirtiendoos todos a Smart Fpg Editor! Jajaja
No puedo dejar de insistir, no se como todavia no se han pasado.
No sé, quizás porque el repositorio está caido...
¡Un momento! ¿Ahora funciona bien? Traposo: "2016-02-18 Latest release 0.4.8-U", ¡¡¡lo has resubido ayer!!!
:D :D :D
PD: ¿He dicho que no me gustan los instaladores nada de nada?
Quote
¡Un momento! ¿Ahora funciona bien? Traposo: "2016-02-18 Latest release 0.4.8-U", ¡¡¡lo has resubido ayer!!!
No, lo que he subido ayer es un fix para que SmartFpgEditor pueda abrir los FPGs "especiales" de FPG edit. Yo no tengo la culpa de que no se ciñan al formato FPG como se deba... Pero he querido dar soporte para que podáis arreglar todos esos FPGs corruptos que habéis hecho durante todos estos años...
Si no te gustan los instaladores puedes optar por una VirtualMachine + Instalar VB6 + Seguir los pasos de como compilarlo tú mismo que me llevaron un rato escribirlos... :P
El tema del instalador está más que justificado en caso de SmartFpgEditor debido a que necesita registrar una serie de componentes COM, y sinceramente registrarlos a mano en un sistema windows moderno es un dolor de muelas... Que sí regsv32 en WoW64 que sí lo otro. El instalador es la manera más sencilla de que la aplicación funcione y el código fuente del instalador está en el mismo sitio (para que sepas lo que hace).
Una cosa más, si tuvieras algún problema con el drag&drop (que la aplicación fallase) lee la información en el issue 5 (https://bitbucket.org/dacucar/smart-fpg-editor/issues/5/win-10-and-win-8-only-drag-and-drop-from-1) con una sencilla solución.
hablando del drag & drop, estaba pensando que seria una buena feature poder seleccionar un rango de graficos a reemplazar con los que estas queriendo agregar.
Por ejemplo, selecciono los graficos del 7 al 10, que corresponden a una animacion, y cuando hago drag & drop con muchos archivos, va incrementando el grafico a reemplazar automaticamente
Es una buena sugerencia, gracias.
Puedes escribir las sugerencias que tengas como issues (https://bitbucket.org/dacucar/smart-fpg-editor/issues?status=new&status=open)? (Da gustito poder marcarlas como "resolved" jeje).
seguro :)
Quote from: darío on February 19, 2016, 07:37:34 PM
Quote
¡Un momento! ¿Ahora funciona bien? Traposo: "2016-02-18 Latest release 0.4.8-U", ¡¡¡lo has resubido ayer!!!
No, lo que he subido ayer es un fix para que SmartFpgEditor pueda abrir los FPGs "especiales" de FPG edit. Yo no tengo la culpa de que no se ciñan al formato FPG como se deba... Pero he querido dar soporte para que podáis arreglar todos esos FPGs corruptos que habéis hecho durante todos estos años...
Si no te gustan los instaladores puedes optar por una VirtualMachine + Instalar VB6 + Seguir los pasos de como compilarlo tú mismo que me llevaron un rato escribirlos... :P
El tema del instalador está más que justificado en caso de SmartFpgEditor debido a que necesita registrar una serie de componentes COM, y sinceramente registrarlos a mano en un sistema windows moderno es un dolor de muelas... Que sí regsv32 en WoW64 que sí lo otro. El instalador es la manera más sencilla de que la aplicación funcione y el código fuente del instalador está en el mismo sitio (para que sepas lo que hace).
Una cosa más, si tuvieras algún problema con el drag&drop (que la aplicación fallase) lee la información en el issue 5 (https://bitbucket.org/dacucar/smart-fpg-editor/issues/5/win-10-and-win-8-only-drag-and-drop-from-1) con una sencilla solución.
Jajaja, tranquilo, lo decía porque ya intenté descargarlo hace cuatro días cuando vi el enlace en tu firma, pero, por aguna razón, me llevó a un proyecto en blanco :D :D :D
El problema que tengo con los instaladores es que soy muy desconfiado con el código ajeno, especialmente con aquel que empieza a tocarte cosas como el registro o te instala ficheros en carpetas desperdigadas por todo el disco duro, y luego no te los borra al desinstalar. Luego tienes que formatear cada 4 años, reinstalarlo todo...
Yo, si me aseguras que es un proceso seguro, sin rastrojos posteriores, y que tu plan de dominación mundial no va a cargarse mi equipo, entonces no hay pegas :D