FPG Editor v 4.0

[DCelso]

Corregido, última versión r57 disponible.

He detectado una gran carencia en mi método de usar internamente 32 bits de color para guardar las imágenes.

Resulta que si tienes una paleta de 8 bits con colores repetidos en la paleta, al guardarse la imagen, todos los pixeles que usen ese color apuntarán a la primera ocurrencia de la paleta. Por tanto aunque en la paleta se sigan conservando los colores repetidos, en la imagen no abrá pixeles que apunten a las otras posiciones distintas de la primera.

Es una carencia que es casi indetectable, pero que en juegos de 8 bits, resulta un gran problema, ya que en ellos la organización de la paleta es muy importante porque muchos juegos tienen soporte de cambio de paleta para cambiar los colores de los personajes y objetos por lo que la repetición de colores en una paleta puede representar a posta, el color de un pantalón de un personaje y el color de una lámpara (por eso están en posiciones distintas de la paleta) y al estar separadas en la paleta, al cambiar la paleta por otra podríamos hacer que el pantalón fuese verde y la lámpara amarilla, por ejemplo. Y por desgracia con esta carencia que tiene fpg-edit actualmente esta habilidad queda perdida. Tengo que hacer un cambio bastante atareado para poder recuperar esta carencia en 8 bits, y aún no tengo muy bien decidido como atacar a este problema. Como nota, he de decir que está presente en toda la rama de fpg-edit v3.1, así que si necesitais retocar fpgs de 8 bits en los que querais mantener dicha habilidad, tendreis que usar una versión anterior ésta, fpg-edit v3.0 o anteriores

[DCelso]

Versión r60 disponible ya.
Mejoras en el editor de mapas.
Bug corregido en la conversión a 8 bits, que causaba colores repetidos.

[DCelso]

Versión r62 para linux disponible.
Añadida herramienta de relleno en el editor de mapas.

[JaViS]

Sugerencia: Cada tanto estaría muy bueno que adjuntaras capturas de las novedades

[DCelso]

:), lo tenía previsto.

pero vamos yo es por incentivar, quien quiera verlo que se lo descargue y lo ejecute ;D

[DCelso]

Nueva versión r65 para windows y linux i386 disponibles.

Ahora desde el editor de mapas, puedes cambiar la paleta y las 16 gamas de colores y guardarlas. Totalmente compatible con  DIV.

[Abash]

Podría alguien confirmarme que la ultima versión para Windows se descomprime bien? Me lo e bajado 3 veces y las 3 veces al abrir con Winrar me aparece vacío aunque tiene peso.

[DCelso]

sí, las ultimas versiones de 7z no las soporta bien winrar.
prueba con botón derecho extraer en, sin abrir winrar.
o actualiza winrar a la última beta, o bájate 7zip.

[Abash]

Ya tenia el 7z y me daba error por eso lo intente con winrar pero ya esta, e actualizado el 7z y arreglado.
Por cierto, la traducción en euskera, tela. Hay alguna palabra que otra que puff y eso que tengo casi 40 tacos y euskaldun de toda la vida jajaja pero bueno, se agradece :)

[DCelso]

 :), quise conservar el idioma del creador de fpgedit. Y claro yo ni papa. Asi que todas las palabras nuevas que han ido apareciendolas tuve que hacer con con google. Si quieres ayudar con la traduccion, tu ayuda sera bienvenida. Solo tienes que abrir el fichero .po con tu editor favorito traducirlo y madarmelo o ponerlo por aqui.

[DCelso]

r66 para linux disponible.
Incorpora soporte de abrir fnts como fpgs.

[master]

Muy bueno lo de abrir FNT como FPG. lo revisé y noté esto:

1) Cuando intento arbir FNT's de 1 bit me dice el error: Division by zero.

2) En las demas profundidades me abre la fuente pero los codigos estan recorridos, un ejemplo: El simbolo "@" en vez de 65 me aparece como 71

3) El caja de texto con las profundidades del FPG no cambia si importar la profundidad FNT

4) El programa no me copia/importa los puntos de control del FNT al FPG

5) Tengo un FNT de 16 bits que no se exporta bien: Solo me exporta los numeros y simbolos del principio y los coloca con los codigos 225 a 256, y tengo otro FNT de 1 bit que si me exporta sin error "division by zero", pero con el mismo problema del FNT de 16 bits (Estas 2 fuentes fueron creadas con una versión anterior de tu programa, pero los demás casos expuestos es con fuentes generadas con la r65 de Windows)

6) Las fuentes no se me generan bien en la versión de linux (es un problema que persiste desde las primeras revisiones de 3.1 en linux), se generan incompletas, y mientras mas pequeñas menos se ven (ejemplo: si pruebo arial 12 en la de windows se ve pero en la de linux no)

Estaría bien que también pueda guardar en formato FNT

[DCelso]

;),
Gracias por las anotaciones, intentaré revisarlas a todas.
Yo descubrí que los fnts de DIV fallan todos, y estaba en ello, quizas se arreglen los otros fnts de camino.

Una cosa, lo de los códigos, los fnts van del 0 al 255, pero el código mínimo en fpg es 1, por lo que tendrán que ir del 1 al 256. Eso que me comentas del símbolo @, es rarísimo, necesitaría la fuente en la que pasa eso, intenta abrir la fuente primero en el generador de fuentes y darle a ver fuente, a ver en qué posición te sale ahí.

Lo de guardarlas, evidentemente, está programado ;).

Lo de las profundidades, ya te comenté que era un campo de depuración que añadí para ver que correctamente todas las imágenes se convertían bien al formato de color interno que es 32 bits, así que si te sale otra profundidad sería cuando iriamos mal

Lo de las fuentes de 1 bit, tengo que revisarlo, creo recordar que los formatos de 1 bit de fnt y fpgs son distintos y por eso no me va.

El problema de linux de las fuentes pequeñas creo que es intrínseco al sistema que uso por detrás, QT, así que tendría que cambiar a otro para ver si pasa y no es por culpa de éste, el problema es que GTK, que es el otro que podría usar trabaja en RGB en vez de en GBR como windows, por lo que tendría que swapear todas las imágenes y conllevaría un trabajo adicional importante. Asi que este problema lo dejaré para lo último.

Lo de los puntos de control del fnt, no lo pensé, ¿te refieres a los offsets, no? actualmente los estaba tratando en campos a parte, no como puntos de control, esta solución podría valer para fnts de fenix, pero para el fnt de DIV, no, ya que no tiene offset de ancho, alto ni horizontal, solo vertical.

[DCelso]

Nueva versión r67 para windows y linux disponible.
Añade soporte para guardar en .fnt y corrige los errores que había de todos los formatos al cargarlos.

[FreeYourMind]

Te voy a decir lo que me decia mi jefe  ;D

"En lugar de marear la perdiz enviando todos los dias nueva versión, envia la release sólo cuando tengas cambios mas grandes. Que así nadie lo va mirar porque estan mareados.".