Nueva generación de FPG Editor. versión 4.0. Editor de recursos para programas divlike para linux y windows.
Prestaciones:
- Editor de FPGs y FNTs
- Se puede convertir entre estos formatos y sus distintas versiones.
- Generador de tipografias (FNT) a partir de las tipografías instaladas en el Sistema Operativo.
- Editor de sencillo de Imágenes SPRITE-ART.
- Se pueden editar las paletas y gamas de colores para los modos 8 bits.
- Editor de archivos de programa (PRG)
- Se pueden compilar y ejecutar.
- Compresor de recursos compatible con BenuuGD (Al realizar ésto se pierde compatibilidad con DIV y PixTudio Android).
Código fuente:https://code.google.com/p/fpg-editor/source/checkout (https://code.google.com/p/fpg-editor/source/checkout)
Descarga: en fichero adjunto.v 4.0.10.
- Mejora en la opción de usar el nombre del archivo como código de imagen, ahora odvia el texto usando solo el número que haya en el nombre del archivo.
v 4.0.8.
- Soporte para inserción y extración de puntos de control en ficheros de texto plano (.ctp).
v 4.0.7.
- Corregidos varios errores en el generador de fuentes.
- Corregido error al convertir a 8 bits.
- Apertura de nuevos formatos fpg.
- Añadida opción para usar el nombre del archivo como código de imagen.
v 4.0.4.
Modificado el módulo generador de fuentes:
- Mejorado el aspecto visual de la ventana.
- Mejorado el rendimiento a la hora de generar la tipografía.
- Corregido fallo que al generar no mostraba el texto escrito.
- Corregido fallo que no mostraba el caracter de valores por encima de 128.
- Ahora también genera tipografías con tamaño menor a 15.
- Corregido fallo en la superposición de colores entre la sombra y el texto y bordes cuando se usa transparencia.
- Corregido fallo que no guardaba la configuración de alfas y charset.
v 4.0.2.
- Eliminada dependencia de la herramienta externa zlib.
- Compresión automática de ficheros.
- Corregidos errores de cabecera en formato fnx.
- Eliminada imagen fantasma 1001,
v 4.0.1.
- Corregido error en conversión a fuentes de 1 bit
v 3.1.
- Corregidos muchísimos errores de conversión a lazarus que tenía la 3.0
- Soporte de sobreescritura de imágenes respetando los puntos de control, ahora puedes extraer una imagen, retocarla con tu editor de imágenes favorito y volverla a meter sin perder los puntos de control.
- Se le ha añadido una herramienta de generación de fuentes ( formato FNX) basada en el código de fntmake 3.0
- Se le ha añadido un visor de fnts, para ver qué caracteres hay exactamente en un fnt y sus posiciones y offests.
v 3.0
- Remasterizado para Lazarus,
- añadida exportación a pngs (nativa en lazarus), modificados diálogos de selección de directorio y barras de progreso,
- corregidos errores puntuales en la carga de muchos archivos,
- Cambiado nombre y descripción de las imágenes por nombre de archivo y nombre respectivamente para no confundirlos mas, al insertar una imagen mete el nombre del archivo sin extensión tanto en el campo nombre de archivo y nombre y ambos pueden ser modificados al darle a editar a una imagen
- NOTA: esta versión está muy verde, he estado probando todas las opciones para crear un fpg de 32bits, necesito muchas pruebas para encontrar los fallos de adaptación de código asi que bienvenido todo el que quiera probar esta nueva versión.
Acabas de volver y ya estás haciedno aportazos!
Lo estoy probando en este momento y, a diferencia de la version 2009, me va perfecto en Wine. Que alegría! Hice varias pruebas con 32b y no he tenido ningún problema tampoco.
Lamentablemente estoy muy corto de tiempo (me mudo de ciudad la próxima semana y aún no consigo a donde) así que lo probaré con mas calma después. De todas maneras si necesitas una prueba en específico hazlo saber.
has vuelto con fuerzas!!! fanstastico, karma!
Quote from: DCelso on September 14, 2012, 11:08:22 AM
[...]
NOTA: esta versión está muy verde
[...]
jajajajajajajaja y hasta el icono es verde! :D
PROBANDO! GRACIAS POR EL APORTE! :)
podrias incluir binarios linux o en su defecto los fuentes asi lo compilamos en linux?
En lazarus de linux no funciona el codigo. Algunas funciones no trabajan igual q en windows. Tengo que reimplementarlas de forma mas portable. Cuando lo tenga listo colgare la version linux. Mientras se puede usar con wine que parece que funciona bien
que pena... pero bueno, si funciona con wine, es bueno...
Que buena DCelso, me alegro que sigas trabajando en eso .. la verdad es una de las cosas que echo de menos en linux, y es un programa para fpg nativos .. q aunq con wine van medianamente bien ... lo suyo esque sea nativo. Mañana pruebo este "winiceado" y espero con ansias la version nativa (http://foro.bennugd.org/Smileys/default/tongue.gif) (con PPA ya de paso xDDDD pedir es gratis (http://foro.bennugd.org/Smileys/default/tongue.gif))
al intentar abrir un fpg me sale...
(http://forum.bennugd.org/index.php?action=dlattach;topic=3212.0;attach=2572)
falta el zlib.exe
hola yo lo probé y me sale lo mismo lo estoy tratando de usar desde Ubuntu 12.04
saludos!!!
Holas. Jejeje eso me pasa por probar con fpgs descompromidos. Se me olvidó adjuntar ese binario pero podeis sacarlo de cualquier otro fpgedit para usarlo. Tambien podeia descomprinor el fpg antes y luego abrilo desde fpgedit
ABRIENDO FPGS QUE VIENEN EN LOS JUEGOS Y EJEMPLOS DEL BENNUPACK
LOS COLORES SALEN MAL..
LO INLCUIREMOS EN EL BENNUPACK PERO SALEN ERRORES POR DOQUIER
MAS QUE EL ANTERIOR VERSION NO SE PORQUE..
Lo k sospechaba. Cambio de tecnologia. Las cosas no van del todo igual he eliminado la compatibilidad de delphi y he tenido reinplementar un puñao de cosas y ahora parece que va mejor. Probare los fpgs del bennu pacjk y a recomplilar en linux a ver ai ahora es mas compatible. Que archivos probaste?
Nueva versión más estable, he probado todos los modos y parecen ir bien, incluso el fpg de 1bit y el fpg de 24 bits. Ya viene con zlib incluido para que descomprima los fpgs.
NOTA: los fpgs guardados van descomprimidos, para comprimirlos tienes que irte a herramientas y comprimir desde el mismo fpgedit.
La versión linux va bien pero no carga las imágenes preview, tendré que seguir investigando por qué narizes la forma de mostrar imágenes que tiene este código no funciona en el lazarus de linux.
ESTAMOS ARMANDO EL BENNUPACK
PERO SEGUIMOS PROBANDO ESTA VERSION Y ES MUY INESTABLE
SE SALE A VECES CON ERROR .. SE BLOQUEA ..
PROBADO EN WIN7 Y WINXP
umh, ¿la nueva 3.0.4?
Necesitaría pantallazos para ver posibles fallos, yo la he probado en vista y no se cuelga ni para atrás. Curioso cuanto más.
EN BREVE SUBIMOS UN VIDEO
no parece tan breve :D.
por desgracia no hay tiempo asi que en breve
(http://3.bp.blogspot.com/--epOCz8QyHY/T2ttyxXrUUI/AAAAAAAABXk/UrKhcI7dvJI/s1600/1257787155442_f.jpg)
;D
(http://1.bp.blogspot.com/-9G5NDiyPwVc/TpvhqZW8BUI/AAAAAAAABaU/QHGRujbseWs/s1600/xxautocritica-breve.gif)
Versión linux disponible.
Quote from: DCelso on September 27, 2012, 07:41:24 PM
Versión linux disponible.
Me dice esto al arrancarlo por consola:
./FPGEdit: error while loading shared libraries: libgdk_pixbuf-2.0.so.0: cannot open shared object file: No such file or directory
He mirado en el synaptic y si tengo instalado esa libreria.. ni idea xDD
Tengo Ubuntu 12.04 64bits
:o . Es eso entonces, es versión 32 bits.
En cuanto pueda saco versión 64 bits.
Me he dado cuenta que lazarus es un mojón para tratamiento de imágenes tremendo.
Funciona de forma distinta en windows y linux.
Los códigos son 0 % portables.
Algunos componentes corrompen el binario y dan errores aleatorios.
Hazlo en python y lo integramos con el packager de Joseba y con el editor de texto q estoy haciendo yo en plan compadre xDDD
por favor, python no... :)
Si quieres pasarlo a c# te ayudo y hacemos un editor como dios manda
Quote from: FreeYourMind on September 29, 2012, 08:06:55 AM
Si quieres pasarlo a c# te ayudo y hacemos un editor como dios manda
tendría que hacerlo con mono
Pregunta: Splinter, por qué Python no?
le dan miedo las serpientes xDDDDD
Offtopic: jajajaj, a mi si, sobre todo las pitones.
porque es una porqueria...
por que usar cosas dificiles de mantener? que no tienen buen rendimiento? cualquier sabe que el rendimiento con phyton no es tan bueno... y no cualquiera toca python facilmente...
Esta semana que ha pasao he probado MONO en mi empresa, he portado un par de aplicaciones de windows a linux de una forma espectacular, practicamente las aplicaciones C# funcionan directamente en linux, y las que no, hacer los reajustes no lleva mucho tiempo, y mono runtime ya suele venir de serie en las nuevas distros linux.
Con lo cual portar el FPG Edit a C# significaria tenerlo tambien en Linux.
mono es una buena opcion.
pero... pero... pero python es totalmente libre, y mono viola varias patentes de microsoft que POR EL MOMENTO se lo permiten.
mono es libre, si mono viola patentes es problema de mono, no de los usuarios.
lo que leí es que muchos "tienen miedo" de que algun dia a microsoft le agarre la loca y empiece a denunciar y cancelar el proyecto. O dejar de soportarlo y que quede toda la gente/desarrolladores colgados.
creo que microsoft ha dado via libre a mono, sino hace tiempo que ya no existia
Volviendo al tema, me alegra que alguien haya continuado el desarrollo de FPGEdit, ahora mismo lo descargo para probarlo. Muchas gracias DCelso, karma más que merecido. Saludos!
Hola DCElso, me gustaria ayudarte a pasar el programa a C# y así poder usarlo tambien en Linux con mono, aparte de las mejoras que ya se podrian hacer mas facilmente al programa, como modernizar la GUI.
Veo que incluyes el src pero no toda la solución, me refiero a que no viene con el fichero de la solución .dpr.
He convertido la version 0.4 usando la tool de pago Delphi2CS, y ha convertido corrctamente un 80% del código, con lo cual ya estaria mucho mas fácil la tarea de conversion.
Faltaria convertir tu ultimo código y trabajar sobre la ultima version.
free, si lo pasas a mono, seria genial, porque no solo funcionaria en linux, sino tambien en windows.
Ahora deberia hacer como tu y ponerte tambien links para que te documentes xDDDD
Para que funcionen en mono, la mayoria de aplicaciones ni es necesario tocarlas, sólo con que tengas el runtime mono instalado ya vale, pinchas en el .exe y la aplicacion rula en Linux...
Encima que las ultimas distros de linux ya suelen venir con el runtime
Quote from: FreeYourMind on November 27, 2012, 02:30:28 PM
Ahora deberia hacer como tu y ponerte tambien links para que te documentes xDDDD
Para que funcionen en mono, la mayoria de aplicaciones ni es necesario tocarlas, sólo con que tengas el runtime mono instalado ya vale, pinchas en el .exe y la aplicacion rula en Linux...
Encima que las ultimas distros de linux ya suelen venir con el runtime
por favor, comparte de lo que fumas... quien dijo lo contrario? tu has dicho, "asi usarlo tambien en linux con mono", y estoy diciendo que al tenerlo en mono, funcionara en linux y windows.
tu fumas de la buena parece... comparte.
como sea, te estoy alentando, aplaudiendo tu iniciativa... hombre te ciegas cuando alguien te dice algo que te molesta y ya no razonas, lo mismo me atacaste en gp32spain, y al final han comentado dandome la razon a mi... y justo de la persona que menos me esperaba... cuando te digo lo de operacion basica, no lo digo con maldad, lo digo por tu bien, para que no pierdas tiempo intentando resolver cosas que son demasiado simples... son cosas basicas que un programador deberia saber y no deberias ofenderte cuando alguien te sugiere que te leas algo al respecto que te sera de gran ayuda.
Por partes Splinter.
1 - Ya sabes que nuestra amistad permite estas cosas, a veces me soprendes con tus rabietas xD
Lo del Gp32spain, perdona que te diga pero eres muy inocente, el forero no te dio la razón, hico un comentario de cachondeo que es diferente, parece que todavia no conoces ese foro y entiendes las bromas xD
2 - Para nada estoy ofendido, si estoy siempre de cachondeo, en ningun momento creo demostrar tal cosa.
3 - Sobre mono, te repito de nuevo, tu logica esta mal, tenerlo en mono no implica que funcione en linux y windows, y tenerlo en .net no implica que funcione en windows y linux.
Es facil de entender, si estas en Windows y usas .NET con C# tienes acceso a funciones de las librerias C# y tambien al resto de funciones de librerias especificas de windows, o libs en c++ del system por ejemplo. Si haces esto, usar una lib de sistema con interop services, esto logicamente no te va funcionar en linux. Ocurre lo mismo al reves, puedes programar en linux usando Mono con C# y usar libs de linux, con lo cual no funcionarias en Windows...
Afinal no sólo yo estoy aprendiendo, quien piensa que lo sabe siempre todo no sabe lo que es ser humilde.
hombre, si lo vas a pasar a mono, lo mejor seria que no uses cosas especificas del operativo...
ademas, repito, tu has dicho, "asi usarlo tambien en linux con mono"... "TAMBIEN"... si dices eso, entiendo que lo haras portable...
Si así es logicamente.
Sobre lo de Gp32spain mira que sigues hechando leña a la hoguera esa! menuda tonteria! Y si te digo que no fue un copy paste que he creado los 2 hilos al mismo tiempo y he querido mantener el titulo en los 2 tampoco te lo vas a creer...
lo mio incialmente era un chiste, tu le diste seriedad... por otro lado, ahora queria quitarme la duda...
Estaría bien que todas las herramientas que usamos en bennu "indirectamente", como un editor de texto especifico que alguno haga o el mismo FPGEdit o cualquier herramienta de apoyo (Packager) que hagamos algunos (mi nivel es bajo lo confieso) lo hagamos todos en el mismo lenguaje. Esto nos ayudaría , creo, a en un futuro unificar criterios, guis , documentación y generar poco a poco un IDE para bennu.
No se si me explico xD. Yo prefiero python, pero siempre he tenido el gusanillo de mono y la verdad es que a veces he tonteado con c#, pero nada serio. Si nos decidimos por hacerlo todos así podríamos concentrar esfuerzos y hacer algo mas grande.
¿ q os parece?
El problema es que cada uno sabe lo que sabe y se siente mas cómodo en el lenguaje que conoce, y como estas cosas son en plan ocio no mola exigir a nadie aprender algo a lo que quizás no se sienta animado. Yo por mi parte renací fpgedit en su tiempo teniendo nociones básicas de pascal pero no me siento cómodo en ese lenguaje, tengo que estar siempre tirando de google y foros para resolver algo o entender peculiaridades del código por lo que no me motiva mucho, yo me siento más cómodo en c++ o JAVA, pero es verdad que la scene necesitaba una herramienta más actualizada por lo que decidí continuar fpgedit. ahora me arrepiento un poco porque a pesar de que mi fpgedit retocado es práctico, si hubiera empleado todo ese tiempo en hacer de cero un editor en java tendríamos una herramienta multiplataforma total y no dependeríamos de intentar traducir/parchear a uno u otro lenguaje el código actual, el port que he hecho del código a lazarus me he dado cuenta que es un poco cagada, es parche sobre parche y corrección sobre corrección, además el mismo código compilado en lazarus linux o lazarus windows no dan los mismos resultados finales de la aplicación, hay cosa que van mejor en windows y otras en linux, así que es tener un programa que funciona de forma diferente en plataformas diferentes, no mola nada. Tengo una medio sorpresa preparada, que es la que me tiene off casi constante, pero no quería adelantar acontecimientos hasta no tener nada visible, pero visto lo visto y que hay planes de reconvertir el código a c#, os adelanto que es una versión partiendo de 0 total de un editor de recursos bennu en JAVA, ( a ver hasta donde llego por mis limitaciones :D) también te aviso, free, que el código que al portar el código del fpgedit a lazarus me dí cuenta de un montón de fallos de pérdida de memoria que tiene el código y que no se cómo lo haría delphi pero se comía esas cagadas que dan en lázarus excepciones tremendas de cierre de la aplicación o inestabilidad en ella, así que cuidado con el código c# resultante, puede ser caótico, también hay abusos de variables globales y funciones estáticas peligrosas, yo que tu no intentaría reutilizar nada de código y solo lo usaría como lenguaje algorítimico para rehacer las partes que veas que van siendo necesarias para tu nuevo ide en c#, hay muchas acciones del actual fpgedit que nadie o muy poca gente usa, como reconversión de formatos o inserción de imágenes en formatos raros y librerías de zips o graficos externas a delphi que van a capón en código binario en el fpgedit.
Dios ahora que lo veo, menuda parrafada que puse pa no decir nada en claro :D
yo si he sacado algunas cosas en claro que has dicho... quizas si podrias haber escrito menos... :D
pero me quedo en claro que empiezas un fpgedit desde cero en java (si no era eso, entonces no saque nada en claro)...
tambien debo decir que he usado el fpgedit 3, desde wine, y la verdad que es imposible de usar, crear un fpg es la muerte... asi que seguramente se deba a todo eso que mencionas...
yo apoyo tu idea/iniciativa de hacer un fpgedit desde cero en java.
Yo apoyaría la idea de KeoH y C#, pero es que de Java no sé nada :(
tal como dice DCElso esto lo hacemos por diversión en el lenguaje que nos he mas comodo, para curro y exigencias ya tengo a mi jefe dentro de una hora xDD
Yo hacia una sugerencia xD no pretendia que nadie se adaptara o reescribiera codigo xDDD .. aunque bien es verdad que con mono se puede utilizar C#, c++ y java entre otros ... pero lo propongo como idea para unir esfuerzos, y "estandarizar" un poco esto xDDD
Tambien acepta C ... q splinter es mas de C xDDD
Quote from: KeoH on November 28, 2012, 01:38:09 PM
Yo hacia una sugerencia xD no pretendia que nadie se adaptara o reescribiera codigo xDDD .. aunque bien es verdad que con mono se puede utilizar C#, c++ y java entre otros ... pero lo propongo como idea para unir esfuerzos, y "estandarizar" un poco esto xDDD
Tambien acepta C ... q splinter es mas de C xDDD
unir esfuerzos, suena a hacer un proyecto en comun, eso suena interesante...
vuestro proyecto de las piramides estilo castlevania, hace tiempo que lo empezasteis xDD
Quote from: FreeYourMind on November 28, 2012, 11:23:04 PM
vuestro proyecto de las piramides estilo castlevania, hace tiempo que lo empezasteis xDD
de que proyecto hablas?
Se cachondea ... De q hablamos d hacer algo grande y no hacemos nada jaja
si, ya se, pero me tiras palos a mi, y yo no estaba en el proyecto... por eso mi pregunta...
Visto lo verde que está lazarus he revertido el código para recompilar con delphi. Ahora ya podrás pasarlo a c#, free . ;)
gracias, estoy de vacas sin internet, me bajo ahora tu proyecto de nuevo. el año que viene flipareis con mis fotos xDD
edito, bueno veo que todavia no lo has subido.... y no voy a estar tan deprisa ;(
Quote from: FreeYourMind on December 22, 2012, 03:19:37 PM
gracias, estoy de vacas sin internet, me bajo ahora tu proyecto de nuevo. el año que viene flipareis con mis fotos xDD
ya quisiera yo estar sin internet y postear mensajes como tu...
Nueva versión de fpgedit, esta es la 3.0.7, es la más estable que he podido conseguir, está en lázarus (object pascal multiplataforma), soporte real de 32 bits, corregidos miles de problemas de compatibilidades y pérdidas de memoria, probado en wine con buenísimos resultados.
https://www.dropbox.com/s/og4v0bxg4g16mub/FPGEditv3.0.7.rar
Hola DCelso! Recién descargué la versión 3.0.7 y le eché un vistazo rápido, solamente encontré un error:
Todos los botones y menúes no tienen nada escrito en ellos, en vez de eso, en todos aparece "NULL". Estarán apuntando a un recurso de texto inexistente?
Por cierto, lo probé en Windows 7 - 64 bits.
¡Saludos!
También me paso lo mismo que a Outlaw, pero se solucionó cuando copie el ejecutable a la carpeta del anterior FPGedit 3 y ya me pone los textos
Es que solo subí el .exe, es decir, es un parche para la 3.0.4.
Bajaros la 3.0.4 y sobrescribirle el fpgedit.exe con el del zip de la 3.0.7.
Sorry, por no avisar, creí que era obvio.
Ok DCelso! No es obvio, pero yo tampoco leí muy detalladamente los posteos!
Guais.
Me he dado cuenta que en esta versión. La 3.0.7. En los modos 8 y 16 bits están cambiada las componentes rgb. Ya corregi el error swap. En breve subir la nueva versión
DCelso, esto lo podrias haber presentado para la crap...
EDIT: en realidad no es asi, pero tenia ganas de hacer el chiste...
:)
Nueva versión, 3.1.8.
Además de añadir lo que dije del swapeo he metido infinidad de mejoras y cambios en el core y diseño intentándolo hacer más compatible hacia wine entre otras cosas. Por favor, splinterGU, dime si te va en tu wine y ponme las trazas de error que te lanza desde un terminal, si las lanza.
https://www.dropbox.com/s/at26g52yjlllf5o/fpgedit3.1.8bin.7z (https://www.dropbox.com/s/at26g52yjlllf5o/fpgedit3.1.8bin.7z)
PD: viene con una sorpresita de regalo.
mientras la sorpresita no sea un virus o un format c:, todo festival.
Quote from: DCelso on January 28, 2013, 04:20:15 PM
Nueva versión, 3.1.8.
Además de añadir lo que dije del swapeo he metido infinidad de mejoras y cambios en el core y diseño intentándolo hacer más compatible hacia wine entre otras cosas. Por favor, splinterGU, dime si te va en tu wine y ponme las trazas de error que te lanza desde un terminal, si las lanza.
https://www.dropbox.com/s/at26g52yjlllf5o/fpgedit3.1.8bin.7z (https://www.dropbox.com/s/at26g52yjlllf5o/fpgedit3.1.8bin.7z)
PD: viene con una sorpresita de regalo.
me va en wine... no hay error... por lo menos, no al abrirlo.
abre fpg bien, no veo problemas.
:o chachi
Creo que encontré dos bugs:
Los fnt me los genera sin el ascii extendido, solo hasta el caracter 127, tengo la casilla de extendido tildada.
Solamente no me permite convertir los FPG a 8 bits, y la terminal me lanza lo sig:
err:commctrl:COMCTL32_SubclassProc Our sub classing stack got erased for 0x10080!! Nothing we can do
Por lo demás, esta muy bien. Carga muy rápido los FPG con muchas imagenes :D .
PD: Uso wine
:o, osti tú. Fallo de lazarus. En delphi no pasaba. A ver sí tiene arreglo.
Arreglado.
Hay algunos caracteres que no tienen representación, por lo que no se pintan.
https://www.dropbox.com/s/5d9yqnppbzzl047/fpgedit3.1.11bin.zip (https://www.dropbox.com/s/5d9yqnppbzzl047/fpgedit3.1.11bin.zip)
Cosas nuevas
*He cambiado el exportar e importar fuentes a bmp para que soporte 32 bits correctamente.
*He añadido un visor de los datos de una fuente y poder ver todos los caracteres generados.
*He cambiado el rango de alfas a porcentajes, ahora es de 0 a 100, en vez de 0 a 255, como antes.
*He añadido soporte de alfas para el color principal de la fuente.
*He añadido más realidad de alfa haciendo que si debajo del borde o fuente con alfa < 100 hay un pixel de sombra se entremezclen dejandolo ver parcialmente.
porque no me pasas eso por pm para adaptarlo al mio de c# ? (ya que ahora sólo nos pones binarios)
lazarus, levantate y anda!
Free, para todos los nuevos cambios tuve que romper la compatibilidad con delphi. Ahora es puro código lazarus sin vuelta a atrás fácilmente.
me alegro... :D
no importa que sea lazarus, me va servir igual, porque ya he convertido 90% del codigo
He encontrado mas bugs:
*Sigue sin convertirme los FPG a 8 bits
*Cuando genero FNT sin borde ni sombra, en 32 bits me guarda el archivo con un fondo blanco en cada letra, en 16 bits lo guarda con fondo transparente y los demas modos no me funcionan (solo guarda cuadros negros), solo me funciona si abro la fuente de 16 bits y despues guardo a 1 bit y 8 (24 no probé)
*Cuando genero FNT con borde en modo 32 bits me coloca un marco negro al rededor del cuadro del grafo, si el borde lo pongo de otro color que no sea Negro(0,0,0) el fondo me lo sigue poniendo blanco. Este punto no sucede en modo 16 bits, trabaja bien
*si abro un FNT de 32 y trato de convertir a 1, 8 o 16 bits me crea fnt's corruptos. En cambio si habro de 16 bits, puedo exportar correctamente a 1 bit y 8 bits
*Los fnt me los guarda con una codificacion diferente de como hasta ahora trabajo, en las versiones anteriores de tu programa podía poner caracteres especiales(á, ñ, ¿, etc...), pero ahora me muestra caracteres que no debe, pero en el visualizador de caracteres aparecen las letras en su lugar.
Y como sugerencia: Me gustaria que el modo de suavisado de fuente pueda activarse o desactivarse al gusto (muy buena herramienta el clear type)
Estas haciendo un gran trabajo!!!!!! :D :D
:o , jodo, entonces no te va nada, ¿no?
Yo acabo de probar en mi equipo y me va todo eso bien.
¿Que S.O. decías que tenias?
En cuanto la lo del suaviado, tendré que mirarlo más detenidamente, ahora se aplica el por defecto del sistema operativo y creo que no se puede controlar eso, estudiaré la API por si acaso.
Quote from: master on January 31, 2013, 06:56:46 AM
..
*Sigue sin convertirme los FPG a 8 bits
..
Ah, sí ese apartado lo tengo olvidado de la mano de dios, no lo veía muy útil, y creía que no lo usaba nadie :D, ya que es una opci´n de uso poco frecuente y puedes extraer las imágenes, crear un nuevo fpg en otra densidad y añadir las imágene extraídas. Quiz´s tampoco te vayan los maps, también los tengo olvidados :D, tampoco creo que los use nadie en el mundo, quizás algun despistaillo :D.
Quote from: master on January 31, 2013, 06:56:46 AM
*Cuando genero FNT sin borde ni sombra, en 32 bits me guarda el archivo con un fondo blanco en cada letra, en 16 bits lo guarda con fondo transparente y los demas modos no me funcionan (solo guarda cuadros negros)
En windows vista va, ¿estás ejecutandolo desde wine?, va a ser eso casi fijo.
En la compilación para linux pasa algo parecido, el modo 32 bits no va, lazarus lo convierte internamente a 24 bits, y eso me está trayendo por la calle de la amargura, resulta que el modo de color nativo de linux es 24 bits y los 32 bits son una emulación o algo así y lázarus no funciona muy bien con las conversiones entre estos formatos en linus, cagoen. Estoy buscando alternativas para sacar versión linux :'(
Quote
, solo me funciona si abro la fuente de 16 bits y despues guardo a 1 bit y 8 (24 no probé)
esto debe ser por lo mismo. ¿ si abres desde cualquier modo distinto de 32 bits y pasas a otro cualquiera distinto de 32 bits va?, es decir de 16 a 8 y a 1 ya veo que si. Pero ¿de 8 a 1 y a 16 y de 1 a 8 y 16?
24 bits es un formato análogo al de 16 bits solo que más preciso, a todos los aspectos se comportaría igual que el de 16 bits, actualmente ningún programa da soporte a este formato :D, fue un extra que añadí al fntedit2009 por si algún día se le daba soporte en bennu (o gem..), osea bennu. :D
No es necesario que lo pruebes porque en bennu no lo vas a poder probar, pero si quieres, prueba también de 24 a 16, 8 y 1 :D.
Quote
*Cuando genero FNT con borde en modo 32 bits me coloca un marco negro al rededor del cuadro del grafo, si el borde lo pongo de otro color que no sea Negro(0,0,0) el fondo me lo sigue poniendo blanco. Este punto no sucede en modo 16 bits, trabaja bien
Veo que va siendo lo mismo, en modos inferiores a 32 bits, el negro es el transparente, en 32 bits no, se usa canal alpha, por lo que describes parece que falla eso, no está usando el canal alfa y se comporta como un modo de 24 bits completamente por eso ves el blanco que debería ser transparente y el negro lo ves transparente :D.
Quote
*si abro un FNT de 32 y trato de convertir a 1, 8 o 16 bits me crea fnt's corruptos. En cambio si habro de 16 bits, puedo exportar correctamente a 1 bit y 8 bits
Confírmame si usas wine, a ver si es quien provoca esto, en windows vista ya te digo que va
Quote
*Los fnt me los guarda con una codificacion diferente de como hasta ahora trabajo, en las versiones anteriores de tu programa podía poner caracteres especiales(á, ñ, ¿, etc...), pero ahora me muestra caracteres que no debe, pero en el visualizador de caracteres aparecen las letras en su lugar.
Explicate mejor, ¿te refieres al texto a previsualizar? Abre la fuente,( después de guardarla o abrir una) con el visor y mira sus representaciones y dime ejemplos, con su número de posici´n me vale.
Quote from: DCelso on January 31, 2013, 03:06:31 PM
Confírmame si usas wine, a ver si es quien provoca esto, en windows vista ya te digo que va
Si estoy usando Wine sobre Ubuntu 12.10 de 64 bits.
Quote from: DCelso on January 31, 2013, 03:06:31 PM
Quote from: master on January 31, 2013, 06:56:46 AM
*Los fnt me los guarda con una codificacion diferente de como hasta ahora trabajo, en las versiones anteriores de tu programa podía poner caracteres especiales(á, ñ, ¿, etc...), pero ahora me muestra caracteres que no debe, pero en el visualizador de caracteres aparecen las letras en su lugar.
Explicate mejor, ¿te refieres al texto a previsualizar? Abre la fuente,( después de guardarla o abrir una) con el visor y mira sus representaciones y dime ejemplos, con su número de posici´n me vale.
me refiero a la hora de usar en bennugd, o incluso en tu programa, en el apartado de escribir texto de ejemplo
Por ejemplo, yo excribo:
Niño
Me aparece algo como esto
Niño
igual con otras letras del ascii extendido, pero como dije, esto pasa solo con esta versión
Entonces lo de las fuentes de 32 bits se debe a el uso de Lazarus, lo entiendo, entonces en las otras versiones usabas Delphi, en las versiones anteriores si trabajaba bien con 32 bits y todo lo indicado
umn, ¿qué versiones?, en la anterior de fpgedit? (si en algún fpgedit iba bien lo de los 32 bit dímelo, todos están en lázarus) o la última de fntedit cuado estaba separado( esta era en delphi)
Prueba esta nueva versión, he corregido un bug que hacía que no funcionara bien el cálculo de offset vertical. y ví lo que comentas de las ñs. tambien lo corregí.
https://www.dropbox.com/s/ckzlij51xzba7co/fpgedit3.1.14bin.7z
DCelso, por que no armas un paquete completo, con todas las mismas dlls que usas vos y todos los archivos? no sea cosa que los que tenemos algun problema sea por tener una dlls o algun archivo que no va?
Al parecer el problema de los 32 bits se ha ido con la versión 3.1.14. Ahora los guarda bien y puedo exportar desde 32 bits a 1, 8, 16 y 24 bits sin problemas.
No lo había revisado, pero el botón de exportar los fnt a bmp no funciona con fuentes creadas en esta versión (3.1.14). me aparece el siguiente mensaje:
"Invalid Horizontal pixel index 2560.
Press OK to ignore and risk........."
Y al intentar importar bmp (creado en esta versión pero con un FNT de una versión anterior*) me manda el error:
"Acess violation
Press OK to ignore and risk........."
*cuando digo versiones anteriores, me refiero a la version separada cuando no me guardaba el caracter 255
Confirmo que no funciona bien "exportar a map" y en el menu de ayuda, los links a las paginas de bennu, div etc... no funcionan:
"Failed to execute: 2"
:o , anonarado me dejas,¿ahora funciona? bueno pues voy a ir por partes, para ir solucionando todo lo que me dices. ¿Puedes probar de 1 a los demás bits?
Gracias tío por todo, me estás haciendo de gran betatester ;) , eso de que usen la aplicación de uno mola.
Opps, se me escapo este bug:
*Si le pongo que como fondo, como borde o como sombra use una imagen, el programa no lo toma y utiliza el ultimo color uniforme que elegí (a cualquier profundidad). Pero si abro una fuente de cualquier profundidad y luego la convierto a 8 bits (en ese momento el programa tiene las propiedades de fondo, borde y sombra seteadas con una imagen, o con un color diferente al que tiene la fuente abierta) la fuente se guarda con el fondo, borde y sombra de la imagen que elegí (o colores) mezclándose con el color que anteriormente tenia(solo pasa en 8 bits), si el color anterior de la fuente original era blanco, la imagen no sufre cambio de color. En este problema descrito, en algunos casos hasta la fuente a perdido el borde.
En cuanto a exportar de 1 bit a 32, 24, 16 y 8 bits, todo funciona correctamente.
Una recomendación: el cartelito (barra de estado) donde muestras "Creando fuente", "pintando fuente" etc... deberia tener un color de fondo fijo, porque toma el color de fondo del previsualizador, entonces si lo tienes con fondo negro, los mensajes no se ven.
No puedo abrir fpg comprimidos, en cambio si puedo abrir fnt comprimidos
Me aparece el siguiente mensaje:
Failed to execute C:\users\master\Temp\\zlib.exe -d "C:\users\master\Mis Documentos\programacion\programas\conv\fontn2.fpg" : 2.
El programa no me permite comprimir los FPG
Seria bueno tener la opción para poder comprimir también los fnt
El problema de la visualizacion del ascii extendido aun sigue, solo se solucionó en la previsualización de tu programa, pero en bennu aun tengo problemas.
Y un caso peculiar es que si intento convertir una fuente (generada en esta versión de tu programa) a fpg, los caracteres me aparecen en otras posiciones, pero no es el mismo problema de la visualización en bennu, ya que los caracteres que se ven en bennu son diferentes al orden de como aparecen en el FPG.
Te adjunto el FNT generado con la versión 3.1.14, y el FPG que obtuve al convertir desde bennugd.
no veo nada con esas fonts.
¿puedes mandarme una captura de pantalla donde señaies el, los carácteres, en cuestión?, me seria de ayuda, gracias.
(http://k43.kn3.net/2A92EFBFF.png)(http://s2.subirimagenes.com/privadas/previo/thump_2013180foros.png)
Hice esta imagen tratando de mostrar lo que te describí en mi ultimo post. Te lo explico
primero, pongo los valores ascii de las letras
segundo, pongo una fuente que se visualiza correctamente
tercero, coloco una fuente creada con la ultima version de FPGedit (3.1.14)
cuarti, Yo hice un programa que convierte una fuente a fpg (y viceversa, para editar las fuentes al gusto), pero al parecer no esta funcionando bien con las fuente generadas con la version 3.1.14 de FPGedit.
En todos los casos solo hay problema apartir del ascii extendido.
:o , en windows va correctamente.
Voy a probar en wine.
¿Puedes probarme este parche?
https://www.dropbox.com/s/ar09jh1s3u5ea7p/FPGEditv3.1.18patch.zip (https://www.dropbox.com/s/ar09jh1s3u5ea7p/FPGEditv3.1.18patch.zip)
He arreglado todo lo que comentabas excepto lo del cambio de caracteres último que comentabas, que estoy en ello.
Por mi cumple .. de regalo os dejo esto.
Código fuente liberado para todo el que quiera mirarlo y/o colaborar.
Ya iba siendo hora, ¿no?
¡¡Felicidades por tu cumpleaños, DCelso!!
Gracias por el codigo y por todo el trabajo y tiempo invertido!.
Todo ya me funciona bien, excepto lo ultimo que te comente de las fuentes (y lo de convertir un fpg a 8 bits).
Te comento 2 cosas:
*En la fuente generada desde la ultima versión, si intento ver el caracter 256 en bennugd, el juego muere
Violación de segmento (`core' generado)
*Cuando yo convierto la FNT (generada en la ultima version de tu programa) a FPG, se asemeja un poco mas a la fuente original (a como debería verse)
pero como he dicho, solo pasa con el ascii extendido
Una imagen con la representación de las fuentes completas en bennugd (desde 32 hasta 255)
(http://s2.subirimagenes.com/privadas/previo/thump_2013169osk.png)
No puse los primeros 31 caracteres porque mi fuente no los tiene.
Nota2: la primera imagen de representacion que puse estaba mal, me equivoque e invertí la fuente generada 3.1.14 con la convertida
esta seria la correcta
(http://s2.subirimagenes.com/privadas/previo/thump_2013180foros.png)
Y con el de 3.1.18 se genera lo mismo q con el 3.1.14?
Puedes pasarme el .prg para probarlo en windows?
Lo que no comprendo es que el conversor tuyo a fpg cambie las imágenes. Es ilógico total, que hace. Se las inventa?
Si, pasa lo mismo al crear fuentes tanto en la versión 3.1.14 como en la 3.1.18
Te paso el prg del conversor (es muy sencillo), lo de que cambie las imagenes mi conversor, pues no, en realidad tal vez sea problema del formato.(incluso yo no entiendo como puede pasar eso)
Nueva versión,
Corregidos problemas de visualización de fpgs de 16 bits
Corregidos conversores
Eliminado código innecesario.
http://fpg-editor.googlecode.com/files/FPGEdit3.1r5.zip (http://fpg-editor.googlecode.com/files/FPGEdit3.1r5.zip)
SplinterGU, ¿puedes probar esta ultima versión en tu wine? a ver si te arranca.
De camino a quien vaya probando la aplicación y le vea carencias, mejoras y / o fallos, le agradecería que me abriera un issue en el proyecto. ;)
https://code.google.com/p/fpg-editor/issues/list
a mi con Ubuntu 12.04 64b no me va bien .. no es estable y hace lo que quiere xDD aunque no lo he probado a fondo. Mañana le meto mas mano. Pero una cosa que me ocurre es que en la vista de los graficos que estan en el fpg, los colores salen jodidos en la vista .. despues el archivo esta correcto .. pero en el lista de imagenes esta jodido los colores. Y en el directorio con las imagenes que voy buscando para meter en el archivo, hay imagenes q no me aparece su vista previa.
:o , lo de que hace lo que quiere habrá que ser mas exacto con lo que pasa y buscar un patrón que repita el error ;)
los colores jodidos que te salen en qué tipo de fpg te sale? puedes pasarme un fpg con ese problema para estudiarlo?
también pásame una imagen (*.png, supongo) que no se te vea, para ver su formato.
oki, cuando llegue a casa esta noche lo pruebo mas en profundidad, y te mando el fpg y demás.
master, nueva versión, r9, al fin corregido el problema de character encoding.
Ahora le he dado soporte para que abra fpgs y fnts comprimidos, usa zlib para ello, que va adjunto con fpgedit.
SplinterGU, al final nunca se llegó a implementar fonts para character enconding cp850 ¿no? veo que siempre usamos iso8859_1 en todos los fonts fnx.
aun no me muestra bien los caracteres, me sigue pasando lo mismo. :(
Según veo, la fuente que me genera FNTedit (3.1.1r9) es iso8859, pero bennugd me depliega caracteres como si se tratara de cp850, pero yo lo necesito en iso8859, ademas de que con cp850 no tengo el ultimo caracter porque es el NBSP.
La posición o código de cada caracter varia según el encoding, pero en tu visor de fuentes, sigo viendo el orden de la iso8859, e incluso me dice que la fuente tiene encoding iso8859, a pesar de que bennugd no lo muestra así.
Es curioso, tengo una fuente en iso8859 (y lo se porque en bennugd se ve correctamente) y tu visor de fuentes me la reconoce como cp850(pero el orden de los caracteres en tu visor de fnt sigue siendo de la iso8859)
Estaría bien tener la opción a elegir del encoding de la fuente.
Ya puedo abrir fpg comprimidos, pero las funciones de convertir el FPG a 8, 16 (cdiv y fenix) y 24 bits no funcionan, solo funciona a 32 bits (pero no la he probado en bennugd).
En la r9 se puede elegir el character encoding a la hora de generar la fuente. Está justo arriba de los dos botones. :o , me dí cuenta que ese cambio aún no lo subí :D , sorry en breve subiré nueva versión con ese cambio :D , que casualidad que lo pidas y ya lo tenga implementado y todo :D
En cuanto al orden, en donde te refieres? en el visor de fnts Efectivamente, antes del cambio anterior mencionado siempre mostraba charset iso8859
en cuanto a las conversiones,que error te dan?
puse un how to compile, por si quieres compilar y probar los cambios del charset. ;)
Quote from: DCelso on February 07, 2013, 02:29:21 PM
master, nueva versión, r9, al fin corregido el problema de character encoding.
Ahora le he dado soporte para que abra fpgs y fnts comprimidos, usa zlib para ello, que va adjunto con fpgedit.
SplinterGU, al final nunca se llegó a implementar fonts para character enconding cp850 ¿no? veo que siempre usamos iso8859_1 en todos los fonts fnx.
no recuerdo, ni tampoco recuerdo para que es necesario, con convertir los fonts/textos deberia bastar... hay miles de herramientas para pasar un texto de una codificacion a otra.
la realidad, es que no recuerdo si ya esta soportado o no, me suena que no.
Splinter. En fénix estaba implementado.ya no se sí se perdió
A nivel práctico es un simple mapeo entre el texto escrito y las imágenes.
Es decir. Si pones write ("hola "). Para sacar las imágenes de cada letra hace lo siguiente. Letra a Letra. Mira el índice de h en el charencoding y con ese índice busca la imagen a mostrar del fnt. Y repite para o,l y a.
Lo malo es que en fénix sólo estaban implementados dos charencoding el iso8859_1 y el cp850.
Ambos son prácticamente iguales en las 127 primeras posiciones pero muy distintos en las 127 últimas.
Por tanto fénix hacia una doble traducción del texto.
Sí pones el "hola" de antes. Ese texto está escrito en el charencoding de defecto del sistema. Por tanto tiene que traducirla a l charencoding seleccionado en la fnt y luego a buscar las imágenes usando las posiciones del nuevo charencoding seleccionado
Se entiende?
Sabiendo eso ya se pueden hacer trucos varios. Sí sabes que en tal charencoding la a es el 120 y la z el 147. Y en tú fontológica pones ese charencoding y dibujada en el 120 una nave y en el 147 un planeta. Podrías poner 5 planetas y dos naves escribiendo lo siguiente: zzzzzaa
lo mismo que estaba en fenix, se mantiene.
ferpecto :D, lo suyo sería darle soporte utf-8 o unicode, que son más genéricos (engloban a todos) y servirían para la eternidad ;), lo malo es que no están limitados a 256 chars por lo que habría que cambiar algo en el formato fnx :D.
utf-8 implicaria mas consumo de memoria y cpu... de momento no esta en mis planes... pero no lo descarto a futuro.
:D. pues sí, bueno, al menos abrir un poco más el rango de charsets de 256 caracteres (fenix solo tenía dos el iso8859_1 y el cp850, y damos por hecho que bennu tb), no estaría mal para empezar :D, hay muchos charsets (que se dejan en el tintero) que podrían salvar a más de uno que usa bennu en lenguajes no españoles a las ñapas que solemos hacer para insertar textos raros en los fnt, a ello me refiero por ejemplo a poner write("·") para escribir por ejemplo un €, ya que sabemos que en nuestra font en la posición del carácter "·" del iso8859_1 pusimos el dibujo del € :D.
me parece... quizas me equivoco... pero que para eso esta la iconv de josebita.
nueva versión r12.
Con soporte para selección de charset (iso8859_1 ó cp850) en el generador de fuentes.
cambiado el nombre del binario y de algunos ficheros fuente.
:O, he probado el último bennugd en windows vista 32 bits y he visto que solo soporta el charset cp850. Falsa alarma, van los dos, el problema era que el charset del sistema es cp850.
1) Cuando escribo algo de ascii extendido en el casillero de "texto de prueba" con una fuente CP850(version 3.1.12r), me muestra un conjunto de caracteres, en vez del que pido.
Lo ejemplifico:
Yo escribo:
"á"
me aparece:
"Ôö£+¡"
2) Aun no puedo ver bien los textos en ISO8859_1, bennugd me sigue mostrando el caracter que correspondería a CP850.
Por ejemplo, yo quiero ver el caracter 133 de mi fuente (ISO8859_1) generada en tu programa:
"..."
El visor me dice que el caracter esta en su lugar y que es el codigo 133.
Pero cuando intento ver el texto en bennugd, me aparece
"à"
que corresponde al 133 de CP850, si genero una fuente en CP850, se visualiza como debería verse en CP850 ("à").
No hay ningún problema con la CP850, solo con la ISO8859_1, que me aparece como una CP850 disfrazada de ISO8859_1, incluso si intento ver el caracter 255, no sale nada en pantalla, porque en CP850 es el NBSP.
3) al intentar convertir un FPG a 8, 16 (fenix y cdiv) y 24 bits, aparece el siguiente error.
Acess Violation.
Press OK to ignore and risk data corruption.
Press Cancel to kill the program.
Ostras. Se me pasó probar el texto visualizador
lo corrijo en breve
lo de los conversores tb.
En cuanto a bennu. Es lo mismo que me pasó a mi al probar.
Te está pasando que tú charset de sistema es cp850. Y es el que usa bennu para saber que Letra mostrar por eso sí pones una á. La busca en el cp850 ya sabe cual es y busca su correspondencia en iso8859_1. Y por eso la muestra bien.
Así que no vale poner el número del char iso... Porque siempre usa el del sistema para saber el símbolo a presentar.
Sí quieres poner el 255 iso.. No vale con poner un char cinco valor 255. Sí no poner el ÿ. O bien buscar la posición de ese char en el charset del sistema y poner ese valor. En nuestro caso el charset del sistema es cp850 por lo que nos pasa ese efecto se que va mal.
Acabo de revisar, y tienes razón, lo que pasa es que desde versiones anteriores de FNTedit yo vengo trabajando con textos con codificación ANSI (CP-1252), es por eso que puse el ejemplo con el caracter "..." (el caracter 133 no existe en iso8859_1), a mi bennu me despliega "à" porque lo que hace es suplirlo con el caracter que esta en esa posición en cp850 (prácticamente busca el equivalente de "à" en iso8859_1).
Las fuentes que yo tengo, y que se supone que trabajan bien son en realidad cp850 con caracteres CP-1252, es por eso que bennu me mostraba el caracter que yo quería.
Creo que extrañaré que tu programa en vez de generarme fuentes cp850 con caracteres cp850, me genere fuentes cp850 con caracteres CP-1252. ya que en la CP850 no existen algunos de los caracteres que yo necesito (hablo de la versión "FNT Make 32 bits build 2" y anteriores)
Quote from: SplinterGU on February 08, 2013, 05:51:53 PM
me parece... quizas me equivoco... pero que para eso esta la iconv de josebita.
Splinter, si no me equivoco, la iconv solo nos serviria si el charset que estamos usando tiene los caracteres que necesitamos, por ejemplo, yo quier usar el caracter "..." de la CP-1252, con la iconv lo convierto a cp850, pero en la cp850 no existe el caracter "...".
Seguro que te iba eso?. Entonces quiere decir otra cosa. Quizás bennu este usando cp1252 como charset interno, sí no sería imposible mostrar caracteres fuera de cp850
Tendré que mirar más a fondo este tema.
Quote from: master on February 10, 2013, 10:36:39 AM
Acabo de revisar, y tienes razón, lo que pasa es que desde versiones anteriores de FNTedit yo vengo trabajando con textos con codificación ANSI (CP-1252), es por eso que puse el ejemplo con el caracter "..." (el caracter 133 no existe en iso8859_1), a mi bennu me despliega "à" porque lo que hace es suplirlo con el caracter que esta en esa posición en cp850 (prácticamente busca el equivalente de "à" en iso8859_1).
Las fuentes que yo tengo, y que se supone que trabajan bien son en realidad cp850 con caracteres CP-1252, es por eso que bennu me mostraba el caracter que yo quería.
Creo que extrañaré que tu programa en vez de generarme fuentes cp850 con caracteres cp850, me genere fuentes cp850 con caracteres CP-1252. ya que en la CP850 no existen algunos de los caracteres que yo necesito (hablo de la versión "FNT Make 32 bits build 2" y anteriores)
Quote from: SplinterGU on February 08, 2013, 05:51:53 PM
me parece... quizas me equivoco... pero que para eso esta la iconv de josebita.
Splinter, si no me equivoco, la iconv solo nos serviria si el charset que estamos usando tiene los caracteres que necesitamos, por ejemplo, yo quier usar el caracter "..." de la CP-1252, con la iconv lo convierto a cp850, pero en la cp850 no existe el caracter "...".
wait... eso te pasa con el font del sistema? o con un font creado con fntedit? prueba con el font del sistema a ver que caracter te da...
yo creo que internamente es 8859-1
si pasa con el font del sistema, pues entonces hay que averiguar que codificacion interna esta usando bennugd... si es con fntedit, pues el fntedit te esta generando con una codificiacion que no corresponde.
binarios de la r13 subidos.
se solventa el error de visualización y de los conversores de fpg
Subidos códigos fuente r14 con posibilidad de generar carácteres iso8859_15 y cp1252 simulados en el .fnt como iso8859_1.
En cuanto pueda cuelgo binarios.
1) en la nueva versión la conversión de FPG funciona, excepto a 8 bits, me manda:
Acess Violation.
Press OK to ignore and risk data corruption.
Press Cancel to kill the program.
Creo que la conversión a 1 bit se tiene que pulir un poco. Cuando intento ver el FPG, como solo hay dos colores (negro y blanco), creo que el negro lo interpreta como transparente y el blanco como color, pues no veo nada en el editor hasta que selecciono un dibujo, porque el fondo es blanco y se confunde con el dibujo.
2) Otra cosa, cuando selecciono "Editar propiedades de la imagen", en donde deberia decir "Ancho" tiene caracteres raros, los demás si dicen "Alto" y "puntos de control".
3) Cuando abro una imagen (doble click) siempre me dice que la profundidad de color es de 32 bits, a pesar de que el FPG es de otra profundidad), pasa igual en el buscador de imágenes desde el disco duro, solo que algunos si me las reconoce de 24 bits
Corregido conversores de 1 y 8 bits. Subire el cambio mañana
Lo de la profundidad es la de visualización. Deberia ser siempre de 32 bits para poder ver alas independientemente de la que tenga la imagen en el fichero. Este dato mo era para mostrar lo metí para comprobaciones internas y me olvide de quitarlo. ::)
Lo de ancho. Debo mirarlo. Creo que es algo del idioma .
subida versión r16
*añadido cp347
*añadido char preview
Por ahora me parece que va muy bien FPGedit, gracias DCelso.
Estoy probando y resulta que mi caso de que no me imprime el caracter 133 "..." es por BennuGD. A pesar de que pusiste la opción de simular una CP1252 en una iso8859_1, y de que se guarda correctamente, me puse a escribir con write todos los caracteres de la cp1252, y bennugd solo me despliega correctamente los caracteres que son imprimibles con la iso8859_1
¡Que lío!
Lo ejemplifico. Si escribo lo siguiente:
€ ... ™ ž ý þ ÿ
Me aparece esto:
Ç à Ö × ý þ ÿ
Los cuatro primeros corresponden a la área no imprimible de la iso8859_1, pero los demás se despliegan correctamente. Como he dicho, al parecer bennugd remplaza los caracteres (tratándose de iso8859_1) de las posiciones 128 a 159 por sus correspondientes en CP850.
Para visualizar correctamente creo que se tendría que simular la CP1252 en una CP850.
Nota1: Mi archivo PRG tiene codificación CP1252.
Nota2: Si uso codificación iso8859_1 y escribo los caracteres no imprimibles en el archivo de texto (el editor solo muestra cuadros en esos caracteres) pasa lo mismo.
Nota3: Las fuentes que yo tengo y que funcionan correctamente son CP850 simulando una CP1252. Guardando el archivo como en la Nota1 o la Nota2 funciona bien y se visualiza correctamente.
Nueva versión subida (r17), ahora puedes seleccionar con qué charset simular el fnx generado.
Quote from: master on February 12, 2013, 05:12:06 AM
Por ahora me parece que va muy bien FPGedit, gracias DCelso.
Estoy probando y resulta que mi caso de que no me imprime el caracter 133 "..." es por BennuGD. A pesar de que pusiste la opción de simular una CP1252 en una iso8859_1, y de que se guarda correctamente, me puse a escribir con write todos los caracteres de la cp1252, y bennugd solo me despliega correctamente los caracteres que son imprimibles con la iso8859_1
¡Que lío!
Lo ejemplifico. Si escribo lo siguiente:
€ ... ™ ž ý þ ÿ
Me aparece esto:
Ç à Ö × ý þ ÿ
Los cuatro primeros corresponden a la área no imprimible de la iso8859_1, pero los demás se despliegan correctamente. Como he dicho, al parecer bennugd remplaza los caracteres (tratándose de iso8859_1) de las posiciones 128 a 159 por sus correspondientes en CP850.
Para visualizar correctamente creo que se tendría que simular la CP1252 en una CP850.
Nota1: Mi archivo PRG tiene codificación CP1252.
Nota2: Si uso codificación iso8859_1 y escribo los caracteres no imprimibles en el archivo de texto (el editor solo muestra cuadros en esos caracteres) pasa lo mismo.
Nota3: Las fuentes que yo tengo y que funcionan correctamente son CP850 simulando una CP1252. Guardando el archivo como en la Nota1 o la Nota2 funciona bien y se visualiza correctamente.
es que no tienes € en cp437... no puedes hacer eso... € es utf
splintergu, ya encontré el por qué de todo (en el otro hilo lo explico ). Sí que se puede. yo lo hago, el € está en muchos mas charset además del utf8, iso8859_15 sin ir mas lejos se creó para ello. mira la posición 164 de éste.
Lo que no puedes hacer es imprimir el € con el fnt interno que trae bennu por defecto, por lo que dices, todas las imágenes son cp437, hasta ahí deacuerdo.
Pero en todos los fntedit, y fntmake anteriores fallaba eso, creaba fnx, con charset iso8859_15 poniendo el campo de charset a cp850, por lo que si codificabas en iso8859_15 el .prg, te iba perfectamente el euro y otros caracteres :D .
pero a menos que quieras emular, tu tienes que crear tus prg en la misma codificacion que los fonts que usas... no puedes pretender usar un font cp437 escribiendo los textos con iso8859-15... ahi esta gran parte del problema... diria yo el problema inicial... luego pueden existir otros, pero eso es lo mas basico que debes hacer.
Muy cierto.
En casos normales debe ser así, estoy deacuerdísimo contigo, habrá que documentarlo. espero que osk tome buena nota para futuras versiones de su documento :D
En casos raros, las simulaciones estas te pueden servir para crear tus propias codificaciones o caracteres raros, sabiendo que escribes en una codificacion real, digamos cp850 tu .prg, y luego dibujas grafos inventados para cada letra del cp850 en su posición en el fnx.
Como digo, actualmente bennu va muy bien para cualquier codificación de 8 bits, programas tu .prg en la codificación que quieras (de 8 bits). Creas tu fnx de esa codifiación exacta y le pones en su cabecera de charset un 1 (lo que llamabamos mal dicho cp850, en verdad bennu cuando ve esto no hace nada ni mapea ni nada pasa directamente el valor leido al fnx para buscar la imagen) y usará la codificación de tu .prg.
Es justo lo que comentas de programar en la misma codificación de tu .fnt. :D
Buenas,
me he vuelto loco con tanta conversión, llevo 2 dias cambiando código...
Afinal la conversion automatica de pascal a c# usando la tool Delphi2CS era una mierda, y he tenido que ir creando codigo equivalente a lo loco, ya queda menos, pero tengo una duda a ver si me la resuelves porque ni mirando el codigo original encuentro donde se hace.
Te resumo, en FPG_Load, cargas un FPG en memoria, o sea rellenas la estructura, por lo menos las variables file_type, fpg_code y version, pero lo que no encuentro es donde les el contenido de las imagenes, mas concretamente, donde rellenas la variable FPG_images.bmp con los bitmaps que tienes en el fichero fpg (haciendo un f.Read por ejemplo), para despues leerlas de la memoria y pintarlas en tu form usando la funcion lvFPG_Load_Images...
Porque ahora mismo tengo una lectura con bmp nulls y la variable FPG_add_pos = 0;
pues justo justito esa carga la cambié en fpgedit lazarus :D.
Antes había un switch que dependiendo del tipo de fgp leía una línea entera .en el fpgedit actual, creé una función para leer el bitmap, y abstraer un poco la lógica de lectura del switch case.
https://code.google.com/p/fpg-editor/source/browse/trunk/uFPG/uFPG.pas#576
Si lees, aqui loaddatabitmap, es justo lo que hacía para leer el bmp en el fpg-edit delphi. Te hago saber que en pascal hay una instrucción super rara que en otros lenguajes no existe, quizás esa sea quien te genera tu confusión. width http://www.delphibasics.co.uk/RTL.asp?Name=With
https://code.google.com/p/fpg-editor/source/browse/trunk/uMap/uMap.pas#69
ya veo, afinal la lectura la tenias en la propria funcion y despues la pasaste a la funcion loaddatabitmap, el tema es que me habia comido esa parte de codigo en fpg_load xD posiblemente porque borré la llamada, pero ya tenia la funcion en uMAp medio portada, bueno pues nada, lo que me interesa es saber en que posiciones leer del buffer, ya me pondré con ello, gracias ;D
;), de nada, esto lo hice para eliminar código redundante, antes estaba la carga tanto en los maps como en los fpgs, y si había que corregir algo y se te olvidaba en uno de los dos la gerías gorda :D, con ésto, solo debes cambiar en loaddatabitmap y corriges tanto maps como fpgs. ;).
Lo que si podrias hacer mientras no llega la noche xD, es decirme que hacen exactamente estas funciones en el loaddatabitmap, porque no encuentro equivalencia y tengo que saber que hacen exactamente para buscar otra forma de implementarlo:
1) Que tipo de controles de imagen son estos ?
a) lazBMP : TLazIntfImage;
b) result := TBitMap.Create;
2)
que hace esta llamada ?
p_bytearray := lazBMP.GetDataLineStart(k);
Sólo devuelve una imagen del fpg la funcion cierto ?
Bueno, voy avanzando, tengo que encontrar las funciones Calculate_RGB y Calculate_BGR a secas, que parece que son nuevas, voy a ver si las tienes tambien en uTools.
bueno ya esta portado, ahora sólo falta ir debugueando e ir arreglado errores hasta que funcione, mañana más xDD
Guais, pues sí, estaba ahí.
Quote from: FreeYourMind on February 18, 2013, 08:35:14 AM
Lo que si podrias hacer mientras no llega la noche xD, es decirme que hacen exactamente estas funciones en el loaddatabitmap, porque no encuentro equivalencia y tengo que saber que hacen exactamente para buscar otra forma de implementarlo:
1) Que tipo de controles de imagen son estos ?
a) lazBMP : TLazIntfImage;
b) result := TBitMap.Create;
2)
que hace esta llamada ?
p_bytearray := lazBMP.GetDataLineStart(k);
Sólo devuelve una imagen del fpg la funcion cierto ?
Sí, solo devuelve 1, si te das cuenta está en el umap, y los maps son para una imagen nada mas. :)
pero hay un for, para leer todas en el ufpg.
lo de lazbmp y tal, es de lazarus, en lazarus los tbitmaps no tienen el método scanline de delphi, y se simulan convirtiendolos a lazintfimage y usando el método getdatalinestart
que te devuelve el offset de una linea en los datos de la imagen. así vas trabajando línea a línea la imagen, en vez de pixel a pixel, lo que acelera mucho algunos procesos, como por ejemplo el de guardar o leer en archivo.
ya me he dado cuenta, ya he convertido todo a c# para que compile, pero me falta descubrir valores, de momento tengo que descubrir el offset en el array para recuperar cada dato de la estructura, ya que el f.read en c# necesita la posicion inicial del buffer en que se va leer cada dato y tus f.readbyte no disponen de esa informacion, aqui sólo me interesa la posicion del buffer para cada imagen del fpg y de paso ya paso los bits a otro tipo de datos como los bitmaps.
Resumiendo sólo me falta conocer las posiciones exactas del array en cada for, lo demas ya tengo su equivalente en c#.
que raro, en c# el f.read no avanza el buffer del fichero?. no me lo creo, totalmente ilógico en informática, en todos los lenguajes que he visto la lectura de archivos es secuencial, seguro que debe haber alternativa viable en c#. Es un poco extraño el tener que ir reposicionando el cursor del fichero para ir leyendo datos.
como que no avanza ? tienes start position y lenght, puedes leer de cualquier posicion, lo que pasa es que imagina esto, en tu array tienes 2 objetos, uno empieza en la posicion 0 y termina en la 10 y el otro empieza en la 11 y termina en la 15. Pues cuando leas el segundo objeto tienes que saber que el primero a terminado en la posicion 10, es esto que me falta, en tus freads no tengo información de inicio directamente, sólo el tamaño de cada uno, y para saberlo tengo que sumar sus tamaños en la strucutra y hacer lectura secuencial, pero es cosa que ya no me apetece hacer hoy ...
por lo que veo no usas lectura secuencial, cuando me refiero a que avance en el buffer, es que avance el cursor de la lectura secuencial, En lecturas secuenciales, primero posicionas el cursor, y luego vas leyendo desde éste, si lees un byte, el cursor avanza una posicion, si less un word, avanza dos, etc, por lo que no es necesario ir poniendo el inicio de donde quieres empezar a leer en todas las llamasdas a read, eso acomplejla la lógica mucho. Te sugiero que cambies a otra forma de leer el archivo distinta a la que tienes y que sea secuencias, nada mas busqué en google como leer un archivo binario en c# y me apareció el binaryreader que es secuencial y se parece un montón a la forma de trabajar de tfilestream de delphi.
http://msdn.microsoft.com/es-es/library/system.io.binaryreader.aspx
No, prefiero usar el otro, sobretodo porque los tipos de datos no siempre se corresponden entre lenguajes y no ocupan lo mismo, prefiero usar array.copy, no te preocupes, si despues tengo dudas ya te pregunto ;D
versión nativa linux de la revisión 19 disponible para descargar.
¿Alguien probó la versión de linux?¿Que tal va?
yo ya lo habia probado, no se si has sacado una nueva...
Pues me aparece esto en la terminal:
Gtk-Message: Failed to load module "overlay-scrollbar"
`menu_proxy_module_load': ./fpg-editor: undefined symbol: menu_proxy_module_load
(fpg-editor:11934): Gtk-WARNING **: Failed to load type module: (null)
`menu_proxy_module_load': ./fpg-editor: undefined symbol: menu_proxy_module_load
(fpg-editor:11934): Gtk-WARNING **: Failed to load type module: (null)
`menu_proxy_module_load': ./fpg-editor: undefined symbol: menu_proxy_module_load
(fpg-editor:11934): Gtk-WARNING **: Failed to load type module: (null)
`menu_proxy_module_load': ./fpg-editor: undefined symbol: menu_proxy_module_load
(fpg-editor:11934): Gtk-WARNING **: Failed to load type module: (null)
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio
Luego ya entra el programa.
En el visor de FPG, si cambio el tipo de vista a lista o detalles, y luego regreso a vista por iconos, ya no me despliega las imagenes, solo los números.
En el editor de FNT, si creo una fuente de tamaño 10, la fuente no se ve, si la genero de 15, aparecen unos cuantos puntos, pero si la genero de 25 si se ve. (al parecer hay algun problema con generar fuentes pequeñas, se come los pixeles o algo asi)
Si abro una fuente y la veo con el "Visor de datos FNT", los caracteres me aparecen un numero recorrido (me refiero a que el 133 me aparece en el 132 de arriba hacia abajo, y si me muevo con las flechas del teclado de abajo hacia arriba, el caso cambia y me aparece como el 134.)
No he revisado a fondo todo, pero se ve bastante bien el programa, probé con fuentes de 1, 8 y 16 bits, probe las conversiones a 1,8,16,24 y 32 bits de fpg y funcionan bien.
---------------------------------------
Acabo de probar la versión para windows y no tengo los problemas que te comente de la versión de linux
pero me aparece esto si ejecuto desde terminal:
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio
err:commctrl:COMCTL32_SubclassProc Our sub classing stack got erased for 0x10080!! Nothing we can do
spliterGU, me refería a la r19. que colgué ayer.
juaus, muchas gracias master, la versión linux está usando el witget QT para crear los componentes visuales, está claro que el wrapper lazarus -QT está muy verde, yo ya le saqué varios fallos que tuve que corregir yo mismo y mandar a la gente de lazarus para que lo reporten. Miraré a ver si puedo corregir esos, que nos interesan mucho a nosotros para el fpg-edit :D.
pero los errores eso de consola a mi no me dan eh ninguna de las dos versiones. Son rarunos.
Yo lo he probado y no me arranca porque no tengo la libreria Qt q pide .. cual es? toy en ubuntu
./fpg-editor: error while loading shared libraries: libQt4Pas.so.5: cannot open shared object file: No such file or directory
pues yo tengo instalado esto relaccionado con QT, y que parezca no ser de desarrollo,
i libqt3-mt - Qt GUI Library (Threaded runtime version),
Prueba con esa sola, y si no, tengo también esto instalado, pero creo que solo es necesario en mi caso que estoy compilando el binario,
i lazarus-ide-qt4 - IDE for Free Pascal - IDE build on top of
i lazarus-ide-qt4-1.1 - IDE for Free Pascal - Qt version
i lcl-qt4 - Lazarus Components Library - Qt backend de
i lcl-qt4-1.1 - Lazarus Components Library - Qt backend
i libqt4pas-dev - Development files for Qt4Pas
Quote from: KeoH on February 20, 2013, 07:53:38 PM
Yo lo he probado y no me arranca porque no tengo la libreria Qt q pide .. cual es? toy en ubuntu
./fpg-editor: error while loading shared libraries: libQt4Pas.so.5: cannot open shared object file: No such file or directory
Tienes Ubuntu de 64 bits?
me pasaba lo mismo, solo hice:
$ sudo apt-get install libqt4pas-dev:i386
y me funcionó, bendito sea el multiarch.
Quote from: DCelso on February 20, 2013, 07:46:36 PM
spliterGU, me refería a la r19. que colgué ayer.
juaus, muchas gracias master, la versión linux está usando el witget QT para crear los componentes visuales, está claro que el wrapper lazarus -QT está muy verde, yo ya le saqué varios fallos que tuve que corregir yo mismo y mandar a la gente de lazarus para que lo reporten. Miraré a ver si puedo corregir esos, que nos interesan mucho a nosotros para el fpg-edit :D .
pero los errores eso de consola a mi no me dan eh ninguna de las dos versiones. Son rarunos.
Acabo de investigar y lo que me sale en la terminal en la versión de windows (y al final de la versión de linux) era por una librería, en este post (http://askubuntu.com/questions/127848/wine-cant-find-gnome-keyring-pkcs11-so) explican como solucionarlo:
Entonces ya solo me muestra el error en la terminal del programa de linux:
Gtk-Message: Failed to load module "overlay-scrollbar"
`menu_proxy_module_load': ./fpg-editor: undefined symbol: menu_proxy_module_load
(fpg-editor:4272): Gtk-WARNING **: Failed to load type module: (null)
`menu_proxy_module_load': ./fpg-editor: undefined symbol: menu_proxy_module_load
(fpg-editor:4272): Gtk-WARNING **: Failed to load type module: (null)
`menu_proxy_module_load': ./fpg-editor: undefined symbol: menu_proxy_module_load
(fpg-editor:4272): Gtk-WARNING **: Failed to load type module: (null)
`menu_proxy_module_load': ./fpg-editor: undefined symbol: menu_proxy_module_load
(fpg-editor:4272): Gtk-WARNING **: Failed to load type module: (null)
Pues he instalado la libreria que dice Master y funciona xD me da el error ese te Gtk tambien .. pero sera algo de ubuntu porque se supone q fpgEdit esta usando Qt .. no se .. voy a probarlo en Kubuntu a ver si da el mismo error
Pues en Kubuntu (escritorio KDE) funciona perfectamente tambien ( despues de instalarme la libreria esa del paso anterior xD) .. el mensaje de error de las Gtk no sale .. pero sale otro en su lugar
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio
Por cierto .. cuando abro un fpg y selecciono varias imagenes de este y le doy al boton animar .. no funciona xDD Sale la ventanita en blanco y ya esta :-\
Quote from: KeoH on February 20, 2013, 08:36:11 PM
Pues en Kubuntu (escritorio KDE) funciona perfectamente tambien ( despues de instalarme la libreria esa del paso anterior xD) .. el mensaje de error de las Gtk no sale .. pero sale otro en su lugar
p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: /usr/lib/i386-linux-gnu/pkcs11/gnome-keyring-pkcs11.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio
Para solucionarlo mira este post: http://askubuntu.com/questions/127848/wine-cant-find-gnome-keyring-pkcs11-so
Quote from: KeoH on February 20, 2013, 08:37:47 PM
Por cierto .. cuando abro un fpg y selecciono varias imagenes de este y le doy al boton animar .. no funciona xDD Sale la ventanita en blanco y ya esta :-\
Me pasa lo mismo.
Quote from: KeoH on February 20, 2013, 08:36:11 PM
Quote from: KeoH on February 20, 2013, 08:37:47 PM
Por cierto .. cuando abro un fpg y selecciono varias imagenes de este y le doy al boton animar .. no funciona xDD Sale la ventanita en blanco y ya esta :-\
Me pasa lo mismo.
:o , ¿con el de windows en wine tambien?
Quote from: master on February 20, 2013, 08:41:37 PM
A que me cargué algo.
Ea, estrenad alguno la sección e issues del proyecto.;)
https://code.google.com/p/fpg-editor/issues/list
Quote from: DCelso on February 20, 2013, 09:07:23 PM
Quote from: master on February 20, 2013, 08:41:37 PM
Quote from: KeoH on February 20, 2013, 08:37:47 PM
Por cierto .. cuando abro un fpg y selecciono varias imagenes de este y le doy al boton animar .. no funciona xDD Sale la ventanita en blanco y ya esta :-\
Me pasa lo mismo.
:o , ¿con el de windows en wine tambien?
A que me cargué algo.
No, solo en la versión de linux.
oye dcelso una pregunta tecnica rapida, una imagen en el array de bits del fpg cuantas posiciones ocupa exactamente (fpg de 16 bits), es (width * height) o juega con alguna variable más ?
Quote from: FreeYourMind on February 20, 2013, 09:28:03 PM
oye dcelso una pregunta tecnica rapida, una imagen en el array de bits del fpg cuantas posiciones ocupa exactamente (fpg de 16 bits), es (width * height) o juega con alguna variable más ?
para todas excepto para 1 bit es: width * height * bytes_per_pixel, para tu ejemplo bypes_per_pixel sería 2 ( 16 bits por pixel / 8 bits por byte)
para 1 bit, se acompleja un poco, porque hay que hacer que una línea sea múltipo de 8, por lo que sería
si width mod 8 es 0 entonces se usa width * height
sino entonces se usaría ( width + (8 - (width mod 8 ))) * height ,
NOTA: 8 - (width mod 8 )) son los bits que le hace falta a width para que sea múltiplo de 8. ;)
Por cierto, es array de bytes, la unidad mínima que que puede guardar en un archivo es un byte. por lo que nunca podrías guardar 3 bits, por ejemplo.
Y que guarda el valor de FPG_images[FPG_add_pos].graph_size ???? no deberia ser exactamente el mismo valor que esa multiplicación ?
es que el graph_size me sale ligeramente mayor que el resultado de width * height * bytes_per_pixel.
:o , debería ser igual, si está pasando eso, hay un fallo.
pues, no la probe... lo siento.
>:( , perdonado, pero porque eres tu, eh. Que no vuelva a pasar. :)
una cosa dcelso, porque en load data bitmap haces operaciones de conversion de paleta y demas, no deberia ser sólo leer el array de bytes (en la respectiva posición) y convertirlo a bmp ?
Quote from: DCelso on February 20, 2013, 09:07:23 PM
Ea, estrenad alguno la sección e issues del proyecto. ;)
https://code.google.com/p/fpg-editor/issues/list (https://code.google.com/p/fpg-editor/issues/list)
Listo ;)
Quote from: FreeYourMind on February 21, 2013, 09:23:01 AM
una cosa dcelso, porque en load data bitmap haces operaciones de conversion de paleta y demas, no deberia ser sólo leer el array de bytes (en la respectiva posición) y convertirlo a bmp ?
Porque la forma más cómoda y rápida de trabajar imágenes y poder disponer de cualquier tipo de representación (y no tener restricciones ni límites) en pantalla es usar 32 bits internamente.
Por lo que el nuevo fpg-edit solo trabaja con imágenes de 32 bits en memoria y las demás profundidades de color (al insertarse en el fpg ) deben de simularse en 32 bits, luego ya al hacer el save, las guardo en el formato deseado. Lazintfimage es mas bestia y trabaja internamente en 64 bits, eso a mi ya me pareció ser demasiado
"tipismiquis" ningún ojo del mundo creo que sea capaz de distinguir 256 tonalidades distintas de verdes, por lo que no te digo na de 65356 distintas (64 bits por pixel, que es 16 bits por canal)
Quote from: master on February 21, 2013, 10:59:47 AM
Quote from: DCelso on February 20, 2013, 09:07:23 PM
Ea, estrenad alguno la sección e issues del proyecto. ;)
https://code.google.com/p/fpg-editor/issues/list (https://code.google.com/p/fpg-editor/issues/list)
Listo ;)
Gracias, oye, que inglés mas bueno tienes, jueu lo entiendo igualito, igualito al español ;)
el tema es que en c#, sólo necesito la imagen en binario da igual que formato sea, la funcion ya convierte el array en bitmap internamente, a lo mejor yo no necesito esas conversiones, sólo necesito que el array contenga una imagen bitmap valida, no importa su profundidad de color, ya devolverá la imagen que tienes guardada en su formato.
con lo cual creo que con saber la posicion de inicio/fin de la imagen me valdria
Bien, entonces qué necesitas de mi.
tu dinero
Quote from: DCelso on February 21, 2013, 08:36:32 AM
>:( , perdonado, pero porque eres tu, eh. Que no vuelva a pasar. :)
hehehe... ;)
new hoty linux version.
http://code.google.com/p/fpg-editor/downloads/detail?name=fpg-editor%28r23%29_linux_bin.tar.gz&can=2&q=#makechanges
Funciona lo que he podido probar .. pero lo de la animación esa nop xD
estoy en ello :D, a ver que puede ser, porque en windows va, será otro fallo QT, cago, como siga así voy a tener que hacerme coder oficial de lazarus :D
oye, tu puedes debugear con lazarus ? podrias pobar un fpg de 16 bits con 2 imagenes de prueba (sin puntos de control) y decirme exactamente en que posicion empieza la primera imagen y termina (me refiero al cuerpo del bmp en el array) y me pasas el fpg ? es que no hay forma, tengo siempre error al convertir la imagen y necesito tener certeza de su posicion. gracias
r24 disponible para linux.
Umn, Free, veré lo que puedo hacer.
free, hice una versión debug, que muestra los puntos clave al abrir un fpg, mira a ver si te vale,
http://code.google.com/p/fpg-editor/downloads/detail?name=fpg-editor_r24_debug.tar.gz&can=2&q=
si no puedes usar linux, mañana te cuelgo versión windows.
La animación funciona en esta ultima version xDDDD
sí, como que es lo único nuevo de la 24 :D , ya te dije que estaba liado con ello :D
y viste el detalle de poder cambiar el tiempo, y el ensanchar y o mantener proporciones?
además ahora también si cambias el color de fondo del listado en el menú de configuración, también se cambia en el fondo de la animación ;)
Pero me he dado cuenta que no me ordena las imagenes por su numero , pa prueba un ejemplo xD
EDIT: Vale .. he conseguido ordenarlas xDD pero deberia de hacerlo por defecto xDD
pon la de windows porfa que me facilitarias mucho la vida
:'(, no tuve tiempo en todo el dia, acabo de sacar uno, voy a compilartelo y te lo subo.
gracias, espero que ahora mismo lo quiero mirar
ya lo tienes.
Si necesitas mas info o no entiendes el log dímelo.
Quote from: DCelso on February 21, 2013, 11:36:36 AM
Gracias, oye, que inglés mas bueno tienes, jueu lo entiendo igualito, igualito al español ;)
;D Jejeje, creí que se vería mejor mi español al ingles de Google Translate.
En la r24 parece que en la version de linux el unico problema es que no me genera bien las letras a tamaños pequeños (de 20 hacia abajo), en la version de windows no hay este problema
gracias!
me ha servido para comprobar que realmente si tenia los valores bien, o sea, el problema parece estar al convertir el array en bitmap usando funciones de c#.
El formato que se guarda en el array es realmente bitmap ? tendré que ver mejor el tema de la conversion.
Otra cosa que te confirmo, guardas mal el valor de graph_size, como puedes ver en la imagen, tiene valor 982 y deberia tener valor 918 que es la multiplicacion:
FPG_images[FPG_add_pos].Width * FPG_images[FPG_add_pos].Height * byte_size = 17 * 27 * 2 = 918
si miramos la posicion de la imagen empieza en 72 y termina en 989, tambien se confirma, o sea 990 - 72 = 918
con lo cual el size deberia poner 918 y no 982 para la imagen del test, aunque esto no afecte el funcionamiento, y parece ser que en bennugd tampoco.
(http://forum.bennugd.org/index.php?action=dlattach;topic=3212.0;attach=2915)
Esta bien. Graph size no es el tamaño del array de pixeles. Si no el total del grafico con su info incluida. 990-8 = 982.
Al decirmelo la otra vez lo mire y lo vi bien. Al decidmelo esta vez ya vi tu fallo.
Me estrañó que dijeras eso la otra vez. Ahora veo el por qué.
En respuesta a si es un bitmap el array pues tampoco. E array es lo que es. La informacion de color de cada pixek. Y guarda exactamente el color pixek por pixel. Y dependiendo del formato fpg usa un byte o mas por cada pixel.
Tampoco corresponde a la forma en que lo guarda un bitmap en todas las profundidades. Solo es igual en 32 y 24 bits. Gracias a splintergu. Porque para 16 fenix usa RGB y cdiv BGR. Y en 8 bits las paletad div las disminuye a seis bits por componente. Y en un bit hace redondeo a byte por libea. En definitiva. Casi nada que ver con bitmap.
ya pero tu lo conviertes al final en imagen usando result.LoadFromIntfImage(lazBMP); ? cierto ? el tema es que tengo que buscar una forma de pasarlo a bitmap al final para poder pintar las imagenes en los controles del form, y al reves al guardar un fpg...
Si. Pero lo hago manualmente. Es el objetivo de la funcion loaddatabitmar. Creo un bitmap de 32 bits le doy las dimensiones leidas en la onfo del bitmT y dependiendo del tipo de fpg leo el array de pixeles de una forma u otra y pinto cada pixel del bitmap. Por lo que si creias que directamente lo asignaba magicamente al bitmap. No era asi. Es un proceso artesano macerado con el paso de las versiones. :)
Buenas noticias, el bicho del monte empieza siendo capturado xDDD
(http://forum.bennugd.org/index.php?action=dlattach;topic=3212.0;attach=2918)
De momento ya sale algo identificable como imagen xD y ya la considera imagen que es lo mejor, te pongo el src de c# para ver si me ayudas a buscar lo que falta, he tenido que usar una llamada distinta al crear el bitmap, usando puntero y variable stride, la forma de calcular el valor de stride lo he visto por internet.
Esto es al final de obtener el array p_bytearray, donde ya solo falta pasarla a bitmap para poder mostarla en pantalla:
int bitsPerPixel = ((int)PixelFormat.Format32bppArgb & 0xff00) >> 8;
int bytesPerPixel = (bitsPerPixel + 7) / 8;
int stride = 4 * ((width * bytesPerPixel + 3) / 4);
System.Runtime.InteropServices.GCHandle pinnedArray = System.Runtime.InteropServices.GCHandle.Alloc(p_bytearray, System.Runtime.InteropServices.GCHandleType.Pinned);
IntPtr pointer = pinnedArray.AddrOfPinnedObject();
result = newBitmap(width / 2, height, stride, PixelFormat.Format32bppArgb, pointer);
El problema que tengo es que los colores no salen bien y sólo tengo 3 opciones de formato de pixel para 32 bits:
Format32bppArgb Format32bppPArgb Format32bppRgb
una de ellas pone el fondo negro, pero la imagen es la misma, tambien he puesto: newBitmap(width / 2... para corregir la imagen horizontalmente, que sino se repite.
:o. No entiendo nada de nadaa.
A ver. No hay una forma de crear un bitmat de 32 bits vacio ?
Y luego acceder pixel a pixel para ir cambiando el color?
vacio! eso es definirlo null, pero si es null no hay posiciones ni pixels a los que cambiar color... enfin esto es mas logico que lo de lazarus creando bitmaps con dimensiones y formatos antes de meter en ellos lo que sea xD
de todas formas yo creo y mirando tu codigo, hay muchas similitudes en el calculo del stride, tambien tiene en su formala width * bytes_per_pixel. yo creo que lo que esta fallando es tener este valor correcto y tambien el equivalente pixel format en c#
tampoco entiendo a que te refieres con cambiar color pixel a pixel, no es supuesto que la info de los pixels no esta ya en el array binario ? vamos, yo de este tema entiendo tanto como de mujeres, nada xDD
Bueno, te dejo mi ultima captura de las pruebas, tambien tengo otro error, ahora mismo sólo puedo cargar 69 imagenes de las 250 que tengo, parece que tengo problemas de aceso a memoria protegida en la variable height... pero eso ya es otro tema, primero quiero solucionar el pintado de las imagenes.
(http://forum.bennugd.org/index.php?action=dlattach;topic=3212.0;attach=2920)
un bitmap vacio = null? como es eso? flipo igual a DCelso...
entiendo que un bitmap vacio se refiere a un bitmap de tamano W x H, de 32bits con todos los pixels en 0.... eso entiendo se refiere DCelso... y por lo menos es lo que yo entiendo como un bitmap de 32bits vacio.
Gracias splinter. Estamos en la misma onda. ;)
free, a ver. Parece que distes con la tecls. Ahi se ven imagenes. Que es lo que falla en ellas?
vale, he visto que en c# tambien se puede crear vacio ya con formato, seria así :
Bitmap b2 = new Bitmap(width, height, System.Drawing.Imaging.PixelFormat.Format32bppArgb);
vale, mañana probaré ser mas fiel al codigo de pascal y rellenar el bmp de la misma forma a ver si funciona de una vez.
Guais, eso va viento en popa entonces:D.
bueno, si intentas sincronizar tu código con el último de svn del mío, lo vas a flipar, he cambiado un montón de ficheros :'(, pero lo hice para convertir la libreria ufpg en una clase como dios manda, hasta ahora era un conjunto de estructuras y funciones, con ello se simplifica un poco la lógica, se organiza un poco el código y se rompe la dependencia de unas cuantas variables globales.
También, y por el mismo motivo, me ví obligado a crear un nuevo componente extendido de listview con soporte para fpgs.
Con este cambio, me dí cuenta de algún que otro error garrafal que existen desde tiempos inmemoriables y que cuando los he visto he flipado pensando que cómo podría ir esto hasta ahora. :D, (me refiero a algunos límites, superiores e inferiores, en los bucles).
Binarios windows r26 subidos.
Bueno ahora estoy usando el metodo similar al tuyo, de ir rellenando el bitmap.
De momento obtengo resultados similares con imagenes mal formadas pero identificables, tambien parece que he corregido el color, para tu info ahora lo hago así (de momento sólo fpg de 16 bits), en el case 2:
case 2:
s = newbyte[width * bytes_per_pixel];
Array.Copy(Buffer, 0, s, 0, width * bytes_per_pixel);
byte_line = s;
for (j = 0; j < width; j++)
{
if (is_cdiv)
{
uColor16bits.Calculate_RGB(byte_line[j * 2 + 1], byte_line[j * 2], ref p_bytearray[j * 4], ref p_bytearray[(j * 4) + 1], ref p_bytearray[(j * 4) + 2]);
p_bytearray[(j * 4) + 3] = 255;
if (((p_bytearray[j * 4] == 0xF8) && (p_bytearray[j * 4 + 1] == 0) && (p_bytearray[j * 4 + 2] == 0xF8)))
p_bytearray[(j * 4) + 3] = 0;
}
else
{
uColor16bits.Calculate_BGR(byte_line[j * 2 + 1], byte_line[j * 2], ref p_bytearray[j * 4], ref p_bytearray[(j * 4) + 1], ref p_bytearray[(j * 4) + 2]);
p_bytearray[(j * 4) + 3] = 255; // Alpha value
if ((byte_line[j * 2 + 1] + byte_line[j * 2]) == 0)
p_bytearray[(j * 4) + 3] = 0; // Alpha value
}
try
{
//result.SetPixel(j, k, Color.Blue);
result.SetPixel(j, k, Color.FromArgb((int)(p_bytearray[((lineStart + j) * 4) + 3]), // Alpa
(int)(p_bytearray[((lineStart + j) * 4 + 1)]), // Red
(int)(p_bytearray[((lineStart + j) * 4)]), // Green
(int)(p_bytearray[((lineStart + j) * 4) + 2]))); // Blue
}
catch(Exception ex)
{
//MessageBox.Show(ex.Message); }
}
break;
case 3: ...
Me parece que ya sólo faltaria obtener el valor correcto para cada interaccion (cambio de linea) de la variable lineStart, porque tu usas esto:
p_bytearray := lazBMP.GetDataLineStart(k);
y no entiendo exactamente que hace, pienso que tambien desloca la posicion del array en cambio de linea, necesito que me expliques esto y que valores/dimensión tiene p_bytearray en cada asignación de esas en el for.
gracias.
Ok. Pinta bien. Como recomendaciin te sugiero que priebes primero a cargar imahenes de 24 o 32 bits. Son mas faciles de manejar y entender la logica. Ya luego te pasas a las demas. Que llevan tratamiento adicionak a cada pixel.
Get data line start hace lo que si nombe dice. Y ya te respondi. Devuelve el inicio de la linea k dentro del buffer de datos.
Por lo que en cada iteracion puedes leer width*bytedepth.
Es decir recorre la dimension height.
En mi caso tbitmap es pf32bit. Que crea un array de datos bgra. Por lo que nyte deoth es 4 siempre. Por lo tanto el array de datos del bitmap se lee de 4 en 4 bytes.
Ahora bien el array de datos del fpg depende del tipo de fpg leido. Por eso esta el swith casr.
En el mismo for y usando mod. En el caso de 24 bits consigo poder accerder al buffer de tbitmap saltando de 4 en 4 y al buffer del fpg saltando de 3 en 3
oye, por cierto estas abriendo bien los ficheros cdiv de 16bits creados antes ? a mi me sale FPG_type = FPG_NULL
Si. Perfectamente. Son de 16 bits bgr(al reves que fenix) donde el color transapente es wl pink. 248.0.248.
Nueva versión para descargar, r27, corregido un error en la exportación de maps.
No creo que alguien use este formato hoy en día, pero me encontré el error y lo corregí :D.
http://code.google.com/p/fpg-editor/downloads/detail?name=fpg-editor_r27_win32.7z&can=2&q=#makechanges
nueva versión r29
http://code.google.com/p/fpg-editor/downloads/detail?name=fpg-editor_r29_win32.7z&can=2&q=#makechanges
Recorregido error en exportación y lectura de maps :D,
Corregidas varias cosas en el manejo de puntos de control.
Ahora al remplazar una imagen, no elimina los puntos de control de la imagen anterior. (por lo que puedes sacar la imagen retocarla y volverla a insertar respetando los puntos de control)
Si insertas un map, también copia los puntos de control.
release 30, para linux.
ningún cambio que afecte a nada con respecto a la 29 solo que es para linux y algún cambio de nombre de variable.
versión r32 disponible para linux.
ahora por defecto crea un fpg de 32 bits, puedes cambiar su formato a otro dinámicamente desde la barra de estado.
Me e bajado la versión 3.1 que tienes un poco mas arriba de este post, que creo que es el ultimo.
Me da error al abrir cualquier fpg.
La ventanita dice:
Failed to get raw image description from bitmap.
Press OK to ignore and risk data corruption.
Press Cancel to kill the program.
Al darle a OK el programa no cae, pero no abre absolutamente nada.
Por si acaso, e probado a meterlo en la misma carpeta donde tengo el 3.0, pero me hace lo mismo.
La versión 3.0 me va bien.
La de windows?. Dime r27 o que r.
Entra en la pagina de codegoogle y en la seccion de downloads. Tienes las ultimad descargas
Windows r29, me la e bajado otra vez por si acaso, pero me hace lo mismo. Me da error al abrir fpg´s de 16 bits. En principio pensaba que era error de mi fpg, pero al intentar abrir los fpg´s de 16 bits que hay en los ejemplos medios del pack, ya e visto que no me abren. Y por si acaso repito que con otra versión mas vieja que tengo del programa si que se puede.
:o, que raro. A mi me abren.
Que version de windows tienes. Vista 32 bits?
Voy a recompilar la 32 a ver si va en esta ultima.
Windows 7 64bits 8 Gigas de ram
Gracias por el aviso, abash,
encontré el problema, no estaba comprobando bien si estaban comprimidos los fpgs.
Ya lo solucioné.
Subo la versión
Pruebala
http://code.google.com/p/fpg-editor/downloads/detail?name=fpg-editor_r33_win32.7z&can=2&q=#makechanges
Edito mi respuesta, ya que ahora hace algo raro.
Si ejecuto el programa y abro un fpg, lo abre sin problemas. Con fpg aclaro que digo los que antes no podia.
Pero...
Si abro los fpg haciendo clic derecho y abrir con...
Me sale una ventanita que dice:
El fichero (.FNT) no es un formato valido.
Desde luego que no es un archivo FNT lo que quiero abrir, eso por descontado. No se porque lo pone la ventana.
Pulso Aceptar y arranca el programa con otra ventana de error.
Invalid pointer operation.
Pulso OK y arranca, pero no abre nada.
:O, verificaré ese error.
he subido otra versión corrigiendo un error en la ventana de compresión, y he añadido también soporte para comprimir los map.
Corregido, ;)
http://code.google.com/p/fpg-editor/downloads/detail?name=fpg-editor_r35_win32.7z&can=2&q=#makechanges
Gracias por el aviso, si encuentras más cosillas ¿podrías insertarlas por aquí para dejar mejor constancia?
http://code.google.com/p/fpg-editor/issues/list
Lamento decirte que no e encontrado ningun error esta vez ;) ahora si que va bien.
Bien por mi.
Pues nada. Para cuando aparezcan. :)
has visto que ahora es tipo winrar?
Puedes arrastrarle imagenes desde el explorador y se insertan.
Nueva versión windows disponible
http://code.google.com/p/fpg-editor/downloads/detail?name=fpg-editor_r36_win32.7z&can=2&q=#makechanges
Nueva versión windows disponible
http://code.google.com/p/fpg-editor/downloads/detail?name=fpg-editor_r38_win32.7z
versión linux ya disponible
http://code.google.com/p/fpg-editor/downloads/detail?name=fpg-editor_r38_i386lin.tgz
versión linux r48 ya disponible
la r47 de linux parece funcionar perfectamente xDD grandes cambios en la interfaz .. parece raro xD pero mola ;D
Gracias, ya está la 51 disponible.
Nueva versión para linux, r53M.
Ahora con soporte funcional para archivos de internacionalización .po (archivos de idiomas), he remplazado por completo el sistema anterior de traducción con ficheros (.ini), pero he puesto a disposición una herramienta de conversión de formato para estos archivos.
También he añadido una herramienta de ayuda a la traducción para cualquier otro idioma que no esté disponible. Con ella he traducido fpg-editor a google-portugués :D. (a ver si me ayudais entre todos a comprobar si las traducciones son correctas, o al menos se entienden)
Quien quiera usar estas herramientas, tiene que activar en el archivo de configuración fpg-editor.ini, ADMIN TOOLS=1 , en la sección de [FPG].
NOTA: hay que hacerlo a mano, no hay posibilidad de activarlo desde la ventana de configuración.
Quien quiera colaborar con nuevos idiomas, bienvenido sea.
mi bennugd tools ya incluye un traductor automatico que se conecta a google en tiempo real xD
;D, cagoen. Si que va a ser potente sí.
A ver si lo das a luz pronto nen. ;)
Nueva versión windows de la r 56
La mejora que añade esta versión, es edición tipo "sprite art" para las imágenes. A esta opción se accede desde la ventana editar de una imagen de un fpg.
https://code.google.com/p/fpg-editor/downloads/detail?name=fpg-editor_r56_win32.7z
Alto. No useis las tres ultimas versiones para 8 bits.
Tiene un error de precision que os cambiara los colores. Estoy arreglandolo.
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
Versión r60 disponible ya.
Mejoras en el editor de mapas.
Bug corregido en la conversión a 8 bits, que causaba colores repetidos.
Versión r62 para linux disponible.
Añadida herramienta de relleno en el editor de mapas.
Sugerencia: Cada tanto estaría muy bueno que adjuntaras capturas de las novedades
:), lo tenía previsto.
pero vamos yo es por incentivar, quien quiera verlo que se lo descargue y lo ejecute ;D
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.
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.
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.
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 :)
:), 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.
r66 para linux disponible.
Incorpora soporte de abrir fnts como fpgs.
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
;),
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.
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.
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.".
;), creo que ya no me queda nada en mente que meter. Salvo algunos retoques y bugs. Creo que no voy a tocarlo por el momento. De tosas formas son daily snapshot si te das cuenta sigue siendo fpgedit 3.1. Aunque ya deberia cambiarle el nombre porque lleva editor de maps, compresor de archivos, editor, visor y generador de fuentes. Por lo que el nonmbre deberia ser mapfpgfnt editor. :)
Ara creo que me pondre con sharp. ;-).
Quote from: FreeYourMind on March 15, 2013, 03:14:47 PM
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.".
perdona, comentario bien de usuario mediocre el de tu jefe... el que se pierde alla el y sus problemas... como te vas a perder enviando releases nuevas si cada una va incrementando en fixes o funcionalidades a la anterior?
realmente ese comentario es de alguien que no tiene interes por el producto... lindo jefe te has ganado!
Quote from: DCelso on March 15, 2013, 03:57:07 PM
;), creo que ya no me queda nada en mente que meter. Salvo algunos retoques y bugs. Creo que no voy a tocarlo por el momento. De tosas formas son daily snapshot si te das cuenta sigue siendo fpgedit 3.1. Aunque ya deberia cambiarle el nombre porque lleva editor de maps, compresor de archivos, editor, visor y generador de fuentes. Por lo que el nonmbre deberia ser mapfpgfnt editor. :)
Ara creo que me pondre con sharp. ;-).
tu sigue a tu ritmo y a tu forma... que nadie esta haciendo el trabajo por ti... tu te lo estas cargando todo solo y no tienes que rendirle cuentas a nadie al respecto...
animo con ello! estas haciendo un excelente trabajo!
Gracias splinter por el apoyo ;).
Estoy a tope con el proyecto este porque desde hace ya tiempo quería darle soporte a las gamas de color de DIV.
En 8 bits son un apoyo muy bueno ya que te sirven para organizar los colores de cada objeto y así poder hacer pixelart rápida y cómodamente, y al darle soporte a fpg edit de editar imágenes pues me puse a piñón a investigar como guardaba las gamas DIV y como las trataba. En la investigación me dí cuenta que el término correcto para referirse a ellas en inglés es "gamut" que significa algo así como gama de colores o conjunto de colores, y es eso exactamente lo que hace DIV guarda 16 gamas de color programables para facilitar la edición de imágenes.
El término "gamma" puede significar también gama, pero no gama de color, y en imágenes se usa para definir la corrección gamma (que es un valor de corrección de color intrínseco al emisor de imagen para hacer que un color sea igual en todos los emisores), que es otra cosa muy distinta a las 16 gamas de DIV..
de nada... yo se bien lo que es trabajar en algo gratis y libre, y a veces cuando alguien te critica algo de lo que haces en ese aspecto te sientes como que tu esfuerzo no vale la pena... y encima de todo, la realidad es que, tu, te estas currando un trabajando tremendo con una herramienta muy util para la comunidad...
desde ya, yo te agradezco por ponerle empuje a la cosa... que otros andamos medios flojos con los avances y el entusiasmo...
saludos.
totalmente de acuerdo, en mi caso sigo sacando las releases pero ya no se las mando al jefe ;D
Quote from: FreeYourMind on March 16, 2013, 08:08:12 AM
totalmente de acuerdo, en mi caso sigo sacando las releases pero ya no se las mando al jefe ;D
sos groso, sabelo! ;)
Quote from: FreeYourMind on March 16, 2013, 08:08:12 AM
totalmente de acuerdo, en mi caso sigo sacando las releases pero ya no se las mando al jefe ;D
En verdad, opino que no dejes de sacar releases porque como dice splinter "como te vas a perder enviando releases nuevas si cada una va incrementando en fixes o funcionalidades a la anterior?"
De hecho, yo tengo en mi disco duro una carpeta llamada FPGedit, con todos los binarios publicados al momento, no me pierdo ninguna actualización, eso si, aveces no me da tiempo de revisarlas, pero lo que encuentro siempre lo escribo.
Animo con FPG-editor. ;)
Encontré un detalle en el programa:
Tanto en la version de windows como en la de linux. En el panel superior (donde se visualizan las imágenes del disco en la pc), si le doy doble click a una imagen no me aparece previsualizacion, incluso me aparece que es de tamaño X=0 y Y=0, pero si inserta bien la imegen en el FPG, y solo en el FPG puedo previsualizar correctamente.
De lo anterior seria entonces: Cuando abro el programa y directamente quiero previsualizar una imagen del disco duro, no se ve nada y el tamaño es de (0,0), pero si abro un FPG y doy doble click sobre una de sus imágenes si se vé, después de eso, al dar doble click sobre el panel superior, ahora el tamaño e imagen mostrada de previsualización es la ultima abierta del FPG.
No se si me explique bien.
:o , creo que sí se entiende, al dejar oculta esa parte por defecto,(ya que ahora no la veo muy necesaria, ahora puedes cargar las imágenes del tirón con el diálogo de abrir archivo, o incluso arrastrarlas desde un explorador), la dejé un poco olvidada, no creí que los cambios que iba haciendo afectaran a esa parte, echaré un vistazo.
master, eres el master,(y el único que me está siendo de betatester y de gran ayuda, gracias.) ya tengo eso arreglado, actualmente solo versión linux disponible.
la nueva r70 añade idioma para el catalán, también googleado, así que estará como estará.
corrige muchas cosas del idioma inglés, gracias a handsource-dyko (http://forum.bennugd.org/index.php?action=profile;u=419) , y otras tantas que añadí yo. A todo esto, una pregunta,
¿en español es correcto decir Fuente para identificar a un tipo de letra? porque font se traduce como tipo de letra, no como fuente. Creo que fuente es una mala traducción de font. Pero pensando pensando casi siempre usé fuente como sinónimo de tipo de letra y ahora estoy muy confundido a si es correcto o no. :D .
Es una de las razones por la cual participo en foros, para ayudar y compartir, y como aun no se programar muy bien, pues en lo que se pueda. Ademas, es una herramienta que todos los bennuseros usamos. Gracias a ti DCelso.
En cuanto a lo de Font, pues como tu dijiste, la traducción es "Tipo de letra", pero creo que lo mas cercano a font en español seria Tipografía. (la llamada tipografía digital es lo que conocemos como fuente, y entrarian las TTF, OTF, PS y en nuestro caso FNT), pero al igual que tu, yo estoy acostumbrado a llamarles Fuentes.
;), pues habría que corregir esa costumbre para no liar a la gente nueva. Ni a los traducores :). Actualmente uso fuente en fpg-editor y loa traductores la lian por ejemplo al ingles o traducen por source o por power y queda bastante mal. ;D
DCelso, no se si sea un error en el programa, o el error sea que no se usar esta opcion, pero lo que pasa es que cuando intento editar una imagen dentro de un FPG con la opción "Modificar datos de imagen" (Map editor), y le doy a guardar, los cambios que hice no se guardan en el FPG, o no se como mantener los cambios, y si intento exportar (desde el Map editor) la imagen que he modificado a algún otro formato, este queda ilegible, no puedo verlo con un visor común.
También intente cambiar los colores de la paleta de colores de un FPG (de 8 bits) que tengo, y no se ven modificados los colores de la imagen.
Una duda; ¿Solo hay una paleta de colores en un FPG/FNT? o es acaso una por imagen, lo digo porque tambien deberia haber un editor de paleta para el FNT/FPG en general.
Una recomendación; Seria bueno que hubiera opción para agregar imágenes al FPG o para reemplazarlas desde el Portapapeles, porque ahora se puede copiar una imagen del FPG al portapapeles, pero no al revés, y el submenú "Portapapeles" del menú principal siempre esta deshabilitada.
También copiar puntos de control al portapapeles o exportar/importar puntos de control en masa. (esto lo digo porque aveces trabajo con 2 instancias de tu programa pero necesito imágenes de un FPG en el otro y viceversa y necesito editar los puntos de control manualmente)
no me digas, ¿al cerrar con la X, o al darle a archivo salir no te pregunta si deseas guardar los cambios?
si, si me pregunta, yo le doy a "guardar", pero no se ven los cambios aplicados en la previsualización del FPG, pensé que se solucionaría guardando el FPG, pero no.
Solucionado, todo lo tuyo y lo de handsource-dyko (http://forum.bennugd.org/index.php?action=profile;u=419).
nueva versión disponbile para linux
versión windows disponible también ya
Subida versión r74 para linux. Siento bombardearos con tantas versiones hoy pero es que no podía esperar a sacar esta nueva novedad del fpg-editor
Como novedad, incorpora un mini editor de prgs.
Muy útil para programillas cortitos como ejemplos o pruebas, con opción de compilación y ejecución incorporada.
Su nombre se acerca cada vez más a DIV Resources Editor y menos a FPG Editor ;)
¡Muchas gracias por tus aportes DCelso!
Gracias a ti por usarlo ;).
Necesito más betatesters, para sacar posibles fallos, corregirlos y cerrar ya el desarrollo para siempre.
Se aceptan personajes de cualquier índole ;).
Última versión linux disponible, ahora con soporte para cambiar el charset de los prgs.
Ya disponible nueva versión para Windows, como novedad trae poder ver y/o convertir entre formatos de juego de caracteres (charset)
Nueva Rama de versiones.
FPG Editor v4.0
Añade un menú principal desde el cual poder seleccionar qué ventana abrir.
SCREEENNSHOOOOTTTSS!!!
;D.
Es verdad.
Pero lo ejecutaste?
Antes de nada felicidades por tu gran trabajo. Aunque llevo poco por aquí y no nos conocemos, admiro tu trabajo :)
Y ahora viene la parte negativa jejeje nunca se si soy yo solo o a alguien mas también le pasa cuando sale algún error. Como poca gente suele comentar... que al final pareceré que siempre me quejo de algún fallo en el programa, y no es queja, es observación, aviso, o como se quiera llamar.
La versión r77 para Windows, me da error cuando intento abrir algunos fpg. E intentado abrir entre 10 y 15 ficheros, y en algunos me dice lo mismo.
Failed to execute F:\Bennu\bla,bla,bla... \\\zlib\zlib.exe -d
"F:\Bennu\bla,bla,bla... loquesea.fpg" :2.
Aunque, y aquí viene lo raro, si esos archivos que no se pueden abrir los abro con una versión antigua del editor que tengo y los vuelvo a guardar, me los abre sin error. Lo digo por si a alguien le sale el mismo error.
:O, pues eso que dices es justo porque están comprimidos y la r77 parece no ir zlib.exe para descomprimirlos, se me habrá olvidado incluirla. copia zlib.exe de otra versión en la carpeta zlib de la r77.
nueva versión r81, con mínimas correcciones, ahora viene en descarga unificada para windows y linux.
Pues creo que ya no hay errores en el programa, o ya no son tan evidentes :P , solo seria esto:
1)No se si no entiendo muy bien lo de las paletas de colores, pero cuando en el Map editor modifico un color de la paleta de colores de la imagen que abrí, no se ve reflejado el cambio en la imagen ni en las demás contenidas en el FPG.
2)El submenú "Portapapeles" del menú "FPG" en el editor de FPG sigue sin funcionar. Tiene 3 opciones "Copiar", "Pegar" y "Vaciar portapapeles", y ninguna opción funciona, cuando seleccionas alguna, esta se deshabilita y no vuele a estar disponible hasta cerrar el programa.
(la opción "Copiar al portapapeles" del menú contextual al dar click derecho sobre una imagen tampoco me funciona)
Todo lo anterior es en Ubuntu 12.10 de 64 bits
y pues solo los problemas de los que ya hablamos:
Agregar soporte para abrir y guardar FNT de 1 bit en el editor de FPG.
Revisar lo de las fuentes pequeñas que no se generan bien en la versión de linux(QT).
Y como recomendaciones:
1)Como ahora se abre una ventana y desde allí se accede a las herramientas, me gustaria que se pudiese abrir varias instancias de las herramientas. lo digo porque es mas cómodo desde una sola instancia del programa tener varios FPG's abiertos.
2)Me gustaría que desde la nueva interfaz en vez de utilizar menús para acceder a a las herramientas, también hubiera botones en la ventana (botones de acceso rápido) para crear nuevo FNT/FPG/PRG
3)Agregar en el map editor una opción para reemplazar un color concreto de una imagen por otro.
4)Cambiar el titulo del hilo, porque ya llegamos a la versión 4.0
seria bueno que se listaran todas las virtudes de este gran programa
;) , gracias, todo lo que dijiste lo tenía en mente, están en las tareas TODO (Por hacer).
Que últimamente ando un poco liado.
Lo de los fnts de 1 bit que dices, ¿que no los abre el editor de fpgs? dita sea, debería de ir, lo estuve revisando la otra vez, ¿puedes detallar mas cosillas? De todas formas me lo apuntare en las tareas pendientes también.
Respecto a lo de abrir y guardar FNT de 1 bit en el editor de FPG:
Cuando corro por primera vez el programa e intento abrir un FNT de 1 bit desde el editor de FPG (Menu "Ficheros", submenu "Abrir..."), solo me abre el editor pero no me manda ningún mensaje ni me abre el FNT. Cuando abro algun otro FPG o FNT y despues intento abrir un FNT de 1 bit, me manda el siguiente error:
division by zero
se me acaba de ocurrir otra recomendación:
1)Que cuando se reemplaze una imagen dentro de un FPG por otra, así como se mantienen los puntos de control, que también se mantengan el campo "Nombre" y "Nombre de archivo", lo digo porque (solamente) el campo "Nombre" es accesible desde bennugd y puede que alguien lo use y el otro campo ("Nombre de archivo") es indispensable para guardar desde el editor de FPG un FNT, y cuando reemplazo una imagen estos campos cambian.
Una duda, ¿que diferencia tienen las gamas de colores con la paleta de colores, que utilidad tienen en bennugd? Entiendo que solo es para tener bien organizados los colores de la paleta para un acceso rápido y facilitar el pixel art. ¿cierto?
Quote from: master on April 01, 2013, 04:33:12 PM
Respecto a lo de abrir y guardar FNT de 1 bit en el editor de FPG:
Cuando corro por primera vez el programa e intento abrir un FNT de 1 bit desde el editor de FPG (Menu "Ficheros", submenu "Abrir..."), solo me abre el editor pero no me manda ningún mensaje ni me abre el FNT. Cuando abro algun otro FPG o FNT y despues intento abrir un FNT de 1 bit, me manda el siguiente error:
division by zero
Gracias, Revisaré esto.
Quote from: master on April 01, 2013, 04:33:12 PM
se me acaba de ocurrir otra recomendación:
1)Que cuando se reemplaze una imagen dentro de un FPG por otra, así como se mantienen los puntos de control, que también se mantengan el campo "Nombre" y "Nombre de archivo", lo digo porque (solamente) el campo "Nombre" es accesible desde bennugd y puede que alguien lo use y el otro campo ("Nombre de archivo") es indispensable para guardar desde el editor de FPG un FNT, y cuando reemplazo una imagen estos campos cambian.
Puedes cambiarlo a posteriory dándole a editar. Siempre se hizo así esta parte por guardar el nombre de archivo del origen y poder recuperar su nombre original al exportarlo a imagen (png u otro formato) Pero estudiaré el caso, ahora con los FNT quizas no tenga tanto sentido ;D, quizás si solo lo evito en caso de FNT ...
Quote from: master on April 01, 2013, 04:33:12 PM
Una duda, ¿que diferencia tienen las gamas de colores con la paleta de colores, que utilidad tienen en bennugd? Entiendo que solo es para tener bien organizados los colores de la paleta para un acceso rápido y facilitar el pixel art. ¿cierto?
Muy cierto, solo sirven para diseño de pixelart. En div nació con esa idea. DIV solo soportaba fpgs e imágenes de 8 bits.
Entonces esta técnica se podría usar para poder tener varias imágenes (de menos profundidad, imaginate de 4 bits (16 colores) ) conviviendo juntas del mismo fpg se podía usar esta técnica y hacer que cada gama fueran los colores de una imagen de 4 bits, pudiendo tener dentro del mismo fpg como 16 paletas distintas para 16 imágenes de 4 bits distintas.
Pero no queda reducido ahí su potencias, como verás, muchas imágenes podrían compartir colores, entonces organizando adecuadamente las gamas, podrías meter más de 16 imágenes de 4 bits distintas sin perder sus colores.
Pero en antaño, en 8 bits, había una cosa que hoy en día se ha perdido su uso, que era el cambio de paleta de colores para generar al segundo jugador o incluso a enemigos distintos. Imagínate un personaje con pantalones azules y camisa blanca, tendrías una gama de colores de azules y blancos, para así hacerle sombras a la ropa. Pues simplemente cambiando esa gama de colores a colores rojos y rosas podrías hacer que el personaje cambiase su vestimenta, por pantalones rojos y camisa rosa, (por ejemplo Double dragon)
Esta técnica se podía implementar usando gamas de colores. Si divides tus 256 colores de tu fpg en 16 gamas de colores, podrías conseguir cambiar de color 16 objetos distintos a la vez independizando sus colores. Es decir, por ejemplo si cada gama la usas para colorear un objeto de pantalla, imaginate el jugador, un enemigo una lámpara, la calle. Podrías tener al enemigo azul (usando una gama) , al jugador azul (usando otra) , la lampara gris (usando otra) y la calle gris (usando otra distinta mas). Y simplemente cambiando la paleta del fpg, podrías hacer que el jugador vistiera de verde, el enemigo de amarillo, la lámpara de azul, la calle de rojo, sin que se solapasen sus colores, ya que cada uno usaría su azul o gris de su gama y no el de otra.
Hoy en día esta técnica en 32 bis se puede medio simular dibujando tu imagen en escala de grises y luego poniéndole encima una plantilla con la silueta de la misma imagen con un color deseado y una componente de transparencia. Imagina un limón en escala de grises al que delante le pones una plantilla del mismo limón de color verde con alfa 128, (algo así como en la vida real a una foto en blanco y negro de un limón le pones un papel semitransparente verde ).
En fin, fpg edit en 8 bits debe de usar la paleta como un conjunto de 256 colores seleccionables entre todos los colores posibles. y las gamas de color como un conjunto de colores seleccionables solamente de la paleta de colores (son como mini paletas de la paleta)
En otro modo distinto a 8 bits, la paleta y las gamas se usan igual, un conjunto de colores de todos los posibles para acceder rápidamente para dibujar cosas.
Hola, por un lado quería ver si podía mejorar el FPG Editor ya que yo llevo años usando Lazarus. Es más, una vez hice un jueguito en Lazarus un par de años después de que usaba DIV. Y comencé con Delphi años anteriores cuando tenía Win, luego me pasé a Lazarus cuando comencé con Linux. Y bueno, eso ya fue hace como 12 años, algo de experiencia en ese lenguaje tengo.
Bueno, el asunto es que puedo colaborar con este software, pero... Igual ya son muchas tareas en las que me voy a meter, por eso no quiero prometer nada, prefiero primero darle prioridad al problema de video que tiene la versión actual de BennuGD.
Ahora, lo que realmente me decidió a responder acá es que estaba leyendo que hablabas de gamas de la paleta. Y aún tengo el DIV2 original y lo ejecuto bajo DOSBOX. Y que yo recuerde no existía una gama, o que se llame así. Pero creo que entiendo a lo que te refieres, te refieres a la parte de la paleta que tiene variaciones de colores en distinta intensidad organizada en filas.
La verdad no me acuerdo si eso estaba explicado en el libro original de DIV o si fue una técnica que comenzaron a emplear muchos creadores de juegos en DIV.
Pero es eso a lo que te refieres, verdad? Porque cuando cargo un map en el DIV2 o un FPG me obliga a cargar una paleta, generarla, o adaptar la carga del archivo a la paleta actual. O sea, sólo puedo manejar una paleta por vez, no existen más paletas cargadas a la vez. Solamente una por vez y cada vez que abres un nuevo map diferente puedes elegir cargar su propia paleta o adaptar su carga con la paleta actual. No veo que haya otra opción, al menos en DIV2.
Estoy viendo y me dice:
Se leyó una paleta nueva...
- Adaptar a la paleta actual
- Fusionar con la paleta actual
- Cargar la nueva paleta
Evidentemente no se pueden tener dos archivos FPG abiertos a la vez con dos paletas distintas. Al menos en DIV2 no.
Bueno, en realidad no me importa mucho para mi, pero lo quiero tener en claro para el tema de las funciones de blit que quiero reescribir para BennuGD.
Si alguien más puede sumarse a la charla o mejor tal vez sea conveniente iniciar un nuevo tema en los foros con este asunto.
Sugerencias acepto.
Que tengas un buen día.
Si DCElso esta de acuerdo le podrás ayudar, ya que es el que 'oficialmente' ha currado en esta aplicacion los ultimos años.
Por otro lado tambien se esta portando a mi tool BennuGD .Net Tools, la cual tambien se podrá usar para editar fpg's, pero todavia no esta disponible.
Sobre DIV2, por suerte tambien tengo los originales, el 1 y 2, pero aunque en el pasado por nostalgia he apoyado la importandcia de DIV en los div likes actuales, ya no veo que sea tan importante dar soporte o total compatibilidad a DIV en llos entornos actuales.
Creo que se debe pensar en dar soporte a otras tecnologias mas recientes que seguir insistiendo en la compatibilidad con el pasado.
anyeos las gamas de color ya lo he repetido unas cuantas veces. no son nuevas paletas si no una forma de organizar los 256 colores de tu paleta actual en 16 o 32 conjuntos distintos. Nunca tendrás más de 256 pero sí 32 ordenaciones distintas de éstos 256 colores.
Ya he reiterado unas cuantas veces que esto solo sirve para la hora de edición de imágenes, parece que no usaste mucho o nada esta parte de edición de dv1 y div2. ya que te hubiera quedado clarísimo que sin la configuración de gamas de colores no puedes editar nada en div ;) .
Div guardaba estas gamas en los maps y fpgs, para que no tuvieras que estar configurando cada dos por tres estas gamas al editar imágenes, no sirven para nada en el juego final, estarian de adorno, es por ello que fenix nunca las usó, no estaba orientado a edición de maps o fpgs, solo a su uso para desarrollar juegos. Como esta herramienta está orientada a justo todo lo contrario, creí ver la necesidad de recuperar dicha peculiaridad en imágenes de 8 bits, y ya que me puse, pues apliqué una misma estrategia para 16 y 32 bits, haciendo que tanto la paleta como las gamas en el editor de imágenes en modos distintos a 8 bits funcionen como colecciones de colores de rápido acceso, lo malo es que el formato fpg no guarda paletas ni gamas en esos modos, así que no se guardan.
En cuanto a modificar o ayudar con el desarrollo, pues por mi de PM, tío, empieza con bajarte el código fuente, disponible bajo control de versiones svn, y compilarlo.
Si encuentras o te dicen algún fallo y creas alguna modificación, pues crea un .patch y lo inserto sin problemas en la rama oficial.
Respuesta para @FreeYourMind:Lo que pasa que SplinterGU me dijo que esa era la condición de que debía ser compatible con eso el blit.
Pero yo la verdad que prefiero programar a partir de 16 bits para arriba. Y también si puedo de una ya usar OpenGL, claro, con la opción de no usarlo al iniciar el modo de video. O sea, añadiría una nueva bandera que activa el modo de aceleración OpenGL y un juego se seguiría programando igual nada más que ahora en vez de hacer todo eso por soft lo haría por hard. Obviamente que creo que iría mucho más rápido.
Pero mi idea es no tener que cambiar el código en tu juego, sino que el blit se encargaría de aprovechar el OpenGL si está disponible y si inicias el video en ese modo. De esta forma los mismos juegos que ya se hicieron a partir de 16 bits podrían fácilmente pasarse a 24 bits con OpenGL sin tener que cambiar nada, ni siquiera creo que hubiera necesidad de cambiar los FPG.
Dije 24 bits porque es como trabajan las tarjetas Nvidia con OpenGL para que funcione la aceleración del buffer Z, según recomienda NVIDIA. Pero funcionaría en 16 bits y 32 bits también. Aunque creo que en 16 andaría más rápido. Por eso mejor prefiero agregar el modo 24 bits y listo.
Pero bueno, igual voy a empezar por el modo de 16 bits que es el que ando usando ahora. Después se añadirán los demás si se necesitan.
Pero hay una cosa que no entiendo, por eso vine para acá:
Los puntos en un map (bitmap), por qué son varios? O sea, según tengo entendido el punto central determina justamente el medio de la imagen, donde las coordenadas X e Y van a ir a parar. Los otros puntos, como funcionaban? Había que elegirlos? Porque en el código del blit no veo que haga referencia a todos, simplemente figura un punto central.
Es correcto eso?
¿Actualmente para qué sirve tener varios puntos de control?
Eso quisiera saber.
Por lo de FPG EditorTenía más bien pensado tocar la parte del editor de programa porque quiero uno que me ayude bastante con el trabajo de editar un proyecto.
Así que lo único que voy a modificar va a ser eso, lo de los FPG, las FNT y todo lo demás no lo voy a tocar.
Al editor de programas le quisiera poner:
- Más opciones de configuración (Personalizar el resaltado de sintaxis y un par predefinido)
- Autocompletar (Que autocomplete con funciones tanto propias de BennuGD como process, globales, locales, etc del usuario)
- Salto a procedimiento (con clic derecho te daría la opción para saltar al procedimiento o la variable o lo que estés seleccionando).
- Ir a línea, buscar, reemplazar (eso ya está hecho igualmente)
- Automáticamente posarse sobre el fuente y el número de línea de un error en la compilación.
- Autosalvado y compilado al intentar ejecutar el programa
- Posibilidad de depurar el programa
- Abrir varios .prg en pestañas.
Podría trabajar también con "Proyectos" en lugar de abrir un prg así nomás, pero eso lo vería después.
Respuesta para @DCelso:Hola DCelso, que tal, gracias por responder. Sí, tienes toda la razón jamás usé esa funcionalidad en DIV. Lo que me importaba en aquel entonces era que mi juego funcionara bien jaja, no le prestaba tanta atención a cambio de colores era más importante para mí que funcionara y ya.
Igual no pude usar mucho DIV, lo compré como en 2001 y luego tuve un problema en el disco duro y perdí mis proyectos de juego. Me amargué tanto que me desanimé y aparte otras cosas me hicieron no tener tiempo para eso.
Luego al año siguiente creo, o en 2003, vi en una tienda el DIV2 y también lo compré, con la idea de por fin poder empezar un proyecto de videojuego ya un poco mejor (suponía que la 2 era mejor). Sí, algunas mejoras tenía, no lo dudo, pero de vuelta algo similar me pasó perdí el trabajo y bue, otra vez, lo abandoné.
Porque me había costado tanto trabajo que me cansó. Obviamente que no tenía la culpa DIV pero el otro problema gravísimo para mí era que el DOS estaba pasado de moda. Quien le iba a dar auge a jugar a esos juegos bajo DOS. Ya para cuando logré tener algo casi como un juego era una época donde lo que estaba de moda era el Windows 98 y luego el Millenium y el 2000 que no tuvo mucho éxito en fin.
Pero me interesé en cambiarme a Linux, para mi sorpresa aún era peor, de un DOS a Linux, el DIV no iba a correr ni soñando. Ya cada vez era más imposible lograr eso. Entonces como usaba Delphi y estaba haciendo un software para otra cosa, y me pasé a Lazarus, pues, hice uno de mis juegos en Lazarus (Free Pascal) directamente y dejé ya de lado el DIV.
Luego me puse a buscar y conseguí Fenix, pero tampoco era para Linux sino para Windows. Y así con tantos problemas era más fácil hacer cualquier otra cosa que un juego en DIV.
Hasta que comenzó a hacerse andar Fenix en Linux y luego apareció @SplinterGU con BennuGD que fue cuando comencé recién a intentar retomar el DIV nuevamente. Primero con el Fenix que me andaba en Linux y luego con BennuGD cuando también comenzó a funcionar en linux. Pero eso no fue hace mucho.
Y como te habrás dado cuenta, el tema de los 8 bits me quedó muy en la historia, una historia que ni siquiera yo viví mucho. Así que siempre trabajé a partir de 16 bits y sin paletas. Que para mí fue un alivio porque la paleta además de que te baja la calidad de los gráficos es un tema que hay que prestar atención y trabajar más para hacer encajar todos los gráficos a una paleta más o menos decente y que quede bien.
Y hoy día no me atrevo a desarrollar un juego con paleta porque se alcanza a notar esa deficiencia de colores y la gente es muy prejuiciosa y capaz que el juego está muy bien armado pero seguro no faltarían aquellos que digan que tiene gráficos antiguos y cosas así. Lo que le daría mala propaganda al juego.
Pero el otro tema es que cuesta más trabajo porque hay que andar trabajando con paletas a la hora de hacer los gráficos.
Quote from: Anyeos on April 24, 2013, 08:15:52 PM
Por lo de FPG Editor
Tenía más bien pensado tocar la parte del editor de programa porque quiero uno que me ayude bastante con el trabajo de editar un proyecto.
Así que lo único que voy a modificar va a ser eso, lo de los FPG, las FNT y todo lo demás no lo voy a tocar.
Al editor de programas le quisiera poner:
- Más opciones de configuración (Personalizar el resaltado de sintaxis y un par predefinido)
- Autocompletar (Que autocomplete con funciones tanto propias de BennuGD como process, globales, locales, etc del usuario)
- Salto a procedimiento (con clic derecho te daría la opción para saltar al procedimiento o la variable o lo que estés seleccionando).
- Ir a línea, buscar, reemplazar (eso ya está hecho igualmente)
- Automáticamente posarse sobre el fuente y el número de línea de un error en la compilación.
- Autosalvado y compilado al intentar ejecutar el programa
- Posibilidad de depurar el programa
- Abrir varios .prg en pestañas.
Podría trabajar también con "Proyectos" en lugar de abrir un prg así nomás, pero eso lo vería después.
:), todo eso lo tenía en mente añadir, el problema es el tiempo, así que si te animas y vas metiendo poco a poco esta parte al programa seria perfecto ;)
sobre los 8 bits, disiento, no tiene que perder calidad un juego en 8 bits, ocupan menos, consumen menos recursos, hace mas multiplataforma al juego, ofrece muchas ventajas, por ejemplo puedes cambiar la paleta y cambiar todos los colores para darle un aspecto distinto al juego sin modificar ni un solo gráfico, para los juegos a los que está orientado bennu va mas que sobrado.
Tengo buenas noticias estoy estudiando más sobre bitmaps, los formatos de pixel, el canal alfa y sobre composición de imágenes pixel a pixel.
Cuando termine de comprender bien todo eso me va a costar menos trabajo implementar una solución que abarque todos los requisitos. Y estoy viendo que no parece muy difícil trabajar en todos los formatos de bits que se quieren. Así que yo creo que de entrada nomás voy a tener todos los formatos inclusive los 8 bits.
Sería muy parecido a lo que ya hay pero voy a procurar instruirme bien para lograrle sacar el máximo provecho posible.
Saludos.
PD: Para no irme de tema acá mejor lo sigo por este otro lado -> http://forum.bennugd.org/index.php?topic=3538.0
Me gustaría, si fuera posible, poder exportar las fuentes utilizando el nombre código-1+".png"
Los códigos actualmente son ASCII+1
Me explico. Ahora mismo esto está así:
@ -> ASCII 64 -> FNT 65 -> 65.PNG
Y me gustaría tener esta opción:
@ -> ASCII 64 -> FNT 65 -> 64.PNG
Sólo quería responder a Anyeos sobre el tema de los puntos de control.
Antes que nada, saludarte, porque no te había visto antes por aquí. Veo que te has metido en el tema del core: buena suerte.
Al lío: los puntos de control son eso, puntos que sirven de referencia dentro de un gráfico. Usando get_real_point nos permite situar, por ejemplo, un proceso "arma" en las manos del protagonista, aunque este cambie de gráfico: si todos los gráficos de la animación tiene un punto de control 1 situado en la mano, usando dicha función nos aseguramos que siempre esté el arma en la mano.
Esto sirve para indicar otra serie de puntos clave, por ejemplo, desde dónde se debe disparar, los ejes de rotación para las diversas articulaciones de un muñeco, dónde deben ir colocadas las ruedas de un coche... todo esto sin importar el gráfico, la rotación o el escalado del mismo.
Obviamente, esto al blitter le da igual, ya que los puntos de control son coordenadas que se pueden calcular matemáticamente, no tiene nada que ver con dibujar el gráfico. Quizás le pueda afectar por el tema de rotación y/o escalado del gráfico en sí, pero por lo que leí del código en su día, no lo creo.
También existe la función "get_point", que devuelve las coordenadas relativas al propio gráfico de ese punto de control, pero no tiene en cuenta ni escalados, ni rotaciones ni nada.
Son realmente útiles para manejar procesos dependientes de otros, o para situar gráficos en pantalla reduciendo cálculos.
PD: tengo que probar esta nueva versión de FPGEdit, que aun sigo con la primigenia :D
PD2: también tengo que averiguar por qué no soy capaz de meter cualquier map en una FNT de 16 bits :lol:
¿Hay que tener algún paquete instalado en Linux para hacerlo funcionar? me dice que no se encuentra un .so (libQt4Pas.so.5).
Instalé el paquete libQt4Pas5 y seguía insistiendo en lo mismo.
Estoy intentado hacer correr FPG Editor V 4.0, y me sale el mismo error que Drumpi.
De momento ire tirando con la version de windows mediante el Wine.
superraro, lo único que hay que instalar es eso libqt4pas5 y claro ( libqtgui4 y demás pesca) pero eso creo que viene instalado de serie en casi todas las distros .
yo he hecho lsof -c fpg-editor y me salen una hartá de .so, pero el que tu dices en cuestión es este /usr/lib/i386-linux-gnu/libQt4Pas.so.5.2.5
mira a ver que versión tienes instalada de ese fichero y en qué ruta está. quizás solo necesites hacer un ln -s del que tengas al que te pide "libQt4Pas.so.5" que le haya faltado hacer a tu instalador de tu distro
Drumpi y kim-elet-o
me pasaba lo mismo, solo instalen la lib, por ejemplo, yo tengo ubuntu de 64 bits:
$ sudo apt-get install libqt4pas-dev:i386
y con eso me funcionó
Ok master, faltaba esa libreria por instalar, gracias.
Por el nombre de la libreria, deduzco que es una libreria de desarrollo para 32 bits, quizas el problema sea que se ha compilado la ultima version con una libreria de desarrollo, en vez con la libreria de produccion.
De todos modos gracias DCelso por el desarrollo de su herramienta, y gracias a master por la solucion de mi problema.
Puede que sea eso, la versión dev, y que sea la de i386 (como mi SO es de 64, pues pensaba que necesitaba la lib de x64).
He estado mirando unas cuantas páginas de este hilo y de otros y no he encontrado algo que me aclare una duda que tengo, y como ya estoy un poco mareado, os cuento...
Estoy tratando de usar los mapas (imágenes .png) de un archivo .fpg de 32 bits y generado con este mismo programa en un modo de 16 bits, pero, cuando hago los "map_put" para imprimirlos por pantalla, sencillamente no aparecen, no se dibujan.
Sin embargo, si cargo los mismos archivos en su formato original .png mediante "load_png" y después los muestro por pantalla mediante "put_map", entonces sí que no hay problema: sí que aparecen en pantalla.
Tengo la sensación de que en este último caso sí que se hace la conversión de 32 bits de los archivos .png a 16 bits del modo gráfico, mientras que en el primer caso parece como que no se hace la conversión (u otra cosa) de los mapas que hay dentro del fichero .fpg y por eso no se muestran en pantalla, y la verdad es que me llama la atención.
¿existe alguna forma de poder mostrar los gráficos (.png originales como digo) de un fichero .fpg de 32 bits en un modo de 16 bits? ¿o no queda otra que que guardarlos en un fichero .fpg de 16 bits?
Me interesaría que se pudieran guardar en el de 32 bits por cuestiones varias, como por ejemplo, no perder calidad en los gráficos al evitar la conversión a 16 bits.
Un saludo.
Pues para empezar, es raro que te haya permitido cargar un FPG de 32bits en modo 16bits, porque Bennu debería haberse cerrado con un mensaje indicando error.
Es normal que te cargue los PNG de 32bits porque al estar en un modo de 16bits, el propio Bennu lo carga generando un mapa de 16bits (te hace una auto conversión), pero no deberías poder usar FPG de 32bits.
Puedes usar gráficos de menos bits en modos superiores, pero nunca al revés.
Además, las imágenes dentro de un FPG ya no son PNG, son formato MAP de 1, 8, 16 o 32 bits
Claro, es que es precisamente a eso a lo que me referí, que de igual manera que al cargar un gráfico de 32 bits con load_png este se adapta en memoria a los 16 bits del modo gráfico, que también los mapas que contiene el archivo fpg (aunque de origen sean de 32 bits) se conviertan en memoria a mapas de 16 bits como el modo gráfico.
Yo pensaba que load_fpg te hacía tal conversión en un modo de 16 bits, pero por lo que me has contado ya veo que no.
Al final me estoy apañando con la alpha de marzo (Android 2.3.3) de BennuGD Android, porque con "la de octubre" no puedo establecer el modo gráfico a 32 bits sin tener problemas con los colores de los gráficos pues salen cambiados (que luego el logCat me saca como que de todas formas se está trabajando en una "Surface" 565 bits, pero bueno).
Gracias por la respuesta, y Feliz Navidad :)
Hombre, a las malas, siempre te puedes hacer tu propio cargador de FPGs con conversión, no es difícil. De hecho, yo he cargado ya muchos FPGs usando FOPEN y demás (para alguna herramienta de conversión de colores, de renombrado sin usar el modo gráfico... cosillas tontas).
En la wiki está toda la info del formato en todas sus variantes. Para pasar de 32 a 16 bits sólo necesitas coger las componentes RGBA y hacer divisiones/desplazamientos para obtener los valores RGB 565, y ya tú decides qué hacer con el alpha: si ignorarlo, establecerlo al 50%...tienes control total.
Lo único que no he conseguido hacer aun son FPGs y FNTs de 1bit ^^U
Por cierto ¿cómo puedo en el FPGEdit modificar/seleccionar la paleta que quiero usar? En el 2006 y anteriores, al crear un FPG de 8bits era lo primero que me pedía ¿ahora sólo se puede hacer mediante conversión?
Quote from: Drumpi on December 25, 2013, 12:57:21 PM
Hombre, a las malas, siempre te puedes hacer tu propio cargador de FPGs con conversión, no es difícil. De hecho, yo he cargado ya muchos FPGs usando FOPEN y demás (para alguna herramienta de conversión de colores, de renombrado sin usar el modo gráfico... cosillas tontas).
En la wiki está toda la info del formato en todas sus variantes. Para pasar de 32 a 16 bits sólo necesitas coger las componentes RGBA y hacer divisiones/desplazamientos para obtener los valores RGB 565, y ya tú decides qué hacer con el alpha: si ignorarlo, establecerlo al 50%...tienes control total.
Lo único que no he conseguido hacer aun son FPGs y FNTs de 1bit ^^U
Por cierto ¿cómo puedo en el FPGEdit modificar/seleccionar la paleta que quiero usar? En el 2006 y anteriores, al crear un FPG de 8bits era lo primero que me pedía ¿ahora sólo se puede hacer mediante conversión?
Claro, si por hacer se podría hacer, pero la verdad es que prefiero invertir el tiempo y la energía en otras cosas, que total y como ya he contado, me estoy apañando con la alpha de marzo de BennuGD Android con la cual sí que salen bien los colores con el set_mode a 32 bits.
De todas formas, te agradezco tu sugerencia ;)
Sobre tu pregunta, pues siento no poder responderte, porque yo el FPG Editor apenas lo he usado, y cuando lo he hecho, no ha sido para manejar las paletas. Espero que alguien pueda explicarte cómo se hace, pero si lo averiguo y aun no lo sabes te lo digo, desde luego.
Voy a aprovechar el post para lanzar unas preguntillas que me rondan:
¿El FPG Editor no puede crear los .fpg comprimidos? es que no he encontrado tal opción, y sin embargo, con uno de los editores que trae el BennuPack, el Smart FPG Editor sí que los comprime.
El problema, es que me da a mí que el BennuGD Android no puede abrir los .fpg comprimidos lo cual es una lástima por dos razones (que se me ocurren):
a) los gráficos quedan a la vista/disposición de cualquiera (lo cual no mola la verdad)
b) el ahorro en cuanto a espacio que ocupan es brutal, lo cual es muy valioso de cara a mejorar los tiempos de descarga de nuestros juegos de las "store", pues obviamente no es lo mismo descargar 15MB que, por ejemplo, 5MB.
Esto ya se habrá hablado supongo, e incluso a lo mejor me estoy equivocando y sí que se existe soporte de archivos .fpg comprimidos desde BennuGD Android (y es que llevo solamente "4 días" reenganchado al mundo BennuGD, y tan solo "medio" al de BennuGD Android), pero he hecho una prueba rápida y no los cargaba (tampoco he leído que tipo de error soltaba la load_fpg, la verdad, pero bueno).
En el nuevo FPG Edit tienes la herramienta de compresión. No significa que te cree un fichero .zip, sino que te comprime el FPG/FNT en el formato que admite Bennu (GZIP, si no recuerdo mal).
Que esté comprimido no quiere decir que nadie pueda leerlo, de hecho, es fácil descomprimirlo porque se usa un algoritmo muy utilizado (lo dicho, creo que es GZIP). De todas formas, para que alguien pueda leer un FPG se necesita un programa capaz de abrir un FPG, no puedes usar el Paint o el Potochof para modificarlos. Claro que el FPG Edit te permite modificarlos (comprimidos o no), pero para eso se hizo. Si lo que quieres es un formato que nadie pueda modificar, te tienes que crear tu tus propios formatos y utilidades de edición.
El tema de compresión no sé hasta qué unto es correcto lo que dices: sí, comprimidos los gráficos ocupan menos, pero luego deben ser descomprimidas en memoria, lo cual consume tiempo. No sé si los juegos hechos en Bennu se empaquetan, como se hace con los JAR, pero hasta donde sé, los ficheros de Java .JAR son ficheros comprimidos como los .ZIP, por lo que los FPG se comprimirían de la misma manera y ocuparían lo mismo lo comprimas tú o no.
Yo siempre intento tener los FPG sin comprimir, porque así sé lo que ocuparán en memoria, y si tengo que compartir el juego, lo comprimo en un ZIP, y punto.
Pero lo dicho, en Android no sé cómo va el tema.
Quote from: Drumpi on December 24, 2013, 08:23:47 PM
Pues para empezar, es raro que te haya permitido cargar un FPG de 32bits en modo 16bits, porque Bennu debería haberse cerrado con un mensaje indicando error.
Es normal que te cargue los PNG de 32bits porque al estar en un modo de 16bits, el propio Bennu lo carga generando un mapa de 16bits (te hace una auto conversión), pero no deberías poder usar FPG de 32bits.
Puedes usar gráficos de menos bits en modos superiores, pero nunca al revés.
Además, las imágenes dentro de un FPG ya no son PNG, son formato MAP de 1, 8, 16 o 32 bits
Hola, se que el hilo no tiene que ver especificamente con lo que te voy a preguntar pero si es sobre el tema? este formato MAP que mensionas como esta almacenado? Por ejemplo, los pixeles de 32 bits estan guardados como RGBA8888 o tiene algun enmascaramiento? Es para un proyecto que estoy haciendo para esta comunidad. Necesito manejar FPGs desde Java y tengo un problema con los colores. Adjunto como se ve (Captura del programa en ejecucion) y como se deberia ver (Captura del photoshop).
Desde ya muchas gracias y disculpen si es incorrecto preguntarlo aca.
Saludos.
bennugd no se cierra por abrir un fpg de 32 en 16bits, simplemente no lo muestra en pantalla, pero se pueden hacer otras cosas con el, mientras no sea quererlo mostrar.
Quote from: proteo on March 25, 2014, 09:12:54 PM
Quote from: Drumpi on December 24, 2013, 08:23:47 PM
Pues para empezar, es raro que te haya permitido cargar un FPG de 32bits en modo 16bits, porque Bennu debería haberse cerrado con un mensaje indicando error.
Es normal que te cargue los PNG de 32bits porque al estar en un modo de 16bits, el propio Bennu lo carga generando un mapa de 16bits (te hace una auto conversión), pero no deberías poder usar FPG de 32bits.
Puedes usar gráficos de menos bits en modos superiores, pero nunca al revés.
Además, las imágenes dentro de un FPG ya no son PNG, son formato MAP de 1, 8, 16 o 32 bits
Hola, se que el hilo no tiene que ver especificamente con lo que te voy a preguntar pero si es sobre el tema? este formato MAP que mensionas como esta almacenado? Por ejemplo, los pixeles de 32 bits estan guardados como RGBA8888 o tiene algun enmascaramiento? Es para un proyecto que estoy haciendo para esta comunidad. Necesito manejar FPGs desde Java y tengo un problema con los colores. Adjunto como se ve (Captura del programa en ejecucion) y como se deberia ver (Captura del photoshop).
Desde ya muchas gracias y disculpen si es incorrecto preguntarlo aca.
Saludos.
Tienes intercambiados el Red y el Blue. Si estás leyendo RGB, intenta leer BGR. O viceversa y solucionado tu problema.
Yo tengo una versión alfa de un port que hice de fpg edit a java, todo desde 0, tengo que buscarlo pero que sepas que abandoné la migración a favor de "lazarus" ya que java era muy muy lento con el procesamiento de imágenes y ficheros y más comparado con lazarus. Claro está eran otros tiempos sin pcs de más de un núcleo ni 64 bits :D
Quote from: DCelso on May 15, 2014, 04:32:43 PM
Quote from: proteo on March 25, 2014, 09:12:54 PM
Quote from: Drumpi on December 24, 2013, 08:23:47 PM
Pues para empezar, es raro que te haya permitido cargar un FPG de 32bits en modo 16bits, porque Bennu debería haberse cerrado con un mensaje indicando error.
Es normal que te cargue los PNG de 32bits porque al estar en un modo de 16bits, el propio Bennu lo carga generando un mapa de 16bits (te hace una auto conversión), pero no deberías poder usar FPG de 32bits.
Puedes usar gráficos de menos bits en modos superiores, pero nunca al revés.
Además, las imágenes dentro de un FPG ya no son PNG, son formato MAP de 1, 8, 16 o 32 bits
Hola, se que el hilo no tiene que ver especificamente con lo que te voy a preguntar pero si es sobre el tema? este formato MAP que mensionas como esta almacenado? Por ejemplo, los pixeles de 32 bits estan guardados como RGBA8888 o tiene algun enmascaramiento? Es para un proyecto que estoy haciendo para esta comunidad. Necesito manejar FPGs desde Java y tengo un problema con los colores. Adjunto como se ve (Captura del programa en ejecucion) y como se deberia ver (Captura del photoshop).
Desde ya muchas gracias y disculpen si es incorrecto preguntarlo aca.
Saludos.
Tienes intercambiados el Red y el Blue. Si estás leyendo RGB, intenta leer BGR. O viceversa y solucionado tu problema.
Yo tengo una versión alfa de un port que hice de fpg edit a java, todo desde 0, tengo que buscarlo pero que sepas que abandoné la migración a favor de "lazarus" ya que java era muy muy lento con el procesamiento de imágenes y ficheros y más comparado con lazarus. Claro está eran otros tiempos sin pcs de más de un núcleo ni 64 bits :D
Muchas gracias por tu respuesta, ya pude solucionar el problema de los colores, ahora lo que tengo que solucionar es el tiempo de carga que tarda como 10 segundos en cargarme un archivo que Bennu lo carga casi instantáneamente, seguramente debe ser porque leo del archivo los bytes de a 4 en lugar de leerlos todos juntos haciendo alto_imagen x ancho_imagen x 4. Igualmente este tema lo deje pausado por ahora para continuar con la traduccion del lenguaje, si queres saber mas sobre mi proyecto esta en un hilo en este mismo foro (Bennu2Java).
Saludos.
Buenas :)
Desde luego el programita está de lujo, yo lo vengo usando desde tiempos inmemoriales ;D
Pero hay una cosa que no me termina..., no sé si será por la ultima versión que bajé...
Los gráficos nuevos que se van añadiendo al FPG se colocan al final aunque tengan numeros inferiores a otros ya incluidos en el FPG.
En otras palabras que si inserto graficos nuevos en huecos dejados en el FPG se van al final, aunque conservan su numero quedan desordenados en la ventana de visualizacion de imagenes del FPG...
Quote from: Coptroner on May 22, 2014, 09:04:53 AM
Buenas :)
Desde luego el programita está de lujo, yo lo vengo usando desde tiempos inmemoriales ;D
Pero hay una cosa que no me termina..., no sé si será por la ultima versión que bajé...
Los gráficos nuevos que se van añadiendo al FPG se colocan al final aunque tengan numeros inferiores a otros ya incluidos en el FPG.
En otras palabras que si inserto graficos nuevos en huecos dejados en el FPG se van al final, aunque conservan su numero quedan desordenados en la ventana de visualizacion de imagenes del FPG...
FPG Editor?
Nueva versión, FPG Editor 4.0 r83, disponible.
Corrige un error por el cual no leía bien los FNT de 1 bit.
Como ya google no deja subir archivos a googlecode, lo tuve que subir a google drive.
https://drive.google.com/file/d/0B68H6eAaxbrLUk05eU9KbjhtOTA/edit?usp=sharing (https://drive.google.com/file/d/0B68H6eAaxbrLMG8yNkJGeDAxQzQ/edit?usp=sharing)
No me deja descargarlo, me dice que tiene virus y que "solo el propietario del archivo puede descargar archivos infectados".
Quote from: master on May 26, 2014, 02:55:15 AM
No me deja descargarlo, me dice que tiene virus y que "solo el propietario del archivo puede descargar archivos infectados".
Lo mismo.
:o
https://drive.google.com/file/d/0B68H6eAaxbrLUk05eU9KbjhtOTA/edit?usp=sharing
lo mismo twice ;D
He pasado el antivirus desde un cdlive y no tengo ningún virus. o al menos parece eso. Uff, que susto. Creo que es el nuevo formato de 7z que no le mola a google. lo subí en zip normal, probad ahora.
lo mismo third strike
:-X
https://docs.google.com/file/d/0B68H6eAaxbrLUk05eU9KbjhtOTA/edit?usp=sharing&pli=1
Oooooooooooout. Doble falta XD, punto para...
(http://dayanayfreddy.com/wp-content/uploads/negocios-multinivel-cuatro.jpg)
esto como va a ser?, me lo he descargado de dos equipos distintos sin problemas.
y me sale como una especie de winzip web desde el que puedo el contenido del zip y hacer archivo - descargar.
en esa opcion despues entra en una pagina que pone:
Lo sentimos, pero este archivo está infectado
Solo el propietario puede descargar archivos infectados.
a ver ahora
https://drive.google.com/file/d/0B68H6eAaxbrLVmxNblFzYktENFk/edit?usp=sharing
(http://thesource.com/wp-content/uploads/2014/02/George-Zimmerman.jpg)
;) , ala, ya tienes más trabajo, volver a portar fpg-edit :D.
jjajja, como no pones el src tiene que ser fácil xDD
Por cierto he retomado mi app, pero ahora estoy con el prg editor a ver si con suerte mañana por fin lo hago funcionar xD
Y mira tus mp capullin :-[
:o , voy a mirarlos.
por cierto, rXX es de revisión SVN XX, es decir, si pone fpg-editor_r83_win32.zip, quiere decir que es la compilación de la revisión 83 de Subversion. por lo que sí tienes el código. Otra cosa es que lo sepas obtener ;) .
si pero tiene que ser con el portatil de linux que en este no tengo svn instalao ni quiero :P
pero porq no os pasais a GitHub? que lo entiendo! jajaja
github mola y todos los demas que generen automaticamente la snapshot en zip
Nueva versión.
Al abrir un fpg lo ordena por código.
Y añadida opcion fpg-ordenar-(codigo, nombre, nombre Archivo)
https://drive.google.com/file/d/0B68H6eAaxbrLbHJDNERWR1hzdlU/edit?usp=sharing
Quote from: DCelso on May 29, 2014, 09:53:56 PM
Nueva versión.
Al abrir un fpg lo ordena por código.
Y añadida opcion fpg-ordenar-(codigo, nombre, nombre Archivo)
https://drive.google.com/file/d/0B68H6eAaxbrLbHJDNERWR1hzdlU/edit?usp=sharing (https://drive.google.com/file/d/0B68H6eAaxbrLbHJDNERWR1hzdlU/edit?usp=sharing)
A eso me refería, voy a descargarlo!
Thanks DCelso;)
error usando windows 7 ultimate 64bits con rutas largas como ejecutar el fpg editor desde mis documentos
al cambiar el idioma a ingles deberia decir fpg editor ... y otras cosas que no cambian de castellano..
Y EN CASTELLANO DEBERIA LLAMARSE FICHEROS FPG para que sea mas detallado ..
si usas delphi deberias convertir rutas largas en cortas antes de ejecutarlo .. por lo menos para el exe que envias...
y sobran demasiados \\\\\\\\\\\\\\
http://delphidabbler.com/tips/6
(http://i.imgbox.com/zNFbkKXY.jpg)
Quote from: l1nk3rn3l on June 17, 2014, 01:51:18 AM
error usando windows 7 ultimate 64bits con rutas largas como ejecutar el fpg editor desde mis documentos
al cambiar el idioma a ingles deberia decir fpg editor ... y otras cosas que no cambian de castellano..
Y EN CASTELLANO DEBERIA LLAMARSE FICHEROS FPG para que sea mas detallado ..
si usas delphi deberias convertir rutas largas en cortas antes de ejecutarlo .. por lo menos para el exe que envias...
y sobran demasiados \\\\\\\\\\\\\\
http://delphidabbler.com/tips/6 (http://delphidabbler.com/tips/6)
(http://i.imgbox.com/zNFbkKXY.jpg)
Ni idea de este error, puede que venga del zlib.exe, ya que no tengo el código de éste. Pronto no se necesitará esta herramienta externa. Pero hasta entonces, es lo que hay :'(
No uso delphi ya, es Lazarus, por lo que ya no hay límite en las rutas ni nombre, debería valer, pero como digopuede que sea culpa del zlib.exe
Por otro lado, los nombres en español de los menús son los originales de DIV, quise respetar todas las opciones del antiguo div y con sus nombres por nostalgia.
Quien haya usado Div/Div2 verá que todo lo que tenía div lo tiene FPG-Edit.
Por cierto, cambíe la versión del r84, he añadido los cambios en los ficheros de traducción que tan amablemente me ha pasado handsource-dyko (http://forum.bennugd.org/index.php?action=profile;u=419) (' EN, NL and DE')
https://drive.google.com/file/d/0B68H6eAaxbrLb0tEU0kyOHdWWTA/edit?usp=sharing
que asco con google la verdad.....
En estos momentos no puedes ver ni descargar este archivo.
Este archivo lo han visto o descargado demasiados usuarios últimamente. Intenta volver a acceder a él más tarde. Si el archivo al que intentas acceder es especialmente grande o se comparte con muchos usuarios, es posible que tardes hasta 24 horas en verlo o en descargarlo. Si transcurrido este tiempo sigues sin poder acceder a él, ponte en contacto con el administrador del dominio.
http://speedy.sh/znYEq/fpg-editor-r84-win32.zip
puedes enviarme el src por privado ? necesito mirar una vez mas el proceso de lectura de las imagenes en el FPG, sólo me falta hacer bien la conversión de los pixeles desde el array segun el tipo de fichero
Nueva versión de los binarios r86 para linux y win32
He corregido un fallo con los fnts y cambios de densidad de color y he añadido al svn los nuevos ficheros de idiomas corregidos por handsource-dyko (http://forum.bennugd.org/index.php?action=profile;u=419)
https://drive.google.com/file/d/0B68H6eAaxbrLTG5sSmw4Zzg4VEE/view?usp=sharing (https://drive.google.com/file/d/0B68H6eAaxbrLclJLclAycmgyaFE/view?usp=sharing)
DCelso, cuando trato de descargar me aparece "Lo sentimos, pero este archivo está infectado. Solo el propietario puede descargar archivos infectados. "
Desde cuando hay versión para Linux? Yo lo usaba con Wine ::)
:( , a ver ahora.
We're sorry. You can't access this item because it is in violation of our Terms of Service. :-\
Es el mismo mensaje que salia poco despues del que copié la primera vez.
no fastidies. dito gdrive, ....
a ver reahora.
https://drive.google.com/file/d/0B68H6eAaxbrLTG5sSmw4Zzg4VEE/view?usp=sharing
Ahora si funciona la descarga. :)
Al tratar de ejecutarlo en Mint 64 me apareció "fpg-editor: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), stripped ". Lo solucioné instalando libqt4pas-dev:i386. Lo pongo acá en caso de que a alguien le pase lo mismo.
El siguiente problema fue que al tratar de compilar me daba el error "file not found ( token error: EOF )". Resulta que era porque el nombre del directorio en el que trabajaba consistía de 2 palabras separadas por un espacio en blanco. Pues eliminé el espacio en blanco y compiló sin problemas.
DCelso, muchas gracias por tu excelente editor y por el port a Linux (bajo Wine no se puede compilar por razones obvias).
DCelso, hice un acceso directo y siempre aparece una ventana de error: Unable to open file "languages/fpg-editor.po". El editor funciona bien, es solo molesto cerrar siempre la dichosa ventana. Desde consola el error que aparece es: p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio No se si tenga relacion. Estoy en Mint 64, por cierto.
En algún momento el compilador dejó de funcionar y daba el error Unable to create file "/tmp/output.tmp". Con borrar el /tmp/output.tmp se solucionó
Esta sugerencia puede ser una tontería, pero al abrir el programa éste debería recordar la ubicación del último archivo que se abrió. No es tan importante, pero bajo Wine si lo hace y es mucho mas cómodo no tener que navegar por directorios cada vez.
Quote from: Kloppix on November 04, 2014, 06:19:44 AM
DCelso, hice un acceso directo y siempre aparece una ventana de error: Unable to open file "languages/fpg-editor.po". El editor funciona bien, es solo molesto cerrar siempre la dichosa ventana. Desde consola el error que aparece es: p11-kit: couldn't load module: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: /usr/lib/i386-linux-gnu/pkcs11/p11-kit-trust.so: no se puede abrir el archivo del objeto compartido: No existe el archivo o el directorio No se si tenga relacion. Estoy en Mint 64, por cierto.
ni idea, y no puedes instalar el pakete p11-kit? en debian existe . https://packages.debian.org/jessie/p11-kit
Quote from: Kloppix link=topic=3212.msg64328#msg64328 date=1415081984En algún momento el compilador dejó de funcionar y daba el errori]Unable to create file "/tmp/output.tmp"[/i]. Con borrar el /tmp/output.tmp se solucionó
que raro, puede ser que tuvieras una instancia abierta del programa o mal cerrada que estuviera bloqueando ese archivo y por eso no te dejaba volver a abrirlo. al borrarlo no te dijo el sistema operativo si estaba bloqueado el archivo?
[quote author=Kloppix link=topic=3212.msg64328#msg64328 date=1415081984Esta sugerencia puede ser una tontería, pero al abrir el programa éste debería recordar la ubicación del último archivo que se abrió. No es tan importante, pero bajo Wine si lo hace y es mucho mas cómodo no tener que navegar por directorios cada vez.
Esta opción se podría programar, actualmente estoy dejando que decida el S.O.(o como esté internamente hecho el componente en lazarus) en windows siempre sevguarda memoria de cual fue el último directorio abierto y juraría que en debian tambien. tendría que verificarlo.
Por lo que veo, estás usando el fpg editor como editor de prgs y compilador de aplicaciones. He de decirte que su punto fuerte no es éste, si no el de crear y editar fpgs y fnts y sus imágenes correspondientes. ¿Te resulta práctico como editor de textos?[/font]
"p11-kit" ya estaba instalado. Luego instalé "p11-kit-modules:i386" ( lo cual desinstaló p11-kit ??? ) y dejó de dar error en consola pero el acceso directo me seguía dando el error Unable to open file "languages/fpg-editor.po"
Finalmente cree un archivo sh ...
#! /bin/bash
cd <Ruta al programa>/fpg-editor_r86M_linux_and_win32
./fpg-editor
... e hice un enlace directo. Ahora lo puedo ejecutar desde el menú sin problemas 8)
Nueva versión v4.0.1 con un simple error detectado en ficheros de 1 bits.
DCelso no podrías corregir el tema de que los archivos del fpg editor tienen unos bytes finales que no son parte la especificación FPG?
Más info aquí:
Re:No puedo pintar en gráfico 1001 (//http://Re:No%20puedo%20pintar%20en%20gr%C3%A1fico%201001)
en cualquier caso genial que sigas manteniendo la herramienta :)
:o , primera noticia que tengo de que dé problemas.
He probado todos los formatos que genera fpgedit, los fpg y los fnt y todos van perfectamente en bennugd actual.
Y en el pixtudio van todos los de 32 bits bien y los de 16 bits parcialmente bien ( porque trantan mal el color transparente)
Supongo que ya no leen ninguno de los dos más allá de la imagen 1000.
Ese gráfico fantasma nunca ha dado problemas antes que yo sepa, es necesario en fpg editor porque guarda en él información relevante.
Pues sí que dio problemas, porque como dije, Bennu y, sobre todo, Fenix, cargaban ese texto extra como gráfico 1001, y me estuvo provocando dolores de cabeza horrendos.
Y sí, estuve probando en Fenix 084, porque el proyecto Montezuma se desarrolló inicialmente como juego para el concurso de videojuegos para GP32 (que al final no se celebró). Lo pasé a Bennu por los múltiples problemas con los NEW_MAP, el retorno de valores, y otros fallos que no recuerdo. Lo que no he encontrado son los ports de Fenix 083b para GP32 y GP2X :o
A raiz de esto, hubo correcciones tanto en las nuevas releases de Bennu como de PixTudio, y por eso no fallan. Pero si te vas a una versión anterior, o necesitas usar Fenix, pues van a dar este tipo de problemas.
Respecto a lo de añadir esos datos extra, ya hablamos en su día del tema :D Lo que no recuerdo es si dimos con una solución, porque no recuerdo ninguna sección del formato FPG para añadir cosas. He visto formatos que sí, que te permitían indicar el tamaño de algunas secciones, y podías incluir información extra al final de las mismas, o al final del fichero porque estaba limitada la zona de lectura, pero no en los FPGs.
A mi me da polemas en Linux...
Quote from: Futu-block on October 24, 2016, 06:32:19 AM
A mi me da polemas en Linux...
¿la versión linux?
¿la version win32 en wine?
porque creo que wine no emula aún binarios x64 y éste último lo es.
ya me has metio el mieo en el cuerpo, lo miro otra vez :D
-----------------------------------------------_-------------------------------
Nope, no me funca, aparece un .exe en el comprimido, al final es pá ná
Como dice drumpi, sí que dio problemas. El hech9 que bennu y pixtudio se cambiasen para ser tolerantes con los fpg creados por fpg edit no quiere decir que fpg edit esté haciendo lo correcto. Yo también me vi obligado a cambiar mi editor FPG para q pudiera soportar los Fpgs de FPG edit. Cualquier persona q quiera hacer un editor FPG y que no tenga en cuenta "lo especial" de los FPGs de FPG edit tenfra los mismos problemas porque basicamente está creando FPGs que están fuera de la especificación. Y las espevificaciones de formato están para facilitar que la gente pueda crear herramientas. Si cada herramienta hace sus propias modificaciones al formato entonces se pierde la razón de ser la especificación y además en este caso la variación ess tan sutil que es difícil darse cuenta de lo que pasa.
Yo no t quiero obligar a nada, pero entiende que somos pocos aquí y que tener un poco más de homogenización no va a hacer daño... Esos bytes extra donde se escribe la versión de FPG edit tenían sentido para los FPGs creados para cdiv, que al fin y al cabo era un "formato de fpg propio", pero no tiene sentido que la herramienta de edición FPG mas usada en la comunidad no haga honor al formato FPG tal cual está especificado.
Tienes Toda la razón del mundo.
Tendré que plantearme otra forma de guardar la información si que se vea afectado el formato.
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.
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
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?
sip pero hay que hacerlo ''especial'' ;)...
hasta que no lo tenga claro, puede que al final no haga falta
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.
Grandiosooo!! :D :D :D
tengo ganas de probar la Tool FPG, por lo que dices es una maravilla!!
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).
;)
Gracias ahora funciona perfecto con el pixtudio... y Bennugd
sera incluido en la proxima beta de pixtudio
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.
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 :)
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 ;)
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. ;)
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.
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 :)
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.
2³²
jijiji puedo hacerlo
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.
Quote from: Futu-block on October 25, 2016, 06:37:31 PM
2³²
jijiji puedo hacerlo
Espero que nadie haya hecho un editor que inicialice un array al código más alto encontrado xD
Quote from: darío on October 25, 2016, 06:45:38 PM
Quote from: Futu-block on October 25, 2016, 06:37:31 PM
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. )
Eso es, asi de simple, poneos de acuerdo y hacer un estandart de fpg...
¡¡Estais escribientrdo la historia!!
y no es broma
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) ;)
É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
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...
Quote from: DCelso on October 26, 2016, 07:20:30 PM
É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...
*bajé
Quote from: DCelso on October 26, 2016, 07:20:30 PM
É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 (https://bitbucket.org/josebagar/pixtudio/src/9f25367611ab1072a60442983dab7ad46375b9aa/modules/mod_map/file_fpg.c?at=bigmap&fileviewer=file-view-default) 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.
// 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;
}
Quote from: DCelso on October 24, 2016, 08:53:19 PM
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).:
(https://fontforge.github.io/assets/img/hero.png)
*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:
(https://k61.kn3.net/B/C/2/E/7/B/21A.png)
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
v4.0.4 disponible.
Quote from: master on October 27, 2016, 11:22:23 PM
Quote from: DCelso on October 24, 2016, 08:53:19 PM
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).:
(https://fontforge.github.io/assets/img/hero.png)
*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:
(https://k61.kn3.net/B/C/2/E/7/B/21A.png)
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?
Quote from: DCelso on October 27, 2016, 11:45:53 PM
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?
Pensaba que quizá bennugd o pixtudio podrían leer mas allá del indice 999, siempre y cuando el archivo contenga menos de 999 imágenes. la utilidad sería poder darle soporte a fuentes UTF u otros alfabetos con mas de 256 caracteres. Hace tiempo tuve que escribir unas lineas de código para poder desplegar japones utilizando 9 archivos FPG, eso permitiría ahorrarnos esas lineas. El verdadero problema con el japones es elegir la codificación correcta, la que yo usé fue Shift JIS:
http://www.rikai.com/library/kanjitables/kanji_codes.sjis.shtml
Pero con una fuente UTF completa utilizaríamos muchos más FPG's.
pues si, en eso no podemos hacer nada, maximo 999 imagenes por fpg y 256 caracteres por fnt.
Quote from: DCelso on September 14, 2012, 11:08:22 AM
...
v 4.0.4.
Modificado el módulo generador de fuentes:
- Mejorado el aspecto visual de la ventana.
- Mejorado el rendimiento a la hora de generar la tipografía.
- Corregido fallo que al generar no mostraba el texto escrito.
- Corregido fallo que no mostraba el caracter de valores por encima de 128.
- Ahora también genera tipografías con tamaño menor a 15.
- Corregido fallo en la superposición de colores entre la sombra y el texto y bordes cuando se usa transparencia.
- Corregido fallo que no guardaba la configuración de alfas y charset.
...
Ostras!! no lo vi la actualizacion!
Debo probarlo.
Tengo una consulta:
Se puede añadir de una carpeta llena de caracteres <numero ascii>.png 32bits
Creo a ver visto que tiene la opcion de "nueva fuente" y parece un FPG Editor... esto me confunde!
con tu herramienta, y como se que el programa usa un charset CP850 o el ISO 8859-1?? como se puede establecer que se trata de una FNT a la hora de guardarla?
Aclaramelo porfa, si con tu herramienta se puede poner PNG de 32 y guardarlo como FNT
---------------
despues de probar de Generar una FNT de 0, queria testear el generador..
encontre algo curioso, desconozco por que es...
Es normal que no existan caracteres de 128 - 161 ??? existe alguna explicacion?? ??? ??? ???
(http://i.imgur.com/lKNIYOI.png)
Quote
Se puede añadir de una carpeta llena de caracteres <numero ascii>.png 32bits
Pues no recuerdo si tenía "importar" antes.
Pero ahora, convierte entre formatos guardando como "*.fpg o *.fnt".
Hay que tener algunas cosas lógicas en cuenta. solo usa los codes del 1 al 256 y si quieres poner los offsets distintos a 0, Tienes que simularlos con puntos de control en el siguiente orden:
cp 0: width offset, height offset
cp 1: horizontal ofseet, vertical offset
Gracias a que los puntos de control se pueden poner con la imagen de fondo esto lo hace ultra cómodo de hacer,
Y al revés igual cuando abres un fnt, verás en los puntos de control de cada imagen los offsets en ese orden.
Quote
Es normal que no existan caracteres de 128 - 161 (http://foro.bennugd.org/Smileys/default/huh.gif) existe alguna explicacion?? (http://foro.bennugd.org/Smileys/default/huh.gif) (http://foro.bennugd.org/Smileys/default/huh.gif) (http://foro.bennugd.org/Smileys/default/huh.gif)
Puede que sea un error.
Tengo que repasar el código.
usa como referencia el antiguo fnt-maker, a ver si hace lo mismo,
Puede que sean caracteres no imprimibles. y por eso no se muestren.
Quote
Aclaramelo porfa, si con tu herramienta se puede poner PNG de 32 y guardarlo como FNT
Eso es heredado de fnt-maker, éste lo hacía en 8 bits y ahora se hace en cualquer densidad de color, desde el generador de fnts, puedes exportar la fuente como .png (con todos los glitches) e importarla siempre y cuando respetes el formato con el que fue exportada.
Directamente desde el editor de fpg no se puede, vamos ni se me ocurrió meter esa opción creo, me la apunto para futura mejora.
Pero antes de mejoras quiero estabilizar actualmente todo lo que hace, así que si me vais reportando bugs, mejor que mejor. :)
Quote from: DCelso on October 30, 2016, 08:15:27 PM
Quote
Se puede añadir de una carpeta llena de caracteres <numero ascii>.png 32bits
Pues no recuerdo si tenía "importar" antes.
Pero ahora, convierte entre formatos guardando como "*.fpg o *.fnt".
Hay que tener algunas cosas lógicas en cuenta. solo usa los codes del 1 al 256 y si quieres poner los offsets distintos a 0, Tienes que simularlos con puntos de control en el siguiente orden:
cp 0: width offset, height offset
cp 1: horizontal ofseet, vertical offset
Gracias a que los puntos de control se pueden poner con la imagen de fondo esto lo hace ultra cómodo de hacer,
Y al revés igual cuando abres un fnt, verás en los puntos de control de cada imagen los offsets en ese orden.
Desconocia que existian puntos de control, eso sirve para calibrar la posicion de impresion del texto, es decir simular lo que hace las fuentes type-true, esa caracteristica que tiene un ancho personalizado o algo asi.
Y si no tienen ningun punto de control, pasa algo?
Segun el editor de FNT(la opcion de Nueva Fnt...) da para "añadir" los PNG pero hay que ir con cuidado, ya que hay que respetar la numeracion de png, que debe cuencidir. Gracias al parametro de numero de grafico, permite añadir masivamente la selecion que se desé.
Si soy consciente que son numeros del 1-255 (imprimibles 32-255), tranqui ;D
Quote from: DCelso on October 30, 2016, 08:15:27 PM
Quote
Es normal que no existan caracteres de 128 - 161 (http://foro.bennugd.org/Smileys/default/huh.gif) existe alguna explicacion?? (http://foro.bennugd.org/Smileys/default/huh.gif) (http://foro.bennugd.org/Smileys/default/huh.gif) (http://foro.bennugd.org/Smileys/default/huh.gif)
Puede que sea un error.
Tengo que repasar el código.
usa como referencia el antiguo fnt-maker, a ver si hace lo mismo,
Puede que sean caracteres no imprimibles. y por eso no se muestren.
Si me resulto extraño... aun asi como pista:
https://es.wikipedia.org/wiki/ISO/IEC_8859
Indica a partir del 160-255 usando esa norma. supongo que es normal, y no sea un error.
Donde puedo encontrar ese antiguo fnt-maker? para probar...
Quote from: DCelso on October 30, 2016, 08:15:27 PM
Quote
Aclaramelo porfa, si con tu herramienta se puede poner PNG de 32 y guardarlo como FNT
Eso es heredado de fnt-maker, éste lo hacía en 8 bits y ahora se hace en cualquer densidad de color, desde el generador de fnts, puedes exportar la fuente como .png (con todos los glitches) e importarla siempre y cuando respetes el formato con el que fue exportada.
Directamente desde el editor de fpg no se puede, vamos ni se me ocurrió meter esa opción creo, me la apunto para futura mejora.
Pero antes de mejoras quiero estabilizar actualmente todo lo que hace, así que si me vais reportando bugs, mejor que mejor. :)
Muy bien! contra mas caracteristicas mejor!
aun que las FNT en div2 se podia abrir como FPG, y lo cargaba, con sus puntos de control y los graficos de 1-255.
Asi que las FNT se puede decir que es como un FPG, pero dedicado a tipografias.
Como haces para indicar si se trata de un charset ISO-8859-1 a otra CP850??
como lo interpreta el FNT_LOAD?? como descubre que se trata de una o otra?
para la hora de hacer WRITE imprima con los caracteres que tocan. ??? ??? ???
Ya lo he explicado un millón de veces, eso no existe así como tal, voy a tener que enseñarte el código bennu de los fnt para que lo entiendas.
Básicamente lo único que debes de saber para que funcione todo bien, es que tanto como el editor con el que hagas tu código fuente (.prg) como tu fnt estén hechos con el mismo charset. una ñ, o un ! o lo que sea no dejan de ser un único número comprendido entre 0 y 255 para bennu, y ese número lo asigna el editor con el que escribas el texto.
Si escribes con edit de msdos usaras cp850, si usas el notepad de windows usarás iso8859, si usas otro mas moderno, podrás elegir cual usar. El resultado final será que tu fichero de texto guardará un número u otro en el código binario de 0 a 255, y ese numerito es el que usará bennu para buscar el texto a mostrar de tu fnt.
El programa ese con el que quereis demostrar como trabaja intermanente bennu o pixtudio es una gilipollez lo único que te dice es en qué charset fue hecho el fnt interno (y creo que es simulado) que usa, si no usas uno propio.
simplemente hace un for de 0 a 255 mostrando los gliths de ese fnt.
Eso no te sirve para nada, solo para saber en que charset poner tu editor para programar códigos que no usen fnts propios.
Nunca se le ha dado tanta importancia como quieres darle a esto, ya que es demasiado transparente. Programas un fnt con un charset, y luego programas tu juego .prg en el mismo charset, y punto pelota fin de cualquier problema.
:-[ :-[ :-[ :-[
esto ha sido un "zas en toda la boca".
Ahora lo acabo de entenderlo!!! soy lenta perdona!
si uso notepad++ podre selecionar el charset ISO8859-1 carga las FNT con ese ASCII extendido.
es decir me guarda el PRG y me genera el DCB en iso8859-1
ya esta, ya no te molesto mas!!
aclarado!! xD
pido disculpas!!
Naada, no problemo, pregunta lo que quieras, para eso estamos..
Perdona si parecí borde, no lo quise ser.
Seguro no me expliqué bien las otras veces.
;)
No le hagas mucho caso, no ha tenido un buen día :D :D :D
He leido en la ayuda de Fenix que los FNX (FNT de 16 bits o superiores) sí que tienen un campo que especifica el charset usado. No me tomeis la palabra porque sé que ese fichero contenía errores. Lo único que indica es el charset usado a modo de información. Por lo general, esa información no se puede obtener (a menos que abras las fuentes como fichero con FOPEN), y te da igual, porque tan pronto escribas un texto con caracteres ascii extendidos (del 128 en adelante, que son la letras acentuadas y demás) vas a ver letras raras, y si no lo hace, terminarás cargando un fichero de texto y será ese el que fallará :D :D
Sigue el consejo de DCelso, y usa el mismo charset en FNT y Bennu ;)
Hasta la salida de ANSI y UTF-8 no se ha estandarizado el sistema de caracteres informático a nivel global. Fenix arrastraba el ser un heredero de DIV, un programa de finales de los 90, y Bennu aun guarda algunas compatibilidades, y los ficheros son una de ellas... así que aun tenemos que lidiar con algún problema de hace 20 años.
Y si creeis que este es un tema pasado de moda, pensadlo dos veces, porque este año me he encontrado con gente que no podía compilar en Bennu porque, sin darse cuenta, habían hecho el programa en UTF-8 con BOM :D
hare caso a DCelso, de guardar el PRG en el charset que sea igual que las FNT que usaria.
hare un PRG que cargue una FNT y imprima un texto.
me interesa el: ISO 8859-1 ASCII extendido.
hare una FNT generado con la tool, con el mismo ISO 8859-1.
y otra una FNT creada con la tool, por graficos PNG(los simbolos e numeracion son del ISO 8859-1).
que cargue las 2 FNT e imprima 2 textos. con caracteres ASCII normal( 32-126) y ASCII extendido(160-255)
Buenas debo reportarte 2 cosas extrañas que he visto:
es para que las corrijas, por fi.
Y decirme como se puede DEScomprimir una FNT a su tamaño original, solo veo la opcion de Comprimir...
Vamos por pasos:
Cosas que estan bien! ;D ;D ;D
Listado de caracteres, a traves de FNT Generator Abrir
Ver: Captura2b
A la hora de ver la FNT a traves del FNT Generator, muestra correctamente el listado ASCII y el simbolo que corresponde.
32 = espacio
33 = !
...
Genialll!!! ;D ;D ;D :D :D :D
Que pasa con los caracteres del 129-159 del ASCII Extendido ISO8859-1/15 ???
Son imprimibles al final?? es un vacio misterioso xDD
Cosas que me parecen raras o erroneas: :(
Ver las FNT por el tipografias -> Abrir...
En la opcion de tipografias-> abrir...:
Al abrir cualquier FNT (puede abrir las Comprimidas y Descomprimidas)
Teoria de la numeracion ASCII: Resulta que los que son los:
32 = espacio
33 = !
...
ok.
Resulta que empiezan por (+1 de lo normal)
Ver: Captura2
Ver: Captura
33 = espacio
34 = !
35...
ME resulta extraño que empieze por el 33 el espacio, es decir a la hora de abrir la FNT cuenta +1.
Curiosamente esto no daña(desconfigura) la numeracion REAL de la FNT al guardar la FNT despues.
O es que existe un grafico numero 1, que lo oculta??
Es normal ese comportamiento? explicamelo, resulta confuso :-\ :-\
Abrir FNT Comprimida, a traves de FNT Generator Abrir
Ver: error2
Pues resulta que no puede abrir una FNT comprimida(fue comprimida con la misma herramientas -> Compresor de FPG Editor V4)
Tambien la FNT se comprimen a la hora de guardar la FNT des del: tipografias -> Abrir...
Arregla eso que pueda abrir una FNT comprimida a traves de FNT Generator Abrir, porfi!
Ademas: explicame como puedo DEScomprimir una FNT(o cualquier FPG,MAP), la herramienta de Compresor carece de boton Descomprimir!!! donde esta?!!! :o :o :o
Lo unico que se me ocurre, es usar fnt_save, para guardarlo en tamaño original(descomprimido) ::)
-Sugerencia: a la hora de guardar FNT/FPG en los 2 metodos: NO pregunta si deseas Comprimirlo o modo descomprimido.
Eso seria una caracteristica a añadir a la hora de guardar.
-Estaria bien un texto en la barra de estado, si el FNT/FPG esta comprimido/descomprimido(una vez abierto)
:o buen feedback si señora. ;D , bien
lo de que no abra comprimidos es un bug, gracias por el reporte, lo corregiré en cuanto pueda
Lo del +1 en todos los caracteres, sí, es la forma que se me ocurrió en un momento para poder usar los fnt como fpgs, (recuerda que no se puede usar el "code" 0, limitación de DIV, heredada a fenix)
Viendolo así. Es verdad que resulta extraño todo corrido un valor , da margen a error. Me aputo eso para hacer algo para mostrar correctamente los valores sin el +1. Ahora mismo si editas verás correctamente el número en el campo name.
los caracteres del 129-159 del ASCII Extendido ISO8859-1/15. También me lo apunto, llevas tres de tres :-X .
Lo de descomprimir, es muy facil. ¿Has probado justo en el editor fpg a irte a herramientas y dar a configuracion y desactivar la opción "activar compresion"? Quizas haciendo eso se desactive la compresión. No se. ;)
las sugerencias, creo que conociendo esa opción de configuración la primera sobra, y la segunda, evidentemente igual. Un fnt o fpg (o cualquier recurso abierto) ya está descomprimido en memoria, es cosa del usuario si al guardar quiere comprimirlo o no.
Graciaas!
Desconocía que existiera un menú de opciones en el FPG Editor, para desactivar que no comprimiera los FPG/FNT. Le echare un ojo! seguro que encuentro mas opciones interesantes!
LA verdad que cualquier usuario que empiece con el editor, desconoce si el FPG,FNT se guarda en modo comprimido o no.
Pero si el usuario encuentra que hay un Compresor de herramienta.
Es lo unico a simple vista que da un usuario al usar la herramienta tan genial!!
:D
en el FNT Generator no me acuerdo si al guardar, los guarda comprimido las FNT?
Tengo una pregunta, y si no existe seria una sugerencia a añadir:
La herramienta tiene entrada de argumentos?
del royo:
fpg-editor.exe mi_proyecto/graficos.fpg (Abriria el FPG Editor)
fpg-editor.exe mi_proyecto/texto.fnt (Abriria el FNT Generator con la FNT ya abierta)
fpg-editor.exe mi_proyecto/titulo.fnt -F (Abriria el FPG Editor en modo FNT)
Me seria util de forma rapida, ademas de asociar ficheros en windows.
----------------------
Probando, encontre la opcion de Activar compresion :D
Debo reportarte 1 bug de la interfaz en FPG Editor:
Cuando iniciamos el FPG Editor... al dar el boton de lista detallada, me aparece hiper estrechos las columnas!!
ver: Captura.png
Deberia auto ajustarse automaticamente al ancho del texto que descrive la columna, esto afecta ambas listas: de ficheros y del mismo FPG tambien.
Una Sugerencia: me gustaria que se guardara la posicion X(Ancho) de cada columna en las 2 listas, es decir:
Nombre = 64px, Tamaño=32px...
esto que lo guardara en el .ini
Y una sugerencia para un boton: Mostrar/Ocultar panel superior:
Me gustaria que se conservara la opcion si se encuentra mostrado o ocultado, que lo guarde en el .ini
asi no tener que abrirla de nuevo.
Ultima sugerencia, si pudiera ser:
Recordar la ruta de la carpeta abierta en el explorador de ficheros(panel superior), es decir, que al iniciar el FPG Editor abriera la ultima carpeta usada, cargando el directorio obviamente.
Esta opcion seria desactivable en menu de opciones, para que el usuario dese que se inicie con la ruta de inicio:(Letra de unidad) o prefiera recordar la ultima carpeta abierta.
Ok, gracias por el reporte.
Todo eso estaba previsto.
La verdad es que el panel superior no lo uso, cuando está cerrado si le das a añadir aparece el selector de ficheros de windows que hace lo mismo (selección múltiple incluída), y ese sí guarda la ruta anterior.
Por eso por defecto viene desactivado al ejecutarse.
nueva versión subida.
v4.0.7
Quote from: DCelso on September 14, 2012, 11:08:22 AM
...
v 4.0.7.
- Corregidos varios errores en el generador de fuentes.
- Corregido error al convertir a 8 bits.
- Apertura de nuevos formatos fpg.
- Añadida opción para usar el nombre del archivo como código de imagen.
...
Huo recién salido del horno!
Lo probare las novedades! gracias!
Por cierto, he comprobado que si seleccionas la vista de detalles, le das al botón nombre, y vuelves a poner la vista iconos, estos se ordenan bien.
O sea, que la función de ordenar funciona, pero no se llama de forma automática :D
4.0.8 disponible ya.
Bonito avatar, je je
si, ma costao un huevo y parte del otro hacerlo. Uff, que cansado estoy.
(comentario offtopic: que buenos avatares tienen DCelso y Futu-Block!)
y los de la rata y el mio no salen del horno ?
:D . Sólo los suyos fueron los que muy particularmente pudieron contar su saga... ;)
Quote from: DCelso on November 04, 2016, 11:45:11 AM
:D . Sólo los suyos fueron los que muy particularmente pudieron contar su saga... ;)
no entendi
Pues que hay que ser enchufao pa conseguir uno. :'(
Pej. A mi ma costao hacer unos cuantos juegos y unas cuantas actualizaciones de fpg-editor pa que me lo hagan.
Así que aplicaros el cuento y haced muchas cosas para el mundillo ;)
Quote from: DCelso on November 04, 2016, 11:58:22 AM
Pej. A mi ma costao hacer unos cuantos juegos y unas cuantas actualizaciones de fpg-editor pa que me lo hagan.
Así que aplicaros el cuento y haced muchas cosas para el mundillo ;)
algun dia lograre hacer algo interesante para el mundillo... y tendre mi avatar nuevo! :D
4.0.10 disponible.
Hola buenas.
tengo creadas los puntos de control en ficheros de texto ascii.
108.cpt
CTRL-PTS
1
28 33
Por cierto genial, la opcion de Exportar!! genialisimo!!
Pues como deberia leer el cpt, en BennuGD/pixtudio
deberia usar fopen, fgets...
pero me encuentro que hay 2 numeros en la misma liniea: 28 33
con un espacio entre las 2.
Podrias montarme una funcion programado en BennuGD para cargar ese punto de control?
y asignarlo al png cargado.
bueno a mi me interesa tenerlo en 2 variables x,y claro.
necesito un poco de ayuda, para cargar este fichero en bennuGD
facil, facil, lo hice a posta para que lo fuera.
1- haces fopen y abres archivo
2 -haces fgets y lee la primera linea y miras que sea exactametne "CTRL-PTS" si no lo es, sales. no es un fichero de puntos.
3 - otro fgets para leer la segunda linea. guardas en una variable con atoi, y ya tienes el número de punto a leer
4 - haces un for hasta ese número
5 . haces otro fgests, y al resultado le aplicas split (" " ), en el array que devuelve split tendrás en la primera posicion el valor x, y en la segunda el valor y del punto de contro.
6- guardas el punto de control en el mapa que creaste con load_png.
7- siguiente iteración del bucle ... etc..
8- cierras el fichero con fclose.
slpit!!
cpoints[1];
string cadena_cp;
split(" ",cadena_cp,&cpoints,2);
Algo asi??
Sí.
me puse en un rato y lo hice, aqui tienes
import "mod_video"
import "mod_key"
import "mod_map"
import "mod_proc"
import "mod_grproc"
import "mod_text"
import "mod_file"
import "mod_string"
import "mod_regex"
import "mod_time"
import "mod_rand"
import "mod_say"
function load_png_cpt(string filename)
begin
graph = load_png(filename);
load_cpt(0,graph, substr (filename,0,Len(filename)-4)+".cpt");
return graph;
end
function load_cpt(file, graph, string filename)
private
int handle;
int longitud;
int i;
string line;
string ctPoint[2];
begin
if (not fexists (filename))
return 0;
end
handle=fopen(filename,O_READ);
line = fgets (handle);
if (line <> "CTRL-PTS")
fclose(handle);
return 0;
end
line = fgets (handle);
longitud = atoi(line);
for (i = 0; i< longitud; i++)
line = fgets (handle);
split(" ", line, &ctPoint,2);
point_set (file, graph, i, atoi(ctPoint[0]), atoi(ctPoint[1]));
end
fclose(handle);
return 1;
end
begin
x =200;
y =200;
graph = load_png_cpt("002.png");
while (!key(_esc))
frame;
end
end
Quote from: DCelso on November 06, 2016, 01:30:13 AM
me puse en un rato y lo hice, aqui tienes
import "mod_video"
import "mod_key"
import "mod_map"
import "mod_proc"
import "mod_grproc"
import "mod_text"
import "mod_file"
import "mod_string"
import "mod_regex"
import "mod_time"
import "mod_rand"
import "mod_say"
function load_png_cpt(string filename)
begin
graph = load_png(filename);
load_cpt(0,graph, substr (filename,0,Len(filename)-4)+".cpt");
return graph;
end
function load_cpt(file, graph, string filename)
private
int handle;
int longitud;
int i;
string line;
string ctPoint[2];
begin
if (not fexists (filename))
return 0;
end
handle=fopen(filename,O_READ);
line = fgets (handle);
if (line <> "CTRL-PTS")
fclose(handle);
return 0;
end
line = fgets (handle);
longitud = atoi(line);
for (i = 0; i< longitud; i++)
line = fgets (handle);
split(" ", line, &ctPoint,2);
point_set (file, graph, i, atoi(ctPoint[0]), atoi(ctPoint[1]));
end
fclose(handle);
return 1;
end
begin
x =200;
y =200;
graph = load_png_cpt("002.png");
while (!key(_esc))
frame;
end
end
Eres un amor! ::) ;D
Esto nos ayudara para toda la comunidad, quien use tus archivos de puntos de control. con tu Tool!!
Genialisimo!!!
Alguna novedad, para una actualizacion? o por ahora hay que esperar, se considera estable y con las herramientas necesarias.
solo curioseo ::)
No, ninguna novedad. :'(
Ahora mismo tengo parado el avance.
Estable es, yo lo uso para mis proyectos bennu. ¿Vistes algún error o mejora?
Reconozco que es una herramienta esencial, siempre son bienvenidas las novedades.
;)
Yo tengo un ordenador con Windows 10 y me dice que no se puede ejecutar el FPG EDITOR. Por favor, create un FPG EDITOR que funcione en Windows 10. Tengo BennuGD, pero cómo hago para cargar gráficos si no puedo usar el FPG EDITOR???.
Por favor, solución.
Nicolás
tienes dos ejecutables en el zip, uno en 32 bits y otro en 64.
Si tienes windows 10 de 32 bits el binario de 64 bits no te irá.
Si tienes windows 10 de 64 bits, ambos deberían irte.
Por favor comprueba esto que te digo a ver si es el problema.
De todas formas, como alternativas tienes fpgedit de Dario, y fpg editor hecho en código bennu, de PRG.
también hay unos scripts molones en "pixtudio-pm de pixel" que pasan un directorio de pngs a un fpg.
Alternativas hay muchas ;).
y bien?
Hola chic@s. Estoy desarrollando un IDE orientado a niños para introducirles en la programacion y queria saber si habia documentacion de los ficheros fpg, map, y en general de los archivos que se pueden cargar en bennugd para conocer sus formatos y construir algunos editores y lectores integrados. ¿Me podéis ayudar?
Hola, eso sería genial, tener documentación actualizada de los ficheros fpg y map.
La última que usé fue de fenix venía como montar los fpgs de 8 bits de div y fpgs de 16 bits de fenix.
Es que creo que los formatos no han cambiado desde entonces. Lo que ya no sé es dónde está la información más actualizada de los mismos porque hace ya tiempo que no toco ese tema ^^U
FNT:
http://wiki.bennugd.org/index.php?title=Fnt_format
MAP:
http://wiki.bennugd.org/index.php?title=MAP_Format_Specification
el de FPG, curisoamente no está :O.
Y como ya no se puede editar...
Necesitamos que alguien arregle la wiki ya, nen.
Josebas, Splinter, Pixel ...