FPG Editor v 4.0

Started by DCelso, September 14, 2012, 11:08:22 AM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

DCelso

Tienes Toda la razón del mundo.

Tendré que plantearme otra forma de guardar la información si que se vea afectado el formato.


Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

Drumpi

Hombre, hay casos en los que se usa un formato para almacenar datos extra al final. Por ejemplo, los programas del Pico-8 se escriben en un PNG normal y corriente, pero justo detrás de la información del PNG (para los que no lo sepan, los programas del Pico-8 se distribuyen como un PNG, y en los navegadores y editores de imágen se puede leer la información del PNG, que es la carátula del juego, pero tras la imágen se guarda la información del binario y los recursos).
Eso se puede hacer porque, como digo, hay formatos que especifican claramente la cantidad de espacio que ocupa la información que contiene en un campo del encabezado. Supongo que es el caso del PNG.

Entiendo que DCelso ha querido hacer lo mismo. Es comprensible y hasta correcto.
La pega es que el formato FPG no tiene un tamaño fijo, ni un campo que especifique la cantidad de gráficos que contiene el FPG o el tamaño que ocupan (es más, los "MAPs" se pueden guardar en cualquier orden, y varían su tamaño en bytes en función del tamaño de la imágen y de la cantidad de puntos de control especificados). Por esa razón no se puede usar esa técnica (tiene un nombre, pero no lo recuerdo).
También es cierto que todos los programas deben hacer una comprobación de si los datos son correctos antes de realizar sus operaciones. Aquí se ha colado que Fenix y Bennu admitían mapas con ID>999 y no debía ser así. Así que, teóricamente, nadie tiene razón ni nadie se ha equivocado :D

La única solución que se me ocurre ahora mismo es que crees en los FPG un mapa cuyo ID sea el último valor disponible en ese campo (creo que era un int con signo, así que debería ser el #7FFFFFFF), y uses el campo de los pixels para añadir la información que necesitas. Así, las nuevas versiones De Bennu y demás no lo leerán por salirse del rango 1-999, y los viejos necesitarán llamar a NEW_MAP un porronazo imposible de veces antes de tener los problemas que tuve yo, con el mapa 1001. Es que no sé si con valores negativos dará error.
A menos que exista un bloque de datos opcional o sin uso que no recuerdo.
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

Futu-block

Yo necesito un nuevo formato de fpg y un nuevo fpg editor especial de "otra" manera, aunque al fin y al cabo sea lo mismo

DCelso

Quote from: Drumpi on October 24, 2016, 12:13:57 PM
Hombre, hay casos en los que se usa un formato para almacenar datos extra al final. Por ejemplo, los programas del Pico-8 se escriben en un PNG normal y corriente, pero justo detrás de la información del PNG (para los que no lo sepan, los programas del Pico-8 se distribuyen como un PNG, y en los navegadores y editores de imágen se puede leer la información del PNG, que es la carátula del juego, pero tras la imágen se guarda la información del binario y los recursos).
Eso se puede hacer porque, como digo, hay formatos que especifican claramente la cantidad de espacio que ocupa la información que contiene en un campo del encabezado. Supongo que es el caso del PNG.

Entiendo que DCelso ha querido hacer lo mismo. Es comprensible y hasta correcto.
La pega es que el formato FPG no tiene un tamaño fijo, ni un campo que especifique la cantidad de gráficos que contiene el FPG o el tamaño que ocupan (es más, los "MAPs" se pueden guardar en cualquier orden, y varían su tamaño en bytes en función del tamaño de la imágen y de la cantidad de puntos de control especificados). Por esa razón no se puede usar esa técnica (tiene un nombre, pero no lo recuerdo).
También es cierto que todos los programas deben hacer una comprobación de si los datos son correctos antes de realizar sus operaciones. Aquí se ha colado que Fenix y Bennu admitían mapas con ID>999 y no debía ser así. Así que, teóricamente, nadie tiene razón ni nadie se ha equivocado :D

La única solución que se me ocurre ahora mismo es que crees en los FPG un mapa cuyo ID sea el último valor disponible en ese campo (creo que era un int con signo, así que debería ser el #7FFFFFFF), y uses el campo de los pixels para añadir la información que necesitas. Así, las nuevas versiones De Bennu y demás no lo leerán por salirse del rango 1-999, y los viejos necesitarán llamar a NEW_MAP un porronazo imposible de veces antes de tener los problemas que tuve yo, con el mapa 1001. Es que no sé si con valores negativos dará error.
A menos que exista un bloque de datos opcional o sin uso que no recuerdo.

Buena idea.

Quote from: Futu-block on October 24, 2016, 12:25:22 PM
Yo necesito un nuevo formato de fpg y un nuevo fpg editor especial de "otra" manera, aunque al fin y al cabo sea lo mismo
ya te dije una forma, encriptando el archivo antes de guardarlo, y desencriptandolo antes de leerlo.
¿no te vale?
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

Futu-block

sip pero hay que hacerlo ''especial'' ;)...

hasta que no lo tenga claro, puede que al final no haga falta

DCelso

#365
Nueva versión 4.02, muy estable.

Probados todos los formatos que genera en fenix 0.92, versiones antiguas de bennugd, actual bennugd y pixtudio.

NOTAS:

fenix solo soporta fuentes de 1,8 y 16 bits. y ficheros de gráficos en 8 y 16 bits

Bennugd soporta fuentes de 1,8,16 y 32 bits y ficheros de gráficos en 1, 8, 16, 32 bits.

Pixtudio solo sopota fuentes y ficheros de gráficos en 16 bits (sin tratar el negro como transparente ) y 32 bits.



Prestaciones:

       
  • Convierte entre fnt y fpgs
  • Convierte entre formatos de bits
  • Soporte de fuentes de un bit. Con este tipo de fuentes, puedes cambiar el color del texto por el que quieras con set_textcolor, lo cual hace muy versatil usar este tipo de fuentes.
  • Edición de las imágenes a nivel de bits.
  • Soporte de las gamas de colores de formatos fpg del antiguo DIV.
  • Generador de ficheros fnt  a partir de las fuentes del sistema con ociones de agregado de sombras y bordes.
  • Visor de ficheros fnt
  • Editor sencillo de PRGS con compiliación y ejecución.
  • Autocompresión de ficheros para que ocupen menos espacio.
  • Herramienta de compresión de recursos.
  • Exportación de imágenes a formatos png con información de puntos de control.
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

alicesimu

Grandiosooo!!  :D :D :D

tengo ganas de probar la Tool FPG, por lo que dices es una maravilla!!

Drumpi

Quote from: Futu-block on October 24, 2016, 12:25:22 PM
Yo necesito un nuevo formato de fpg y un nuevo fpg editor especial de "otra" manera, aunque al fin y al cabo sea lo mismo

Pero mira que te gusta complicarte: crea tu propio formato, lo lees con FREAD y usas esa información con NEW_MAP y PUT_PIXEL (y NEW_FPG si sigues apegado a usar FILE).
Estoy dispuesto a hacerte el código de load, unload y save si me das los detalles del nuevo formato (tipo, tamaño y descripción de cada campo, y de cada bloque... ¡No encuentro la descripción del formato FPG por ningún lado de internet! Menos mal que lo tengo en copia local).
Lo ordenas como quieras, lo comprimimos... no me pidas que lo ofusque porque se escapa de mis conocimientos ^^U

DCelso: genial ¿Has resuelto finalmente lo de tus campos ocultos? ¿La compresión es automática o hay opción para desactivarla? Prefiero tener los FPGs descomprimidos para saber lo que me van a ocupar en memoria. Un compresor/descompresor siempre viene bien (aunque yo ya lo tengo hecho en código Bennu :P).
A ver si ya no necesito acudir a FNT Edit o DIV2 para hacer fuentes :D

Karma up!!!! (sí, el sistema de karmas sigue vigente, aunque sea el único que parece usarlo :D).
Hala, como con 1001 procesos sólo va a 9 FPS, vamos a meterle 32 veces más, a ver si revienta.
(Drumpi epic moment)

l1nk3rn3l

#368
 ;)

Gracias ahora funciona perfecto con el pixtudio... y Bennugd
sera incluido en la proxima beta de pixtudio

DCelso

Quote from: Drumpi on October 25, 2016, 01:10:30 AM
...
DCelso: genial ¿Has resuelto finalmente lo de tus campos ocultos? ¿La compresión es automática o hay opción para desactivarla? Prefiero tener los FPGs descomprimidos para saber lo que me van a ocupar en memoria. Un compresor/descompresor siempre viene bien (aunque yo ya lo tengo hecho en código Bennu :P ).
A ver si ya no necesito acudir a FNT Edit o DIV2 para hacer fuentes :D
...

Con tu truco, gracias ;).

Lo de comprimir, exacto, es configurable. Además gracias a la herramienta de compresión puedes hacerlo al final si quieres.

Lo de las fonts, ya hace tiempo que integré en fpg-editor el antiguo fnt-edit. bueno o no tanto en versiones (desde las 3.0)

Además el nuevo interfaz está copiado del antiguo DIV para que sea mas intuitivo a la gente que viene de él.
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

alicesimu

Aun me acuerdo de las viejas tools, de hace 5 años atras: FPG edit y el FNt editor.

Al abrir esta version FPG Editor v4, me vino a la cabeza la fusion de los 2 tools, pero mejorado aun mas :)

Futu-block

Quote from: Drumpi on October 25, 2016, 01:10:30 AM
Quote from: Futu-block on October 24, 2016, 12:25:22 PM
Yo necesito un nuevo formato de fpg y un nuevo fpg editor especial de "otra" manera, aunque al fin y al cabo sea lo mismo

Pero mira que te gusta complicarte: crea tu propio formato, lo lees con...
Estoy dispuesto a hacerte el código de load, unload y save si me das los detalles del nuevo formato (tipo, tamaño y descripción de cada campo, y de cada bloque... ¡No encuentro la descripción del formato FPG por ningún lado de internet! Menos mal que lo tengo en copia local).
Lo ordenas como quieras, lo comprimimos... no me pidas que lo ofusque porque se escapa de mis conocimientos ^^U

El problema es el tiempo, todavia no me hace falta, asi que todo proposito de ayuda por los demas todavia no me es util, asi que gracias y ya te llamo ;)

DCelso

Quote from: alicesimu on October 25, 2016, 08:59:56 AM
Aun me acuerdo de las viejas tools, de hace 5 años atras: FPG edit y el FNt editor.

Al abrir esta version FPG Editor v4, me vino a la cabeza la fusion de los 2 tools, pero mejorado aun mas :)

;D esa es la idea.

En teoría, fpg editor y bennugd es autosuficiente para crear juegos pequeños. ;)
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

DCelso

Añadida nueva descarga con binarios para win32 y win64 juntos.

El de linux debe esperar, por el momento el de win32 en wine va genial por si quereis probarlo también.
Monstruos Diabólicos

"A PAck of classic GAMEs For BennuGD" en desarrollo
http://code.google.com/p/apagame4be/

darío

#374
Quote from: Drumpi on October 24, 2016, 12:13:57 PM
Entiendo que DCelso ha querido hacer lo mismo. Es comprensible y hasta correcto.
La pega es que el formato FPG no tiene un tamaño fijo, ni un campo que especifique la cantidad de gráficos que contiene el FPG o el tamaño que ocupan (es más, los "MAPs" se pueden guardar en cualquier orden, y varían su tamaño en bytes en función del tamaño de la imágen y de la cantidad de puntos de control especificados). Por esa razón no se puede usar esa técnica (tiene un nombre, pero no lo recuerdo).
También es cierto que todos los programas deben hacer una comprobación de si los datos son correctos antes de realizar sus operaciones. Aquí se ha colado que Fenix y Bennu admitían mapas con ID>999 y no debía ser así. Así que, teóricamente, nadie tiene razón ni nadie se ha equivocado :D

Quizás demasiado tarde para dar mi opinión porque ya se ha adoptado esta solución.
Si bien entiendo que alguien pueda tener necesidades extra fuera del formato tal cual está definido, si la especificación del Fpg no soporta dichas extensiones, no dejan de ser "hacks al formato".

La solución que tu propones, Drumpi, lleva un cambio implicito en la especificación del formato FPG, que es añadir un requerimiento adicional que no ha existido hasta ahora:

       
  • "Si se detecta un mapa con código 0, el área de datos será ignorada"
Porque el argumento que das de que "un programa deba verificar siempre los datos que carga" no acarrea ninguna estrategia concreta de cómo debe reaccionar el programa en caso de que los datos verificados no sean correctos. Así pues, si bien es correcto asumir que un editor FPG verificará los datos del codigo, no es correcto asumir que el programa ignorará "y permitirá" esos datos extra ya que el programa puede simplemente reportar que la carga del fichero no es posible debido a que tiene "datos corruptos", puesto que como digo, no es parte de la especificación que "códigos incorrectos y su sección de datos serán ignorados".

Es más, tiene aún menos sentido cuando el código del mapa es el primer campo de 4 bytes en la sección de cabecera de cada mapa. Un programa, pese a detectar que el código es incorrecto, en este caso un "0", estára obligado seguir leyendo los restantes 52 bytes de la cabecera del mapa y luego decidir que "pese a que el código es incorrecto, voy a hacer cómo si no lo fuera, y saltarme tantos bytes como indiquen width and height ...

Decir "si funciona en BennuGD, Fenix y PixTudio entonces es correcto" es análogo al "si el programa compila entonces funciona". Que funcione en BennuGD, Fenix y PixTudio es una consecuencia de un detalle de implementación de dichos compiladores, pero no es estrictamente más correcta que los "datos extra al final".

Ahora que soporta gamas de colores, has probado en Div después de haber introducido dicho cambio? por curiosidad?

La verdad, yo solo veo tres soluciones limpias a esto:


       
  • Que se decida que ignorar mapas con código 0, y hacerlo es parte de la "especificación". Para lo cual sería aconsejable aumentar el número de versión del FPG para que programas que no soportan este nuevo requerimiento de la especificación. Logicamente esto implica el cambio de tanto pixtudio como bennu, para lo cual los responsables tendrían que dar su opinión...
  • Que se decida que el formato FPG soporte extensiones de alguna otra forma, para lo cual sería aconsejable cambiar el número de versión del FPG con las mismas implicaciones que la anterior opción.
  • Que los programas que quieran añadir información adicional lo hagan creando un archivo adicional, y no hagan hacks extraños.
Por lo pronto, con el cambio introducido en FPG Edit tanto Smart Fpg Editor como fenixlib van a dejar de ser compatibles con los Fpgs creados por FpgEdit, lo cual es una pena porque ya tuve que adaptarlos a las "particularidades" del FPG Edit....

Todo esto lo digo desde el respeto y la mutua cooperación :)
My sites:
Smart Fpg Editor - Painless FPG Edition for Bennu and PixTudio
fenixlib - .NET support for manipulating PixTudio, Bennu and Div graphic formats