FPG Editor v 4.0

[DCelso]

A ver. No dramatices. Tanto la versión anterior como ésta no rompen las especificaciones de fpg.
Ambas generan un gráfico de un bit normal y corriente donde la información que necesito las guardo en sus campos name y filename. El formato estaba ya diseñado para soportar codigos de mas de mil. La limitación de 999 era por memoria. Pero el código se guarda en un dword de 32 bits. Asi que formalmente la especificación tolera hasta  añadir 2^32 imágenes. La limitación a 999 no la da la especificación fpg si no la limita el lenguaje que lo usa. Dicho esto he cambiado de 1001 a -1, innecesariamete ya que la especificación fpg lo permite. Pero si necesariamente para guardar compatibilidad hacia atrás. Estoy casi seguro que div permitirá dicha modificación. Ya que ni creo que sea capaz de llegar más lejos de lo que llega 16 bits por lo que ni existirá para el este gráfico. De todas formas div solo usa fpgs de 8 bits. Y ya el formato soportaba Un campo para guardar la densidad de bits. Si el fpg de 16 o 32 no rompen la especificación. Entonces por qué el grafico 1001 lo va a hacer?
Siendos justos, un editor fpg ajustado a la especificación fpg debería mostrar todas las imágenes que su campo code sea capaz de direccionar. No solo 1 al 999. Por lo que lo más justo es decir que ninguno estamos cumpliendo la especificación del formato. Ya que si lo hubieras hecho habrías sido capaz de ver la imagen 1001 y haberla borrado como cualesquier imágen. Por ejemplo Fpgedit 2009 y 3.0 eran capaces de hacer eso.

[Futu-block]

2³²
jijiji puedo hacerlo

[darío]

Me sigue pareciendo un hack, pero al final es ponerse de acuerdo...

Almenos saber si la politica debe ser que se muestren los gráficos o que se ignoren. X la simple razón de que como ya he dicho somos pocos entiendo que un poco de homogenización no nos hace mal...

En mi caso yo genero un error a propósito si el código sale del intervalo 1...999. Cambiarlo me cuesta poco pero no me entusiasma idea de mostrar un grafico que no se ve en otros lados...

La pregunta de lo de div es por curiosidad ya q el codigo fuente de fénix y bennu lo conozco pero imagino que si has dado sopprte a los gamma de div es xq quieres q sea compatible con div. No tengo ni idea de como reacciona div si ve un codigo -1 y x eso preguntaba.

[darío]

2³²
jijiji puedo hacerlo

Espero que nadie haya hecho un editor que inicialice un array al código más alto encontrado xD

[DCelso]

2³²
jijiji puedo hacerlo

Espero que nadie haya hecho un editor que inicialice un array al código más alto encontrado xD

;D .
Oye, pues no sería mala idea que todos los editores usaran ese gráfico de 1 pixel para guardar el programa y la versión con la que se hizo el fpg. a mi he ha sido util para detectar fallos y saber desde cuando estaban o cuando desaparecieron.

Por ejemplo una cosa que me choca es el formato de 1 bit, los fnx de 1 bit la informacion se guarda de una forma, y en cambio los fpg de 1 bit la información la guardan de otra forma. El fnx rellena con ceros por filas para ajustarse a multipos de byte. en cambio el fpg lo hace al completo rellena al final con ceros para ser múltiplo de 8 :D.

Eso es lo que más trabajo me costó de entender y lo que ha hecho que siempre existan fallos en esos formatos.
Creo que la diferencia está en que uno lo hizo slaine y otro splinter
( :P ,  porque en fenix no he conseguido abrir los fpgs de bit, o bien no los soporta o bien tienen un fallo que splinter ha corregido. )

[Futu-block]

Eso es, asi de simple, poneos de acuerdo y hacer un estandart de fpg...

¡¡Estais escribientrdo la historia!!

y no es broma

[Drumpi]

Es que el problema que tenemos aquí es que el formato FPG se especificó en DIV, y no se puede modificar. Los FPG de Fenix son una extensión de aquel formato, pero se las ingeniaron para que DIV no pudiera cargarlos.

Darío, te doy la razón en que la solución planteada es una chapuza en toda regla. En teoría, un programa con comprobación de integridad de formato debería rechazar de golpe el FPG con un código diferente a los que acepta, y DCelso tendría que omitir dicha información. Sin embargo, hemos respetado el formato usando un "vacío legal" dentro del mismo, ya que el ID del gráfico tiene un tamaño (WORD o INT, no recuerdo) y cualquier valor que quepa en esos bits es válido (no he visto en la documentación que se diga que tiene que valer entre 1 y 999).
Ten en cuenta que la limitación de 1000 gráficos viene dada porque tanto DIV, como Fenix y Bennu, ponen como ID de un mapa creado con NEW_MAP, CLONE_MAP o similares, un valor >=1000 (en realidad, DIV usaba valores impares, por lo de true y eso), usando el FILE = 0, que también era un identificador válido de LOAD_FPG... lo cual también es un fallo de diseño en sí mismo (se debería haber reservado un ID de FILE específico para mapas creados en memoria).

¿Lo que hemos metido al FPG de DCelso es un hack? tal vez, pues nos hemos valido de una inseguridad del sistema ¿Rompe para algo la ejecución del programa? Creo que no. No lo he probado en DIV, y sabemos a ciencia cierta que ni Fenix ni Bennu van a tener problemas a menos que se creen 2³² mapas en memoria. Habría que probar en CDIV y demás DIV-likes, pero mientras no falle, ni se considere un riesgo de seguridad, y se modifique el código para corregirlo, el punto de DCelso es totalmente válido.

He visto formatos en los que puedes hacer cosas aun más burras que esta (por ejemplo, los PNG animados no son un estandar y han sido soportados por muchos programas, incluidos navegadores como Firefox o Chrome), y si te pones a leer todos los campos opcionales que contiene un JPEG te puedes tirar de los pelos (sí, el sistema de geolocalización de la imagen forma parte del estandar, y muchas más cosas).

Dicho esto, que conste que en su día ya le dije a DCelso que ese "mapa 1001" no me gustaba, que podría traer problemas (y de hecho, he sido yo el primer danmificado :D) y que prefería mi FPG limpio, y seguí usando FPG Edit 2005. Si estoy pensando en cambiar es porque voy a necesitar en un futuro cercano un editor de FNT que importe desde TTF (me da pereza buscar el FNT Edit ^^U), y un editor con soporte 32bits, cosa que FPG Edit carece (si no te importa, DCelso, voy a seguir con mi notepad++, que ya me he hecho a mi esquema personalizado de colores :D).

Además, no es el único editor que hay, aunque sí para Linux, y si no, con el propio Bennu se puede crear un editor propio (o con un simple código se puede eliminar ese "mapa extra": LOAD_FPG, UNLOAD_MAP, SAVE_FPG, CHIMPÚN) ;)

[DCelso]

Éxito total, una descarga WOW.

Iba a decir que si encontrábais algún bug o algo incoherente o mejora lo comentárais, pero visto lo visto...

;D ;D

[Futu-block]

No, no encuentro ningun bug...
será que en linux no rula??

mierda, he de probarlo, matarme


vale, po no, es el que uso habitualmente, y funca bien en linux bajo wine o lo que sea...

[alicesimu]

Éxito total, una descarga WOW.

Iba a decir que si encontrábais algún bug o algo incoherente o mejora lo comentárais, pero visto lo visto...

;D ;D

Yo me lo vaje, ya que el pixtudio carece de la versión 32bits del editor.
Me gusta tener las dos opciones, y lo mire por encima todas las opciones, abrir un fpg de 16,32bits ,generar alguna fuente de prueba.
Y el micro editor de código .prg que tiene un conversor de charset.
Aun que el notepad++ se puede cambiar de formato tambien.

Esta noche lo probare mas...

[Futu-block]

*bajé

[darío]

Éxito total, una descarga WOW.

Iba a decir que si encontrábais algún bug o algo incoherente o mejora lo comentárais, pero visto lo visto...

;D ;D

DCelso hay que tener un poco de paciencia... hay más editores FPGs que usuarios en estos días xD.

Yo lo acabo de descargar y probar. Quería sobretodo probar la compatibilidad con mi editor aunque aprovecho para hacerte comentarios:

   
• El programa no me ha fallado en las pruebas que he hecho
• Podrías añadir unos tooltip a los botones de la barra de herramienta
• A primeras, no me ha resultado evidente que el combo box de abajo a la derecha fuera para convertir el Fpg a otras densidades, y sobretodo me esperaba que me hubiese pedido confirmación.

Por otro lado, me ha dado por controlar el código de PixTudio y por lo que veo la solución adoptada es análoga a la que hice yo en Smart Fpg Editor. Si bien los FPGs de FPG edit van a funcionar, van a generar un Warning. Y en cualquier caso, es solo porque da la casualidad que escribes el gráfico fantasma al final del fichero. Solo para que lo sepas.

Code Select Expand

       
// Warn when detecting a malformed FPG file and stop reading
// This should not happen anymore
if(chunk.code < 1 || chunk.code > 999) {
if(debug) {
PXTRTM_LOGERROR("Malformed FPG detected '%s'\n", fp->name);
PXTRTM_LOGERROR("This FPG file contains a graph with code %d\n", chunk.code);
PXTRTM_LOGERROR("but FPG files should not contain map with codes > 999 or < 1\n");
PXTRTM_LOGERROR("You can expect weirdness\n");
}

break;
}


[master]

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.

WOW, cantidad de cambios desde que fui tester de FPG Editor XD


Le encontré algunos detalles:
Probé creando un nuevo FPG (fpg prueba 1), y vacío decidí pasarlo a 8 bits, me manda un mensaje que no hay imágenes, y luego agrego imágenes, al guardar, me guarda un FPG en 32 bits (con las imágenes en 32 bits), a pesar de que la caja de abajo indica 8 bits. Después elijo 32 bits y vuelvo a pasarlo a 8 bits, aquí se convierte correctamente y paso a ver la paleta de colores, es correcta. No guardé el FPG después de este ultimo cambio.
Creo un nuevo FPG y agrego imágenes que son totalmente diferentes a las que usé en el FPG de prueba 1, pero ahora decido trabajar íntegramente en 32 bits y guardar, después voy a ver la paleta de colores y esta corresponde a la paleta de colores del FPG de 8 bits del cual no guarde sus cambios (FPG prueba 1). (Al parecer no se limpia la paleta de colores en el programa, sino que muestra la ultima utilizada, eso podría confundir un poco. mas aun si se está trabajando en 8 bits).


Con esto narrado enlisto:
Bug:
*Muestra la paleta del ultimo FPG de 8 bits trabajado, aunque se esté trabajando con un FPG nuevo o diferente en otra densidad de color.
*El modal de Guardar cambios aparece siempre aunque le hayas clicado a "NO", a pesar de que se está editando un FPG que no tiene cambios. Esto sucede si un FPG al cual le hiciste cambios no lo guardaste (Le diste a "NO"), desde ahí te preguntará en todos los que abras a pesar de no tener cambio alguno.
*El Sub-menú Porta papeles del menú Archivo nunca se activa (creo que no se puede copiar, pegar aun?)


Recomendaciones:
*Creo que solo haría falta una función para poder importar, exportar y editar (dentro del FPG Editor) paletas de colores.
*Agregar las funciones de Copiar y Pegar del porta papeles.
*Permitir al usuario seleccionar el color con el cual el editor pintará los gráficos de 1 bit en la lista (No había visto que el editor permite cambiar el color del fondo, pero tal vez si se hiciera en automático que se pinten las imagenes de 1 bit en el color complementario al fondo o configurar el color en el cual se pintarán) ya por default FPG Editor los pinta blancos, y como el fondo es blanco, no se ven a no ser que los seleccione el usuario.
*Agregar (para cualquier caso, ya sea en formatos FPG o FNT) una pequeña sección que nos permita escribir con el archivo que se está trabajando, para visualizar como se verá en Bennu o Fenix o DIV o Pixtudio. Como lo que tiente el Generador de fuentes. Esto podría ayudar a que los usuarios que creen sus fuentes desde cero, y puedan ajustar los "offset x" y "offset y" de las fuentes desde el Editor, y no tener que importar su fuente al generador de FNT para probar sus cambios. Es más, sería muy bueno poder editar la fuente y ver los cambios en tiempo real con un ejemplo de la letra mostrando de manera detallada el offset "x" y "y" frente a otra letra o arriba de otra, etc, así como la siguiente imagen de FontForge (con las lineas que muestran la separación entre letras o las que te indican la altura o la parte media de la letra, eso lo hice a mano cuando trabajé con fuentes no latinas).:



*Agregar una forma de editar campos de manera masiva, ya sea nombre, los puntos de control en el caso de los FPG y offsets en caso de los FNT.


Bugs en el Generador de FNT:
*Las fuentes que se generan menores e 15 puntos tienen problemas al dibujarse (o convertirse?), adjunto una imagen que muestra eso:



Recomendaciones:
*Agregar la posibilidad de importar paleta de colores desde FNT, actualmente el generador de FNT permite importar fuente de FPG, PAL, BMP y PCX. NOTA: no he probado esa funcionalidad.
*Agregar la posibilidad de generar un FNT (a partir de un TTF) eligiendo los caracteres (por ejemplo, con rangos), esto permitiría generar fuentes FNT con caracteres no latinos, o mas bien, de codificación diferente a la que tenemos configurado el ordenador.
Esto ultimo lo pido porque hace tiempo trabajé en un proyecto y me fue complicado generar un FNT de caracteres cirílicos (ruso). Ya que agarré maña, me pude apañar también un FNT en esperanto, francés y japones, pero todo muy artesanal.




Eso es todo, agregaría al final una petición que no se si es muy descabellada, pero por lo que leí en el Hilo, sería posible un FPG que tenga menos de 999 imágenes pero sus códigos sean mayores a ese rango, me explico mejor:
Archivo1.FPG contiene 999 imágenes con indices de 0 a 999
Archivo2.FPG contiene 999 imágenes con indices de 999 a 1999
etc...
...
...


Si se puede, sería genial que se pudiese añadir una función para desplazar un FPG mas allá de los 999, a riesgo de que el usuario use menos de 999 gráficos en un Archivo.


Sería todo. Saludos, y felicidades por la nueva versión!!!.


PD: Todo esto lo probé desde una computadora con Windows 7 de 32 bits

[DCelso]

v4.0.4 disponible.

[DCelso]

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.

WOW, cantidad de cambios desde que fui tester de FPG Editor XD


Le encontré algunos detalles:
Probé creando un nuevo FPG (fpg prueba 1), y vacío decidí pasarlo a 8 bits, me manda un mensaje que no hay imágenes, y luego agrego imágenes, al guardar, me guarda un FPG en 32 bits (con las imágenes en 32 bits), a pesar de que la caja de abajo indica 8 bits. Después elijo 32 bits y vuelvo a pasarlo a 8 bits, aquí se convierte correctamente y paso a ver la paleta de colores, es correcta. No guardé el FPG después de este ultimo cambio.
Creo un nuevo FPG y agrego imágenes que son totalmente diferentes a las que usé en el FPG de prueba 1, pero ahora decido trabajar íntegramente en 32 bits y guardar, después voy a ver la paleta de colores y esta corresponde a la paleta de colores del FPG de 8 bits del cual no guarde sus cambios (FPG prueba 1). (Al parecer no se limpia la paleta de colores en el programa, sino que muestra la ultima utilizada, eso podría confundir un poco. mas aun si se está trabajando en 8 bits).


Con esto narrado enlisto:
Bug:
*Muestra la paleta del ultimo FPG de 8 bits trabajado, aunque se esté trabajando con un FPG nuevo o diferente en otra densidad de color.
*El modal de Guardar cambios aparece siempre aunque le hayas clicado a "NO", a pesar de que se está editando un FPG que no tiene cambios. Esto sucede si un FPG al cual le hiciste cambios no lo guardaste (Le diste a "NO"), desde ahí te preguntará en todos los que abras a pesar de no tener cambio alguno.
*El Sub-menú Porta papeles del menú Archivo nunca se activa (creo que no se puede copiar, pegar aun?)


Recomendaciones:
*Creo que solo haría falta una función para poder importar, exportar y editar (dentro del FPG Editor) paletas de colores.
*Agregar las funciones de Copiar y Pegar del porta papeles.
*Permitir al usuario seleccionar el color con el cual el editor pintará los gráficos de 1 bit en la lista (No había visto que el editor permite cambiar el color del fondo, pero tal vez si se hiciera en automático que se pinten las imagenes de 1 bit en el color complementario al fondo o configurar el color en el cual se pintarán) ya por default FPG Editor los pinta blancos, y como el fondo es blanco, no se ven a no ser que los seleccione el usuario.
*Agregar (para cualquier caso, ya sea en formatos FPG o FNT) una pequeña sección que nos permita escribir con el archivo que se está trabajando, para visualizar como se verá en Bennu o Fenix o DIV o Pixtudio. Como lo que tiente el Generador de fuentes. Esto podría ayudar a que los usuarios que creen sus fuentes desde cero, y puedan ajustar los "offset x" y "offset y" de las fuentes desde el Editor, y no tener que importar su fuente al generador de FNT para probar sus cambios. Es más, sería muy bueno poder editar la fuente y ver los cambios en tiempo real con un ejemplo de la letra mostrando de manera detallada el offset "x" y "y" frente a otra letra o arriba de otra, etc, así como la siguiente imagen de FontForge (con las lineas que muestran la separación entre letras o las que te indican la altura o la parte media de la letra, eso lo hice a mano cuando trabajé con fuentes no latinas).:



*Agregar una forma de editar campos de manera masiva, ya sea nombre, los puntos de control en el caso de los FPG y offsets en caso de los FNT.


Bugs en el Generador de FNT:
*Las fuentes que se generan menores e 15 puntos tienen problemas al dibujarse (o convertirse?), adjunto una imagen que muestra eso:



Recomendaciones:
*Agregar la posibilidad de importar paleta de colores desde FNT, actualmente el generador de FNT permite importar fuente de FPG, PAL, BMP y PCX. NOTA: no he probado esa funcionalidad.
*Agregar la posibilidad de generar un FNT (a partir de un TTF) eligiendo los caracteres (por ejemplo, con rangos), esto permitiría generar fuentes FNT con caracteres no latinos, o mas bien, de codificación diferente a la que tenemos configurado el ordenador.
Esto ultimo lo pido porque hace tiempo trabajé en un proyecto y me fue complicado generar un FNT de caracteres cirílicos (ruso). Ya que agarré maña, me pude apañar también un FNT en esperanto, francés y japones, pero todo muy artesanal.




Eso es todo, agregaría al final una petición que no se si es muy descabellada, pero por lo que leí en el Hilo, sería posible un FPG que tenga menos de 999 imágenes pero sus códigos sean mayores a ese rango, me explico mejor:
Archivo1.FPG contiene 999 imágenes con indices de 0 a 999
Archivo2.FPG contiene 999 imágenes con indices de 999 a 1999
etc...
...
...


Si se puede, sería genial que se pudiese añadir una función para desplazar un FPG mas allá de los 999, a riesgo de que el usuario use menos de 999 gráficos en un Archivo.


Sería todo. Saludos, y felicidades por la nueva versión!!!.


PD: Todo esto lo probé desde una computadora con Windows 7 de 32 bits

Gracias por el feedback, muy bueno, algunas cosas que dices ya las estaba corrigiendo y ya están listas en la última versión.

Intentaré corregir todo lo que vistes.

Lo de códigos por encima de mil, no le veo mucho fuste. esos fpgs no se podrían usar en bennugd ni ningún otro divlike.

¿Qué utilidad tenías pensado darle a eso?