Hola a todos:
Voy a intentar focalizar mi energía un poco hacia bennu. Mientras llega el dia en que pueda sacar unas cosillas, y como tengo que programar algo un poco tedioso y repetitivo, para "relajarme", voy a tratar de hacer un conversor de fuentes, que me está haciendo falta.
Ya he reunido la documentación necesaria. La idea es que:
-Cargue FNT de cualquier profundidad de color.
-Guarde en FNT de 1, 16 y 32 bits (los de 8 bits van a ser más complicados, por el tema de optimizar paletas, que aun no se cómo hacerlo, quizás más adelante).
-Importar desde un FPG (el número de cada mapa indicaría el número como caracter)
-Exportar a FPG.
-Ver la posibilidad de generar alguna fuente, usando la ttf.dll o similares.
Bueno, la idea principal era hacerla por linea de comandos, por si alguien quería hacerse un script para usarlo, pero Splinter prefería hacerlo mediante IDE.
Esto me puede plantear un pequeño problema, pues mi experiencia con anteriores IDEs por código no fue tan satisfactoria (y porque mi capacidad de diseño es baja). Pero se intentará.
Así que el hilo estará abierto para cualquier sugerencia.
Tambien para plantearos mis dudas, empezando por si preferís una interfaz clásica, algo un poco distinto o algo totalmente surrealista (warning: posible Drumpi-locura inside ;D)
Y otra cosa ¿tendríais inconveniente en que esté sólo en inglés o solo en español? más que nada porque me interesa sacar algo funcional lo más pronto posible, nunca sé a ciencia cierta si voy a terminar algo o no ;D
Un saludo.
Drumpi, igual te alegra saber que eso que dices está medio hecho :P
Si te interesa envíame un mensaje.
Qué grande!!
Si puede ser con Ide, pues bien, pero se puede hacer una versión previa completamente funcional en línea de comandos, y ya vendrá lo otro después, no? Pienso que la línea de comandos es importante tenerla presente siempre...
Venga, gracias a todos!!
mientras sea funcional y simple, da igual que sea por linea de comandos o ide... la preferencia es ide...
podes usar las funciones de ide que hice yo para bennu, y lo haces directamente en bennu...
como gustes...
1 karma por la iniciativa! :D
si usas bennu puedes usar la pango para crear las fuentes de fuentes del sistema. no se si ya salió a la vista, pero hay un instalador que ha hecho josebita para que funcione en windows de forma automática, con lo que ya no habrá problemas
y usar la gui para crear los botones. tenía pensado hacer algo para el fpg editor sin embargo no he logrado comprender cómo funcionan las funciones para crear fuentes :) , de cualquier forma me alegro que hayas tomado tu la iniciativa, en verdad se necesita un editor de fuentes...
bueno, nos vemos, saludos y un karma para tí :)
Bien, de momento voy a empezar con las funciones de guardado y carga, y para ir testeando usaré consola de comandos.
Después me centraré en un IDE, aun tengo los códigos que hizo Splinter, así que si no ha habido cambios en los últimos 4 meses podré ir mirando de hacer algo, aunque andaba visualizando una interfaz con botones sueltos volando por el espacio... ;D
La pango la dejaremos para más adelante, primero quiero aprender a manejar el formato FPG, y la ttf es tan sencilla de usar que me podré olvidar del fread un rato.
Por cierto, por curiosidad: en Fenix me di cuenta que, si quería trabajar con los mapas, sólo por cargarlos en memoria ya había que inicializar el sistema gráfico, al menos para ponerlo en 16bits. No es un problema, en absoluto, pero me llamó la atencion cuando intenté hacer un programa puramente por linea de comandos: tuve que abrir si o si una ventana (la aproveché para mostrar mensajes y demás).
Hola de nuevo:
Tengo que pediros disculpas, porque en realidad no me he puesto a trabajar en serio en esto hasta ayer (es lo que tiene mi pila: los cinco primeros proyectos se ejecutan en orden "segun me apetezca programarlos" :D)
Pero bueno, lo he cogido con ganas y de momento ya tengo la carga de fuentes a medias, aun quedan algunas complicaciones por superar y crear los mapas con las imágenes, pero puedo ver los primeros datos de TODOS los formatos de FNT, incluso de aquellos que no puede el FNTEdit: los ficheros comprimidos.
Se me están planteando serios problemas intentando entender el formato nuevo de FNT, porque no existe documentacion alguna al respecto y lo estoy haciendo descifrando el código de Fenix 092a (por suerte, mi C no está tan oxidado como pensaba) y los valores de fuentes ya existentes.
Un par de cuestiones:
¿Existe alguna forma de averiguar si algun fichero está comprimido con la zlib sin tener que recurrir al "prueba y error"?
Aunque lo voy a sacar este fin de semana sin internet (pero por si acaso), hay una serie de campos nuevos en las cabeceras de cada fuente del formato fnx que no entiendo ¿para qué son?
En cuanto tenga disponible algo que sea ejecutable, aunque sea por linea de comandos, lo pondré aqui.
Mientras tanto, si alguien quiere ocuparse de diseñar la interfaz (aunque sea en papel, pero si puede hacer los botones y demás, mejor) pues le estaré muy agradecido, porque yo podría acabar haciendo cualquier chapuza ^^U
si usas las funciones de archivos con el flag de zlib no te interesa si estan comprimidos o no... la libreria internamente hace el chequeo...
tambien tenes los fuentes en C de bennu... pero yo creo que no es necesario ver los fuentes...
Ah, vale. Gracias por la info.
Pero si abro un fichero en modo O_ZREAD se supone que no puedo usar el comando FSEEK para ir a una parte anterior del fichero, por lo que si sería interesante poder distinguirlos. pero vamos, que el "try & error" funciona de lujo.
Tambien se lo de los fuentes de Bennu, pero es que los de Fenix son los que tenía más a mano ^^U
Y sin ver los fuentes, ya me contarás cómo averiguo el formato de los fnt nuevos. En el wiki se habla del formato FNT de DIV que empieza con el campo magic "fnt\x1a\x0d\x0a\x00" (juer, me lo se de memoria) y tiene un octavo byte que indica la version, que siempre es cero.
Sin embargo, las fuentes de Fenix empiezan con "fnx\x1a\x0d\x0a\x00" y el octavo byte no es la version, sino la profundidad de color, y eso no se dice en el wiki.
Amen de que luego cada letra se supone que tiene 4 ints que especifican ancho, alto, desplazamiento vertical (respecto a la linea de escritura) y desplazamiento de los datos (el número del byte donde empieza el mapa de la letra), y en cambio, el "fnx" dispone de ocho campos, entre ellos el desplazamiento horizontal de la letra y ¿desplazamiento vertical de los datos?
FUENTE (http://fenixworld.se32.com/fenixwiki/index.php?title=Especificaci%C3%B3n_FNT) (no encontrado en el bennu wiki)
los modos son o_zwrite y o_zread... o_zread detecta si esta comprimido o no, y usa la funcion adecuada para recuperar los mismos...
y con respecto a los fonts, tenes que tener en claro que no es serializado, sino que en ningun caso, en la misma unidad de profundidad (byte/word/dword, segun el modo) vas a tener pixels/bits de distinta fila.
para 1 a 8 pixels de profundidad = 1 byte
para 16 = 2 bytes
para 32 = 4 bytes
los bits sobrantes, para el caso de 1bit no se usan... no se tienen en cuenta...
podes chequear cualquier formato grafico, sonido, etc... que no sea serializado, para entender un poco esto...
Quote from: Drumpi on March 06, 2009, 01:38:27 PM
Ah, vale. Gracias por la info.
Pero si abro un fichero en modo O_ZREAD se supone que no puedo usar el comando FSEEK para ir a una parte anterior del fichero, por lo que si sería interesante poder distinguirlos. pero vamos, que el "try & error" funciona de lujo.
Tambien se lo de los fuentes de Bennu, pero es que los de Fenix son los que tenía más a mano ^^U
Y sin ver los fuentes, ya me contarás cómo averiguo el formato de los fnt nuevos. En el wiki se habla del formato FNT de DIV que empieza con el campo magic "fnt\x1a\x0d\x0a\x00" (juer, me lo se de memoria) y tiene un octavo byte que indica la version, que siempre es cero.
Sin embargo, las fuentes de Fenix empiezan con "fnx\x1a\x0d\x0a\x00" y el octavo byte no es la version, sino la profundidad de color, y eso no se dice en el wiki.
Amen de que luego cada letra se supone que tiene 4 ints que especifican ancho, alto, desplazamiento vertical (respecto a la linea de escritura) y desplazamiento de los datos (el número del byte donde empieza el mapa de la letra), y en cambio, el "fnx" dispone de ocho campos, entre ellos el desplazamiento horizontal de la letra y ¿desplazamiento vertical de los datos?
FUENTE (http://fenixworld.se32.com/fenixwiki/index.php?title=Especificaci%C3%B3n_FNT) (no encontrado en el bennu wiki)
bueno, el fseek si funciona, lo que no podes hacer es escribir en esa posicion... eso no lo soporta la zlib... te dara error...
exacto, el metodo de chequeo y error funciona...
bueno, los headers y los magics si los necesitas, pero los fuentes no son realmente necesarios... pense que ya tenias las estructuras...
los fonts en bennu/fenix, sea la resolucion que sea, empiezan con 'fnx'...
EDIT: Es cierto, div y fenix son diferentes, no solo la cabecera...
despues de leer la paleta (solo en el caso 8bits), viene esta data... luego lo demas creo que ya es simple...
div:
struct
{
int width ;
int height ;
int yoffset ;
int fileoffset ;
}
oldchardata[256];
fenix/bennu:
struct
{
int width;
int height;
int xadvance;
int yadvance;
int xoffset;
int yoffset;
int fileoffset ;
}
chardata[256] ;
Si, eso ya lo había visto este fin de semana. Despues de un duro combate a brazo partido (y un fallo tontísimo por mi parte :D) conseguí descifrar el contenido, aunque parece que hay algo de información redundante, pues (si no lo confundo con xoffset e yoffset) xadvance e yadvance indican el ancho y alto respectivos, sumándole los desplazamientos de posición.
Una feature que desconocía y que podría dar mucho de si en juegos estilo cartoon.
La buena noticia es que ya he conseguido que mi programa lea un fichero de fuentes: comprimidas, sin comprimir, con letras desordenadas (por probar, porque no hay ninguna fuente así) y profundidades de 8, 16 y 32 bits (las de 1 bit las he dejado un poco aparcadas porque no me aclaraba en el método para crear mapas de 1bit). Obviamente sólo he podido probar 8 y 16 bits (formato viejo y otra generada por save_fnt), pero todo se andará.
Hay muchas cosas que voy a tener que pensarlas de nuevo, pues me han surgido más detalles que desconocía (como la existencia de dos codificaciones de caracteres) que me obligan a añadirle más opciones de conversion, pero eso no es problema: actualmente guardo cada caracter como un mapa en un array de 256 posiciones, y alterar su posición, color, forma y demás es sencillo, de hecho, se me ha encendido una bombillita respecto a otro uso muy curioso que se le podrían dar a las fuentes.
A ver si en los próximos días puedo decir ya que se pueden guardar las fuentes y cambiarles algun detalle. Al final, con la tontería, acabaré creando una librería de fuentes y todo XDDD
PD: dos cuestiones.
1- ¿El LSB de un byte es el pixel (0,0) de un mapa de 1bit, o lo es el MSB?
2- ¿Map_buffer accede al primer byte con información de color del mapa o al primer campo de datos del mapa en memoria?
3- (Esto es por otro código) Me he fijado que de la version 083b a la 092a desapareció el campo flags de la estructura "_bitmap" (o del tipo GRAPH) ¿Se suprimió o se cambió? Quiero portar una librería pero como usa dicho campo no me deja, y los fuentes de la 083b los tengo perdidos.
Muchas gracias por tu paciencia y tu sabiduría, apreciado maestro ;)
offset, indican desplazamiento donde ponerlo a partir de las coodenadas X e Y
advance, indican el avance que sumar a "x" e "y" para posicionar el proximo caracter.
no tienen relacion real con el ancho y el alto.
1) bit 7 es primer pixel, bit 6 es 2do... pero podes usar las funciones put_pixel...
2) map_buffer = datos
3) no recuerdo, pero que dice exactamente el codigo que usa flags...
bit 7... eso es un poco ambiguo ¿no? :D supongo que te refieres al "Most Significant Bit".
Bien, eso está implementado, sólo falta hacer lo propio en el salvado de la fuente. Añado las opciones de conversion por parámetros, un par de funciones de conversion para los mapas y ya podré sacar una version primitiva para buscar fallos.
Y si todo va bien, tendré que decidir si empezar con la interfaz o con la importacion de FPGs
Respecto al código, pues no lo he analizado lo que debiera: trate de compilarlo y me dio el error de que el campo flags no existe en una variable de tipo GRAPH, pero se usa en diversos sitios de la VSE08 (http://inthewater.se32.com/dlls/vse08.rar)
si, el "bit mas significativo", pero por las dudas, queria evitar luego tener que responder o aclarar a que me referia con "bit mas significativo"... por el contrario, decir "bit7" (128, 0x80, 080h, 10000000b) despeja toda duda/ambiguedad...
vos no estas usando la funcion save_fnt? creaste una propia?
Sep, ya me conoces, me gusta crearme mis propias funciones, ya que así tengo control total sobre lo que hago. Por ejemplo, save_fnt sólo guarda en formato "fnx" de 16 bits con compresión (al menos, en Fenix), que no son compatibles con el viejo FNTEdit, gracias a esto, voy a poder guardar fuentes en formatos "fnt" y "fnx", de cualquier profundidad de color (independientemente del modo gráfico), con/sin compresión, etc...
Faltaría poco para poder crear un módulo en C, pero aun hay algunas funciones y variables internas de Fenix que no conozco, amen de unas cuantas operaciones tipo C que no entiendo, que usais para mejorar el rendimiento. En cuanto sepa, te hago esta funcion y monto un start_tscroll "copiando" código del scroll normal :D
Por cierto, soy electrónico: para mí es menos ambiguo hablar del bit más o menos significativo, porque el "bit 7" depende del orden en que se lea, pero el menos significativo es el que "menos valor representa". Siempre es bueno saber otras formas de decirlo.
Nuevo avance: funciones de carga y salvado terminadas, pero están sin probar. Estoy con las funciones de conversion de mapas (que no hay ninguna). Va a ser un poco más complejo de lo que pensé al principio, porque get_rgb creo que es dependiente del modo gráfico, y no es lo mismo un 70 de un map_get_pixel de 8, 16 o 32 bits.
Después me pasaré a la exportación en FPG, para comprobar si los resultados son satisfactorios.
pero eso es ridiculo, es no confiar en el lenguaje, es lo mismo que yo use C y me ponga a crear las librerias de C porque no confio en C... no tiene sentido...
para que queres guardar fonts para el fntedit? "save_fnt solo guarda...", pero yo podria decir que "fntedit solo soporta...".
el bit mas significativo, independientemente de donde se encuentre fisicamente, es el bit 7...
repito, no veo mucho sentido en perder el tiempo reinventando la rueda... deberiamos mirar hacia el futuro, no hacia atras... pero bueno...
por otro lado, en que porcentaje ya va el proyecto? hay algo para testear?
Hombre, no te lo tomes a mal, tengo mis razones para hacerlo así:
1- No dependo del modo gráfico, para empezar. No me parece apropiado tener que hacer un set_mode cada vez que quiera convertir una fuente a una profundidad de color... por no hablar de las incompatibilidades de tener en memoria maps de 16 bits y tener que cambiar a 8 para guardar una fuente para usar en DIV.
2- Las funciones de salvado de fuentes, salvo que se hayan retocado mucho (que me parece a mi que no), son muy limitadas. Sí, fntedit solo soporta fuentes DIV-like (lo he comprobado), y es por eso por lo que me he lanzado a hacer esta utilidad, porque necesitaba una fuente que no cambiase de color con la paleta. Y por una razon similar no puedo usar las funciones nativas de Bennu: un editor de algo tiene que ser tan versatil como se pueda. Es como coger el editor de video del XP: puede admitir 30000 formatos de entrada, añadir 70000 efectos y todo eso, pero si despues sólo puedo sacarlo en wmv con su correspondiente pérdida de calidad, tamaño y compatibilidad, pues es mejor usar otro ¿no?
3- Estoy intentando aprender programación en general. Aunque uso Fenix/Bennu, tambien quiero migrar a C por cuestiones profesionales (en un futuro). Obviamente, en C se usan librerías para simplificar la vida, pero siempre es mejor saber hacerte tus librerías y usar otras, que saber manejar unas librerías y luego depender sólo de ti ¿no? :D
No se, es mi manera de verlo. Este sólo es otro pasito hacia mi destino de "maestro de los ficheros" de nivel 78 :D
Bueno, yendo al grano, os traigo una versión que acabé justo ayer justo antes de cenar. No está probado, salvo que he conseguido crear fuentes de 16 bits, con y sin compresión, a partir de una fuente de FNTEdit, luego volver a convertirla en una fuente estilo DIV que cargó FNTEdit (pero no se si funcionó). Las fuentes de 1bit no funcionan bien: las admiraciones y los puntos salen bien, pero las letras se convierten en lineas verticales discontinuas, tengo que investigarlo.
De momento, está hecho con una wip11 para windows que tenía por ahi (acabo de coger la última versión hace un momento) y solo funciona por la linea de comandos, con un parámetro como mínimo: para leer la ayuda, usad el parámetro "-h" en minúsculas (fntconv -h).
Subo tambien las fuentes, porque hay algunas funciones que a lo mejor interesan a la gente, por ejemplo, conversiones de color entre mapas, o funciones para guardar FPGs y MAP que hice para Fenix, a las que tengo que añadir los cambios para Bennu (tengo especificaciones para "fpg" (8bits) y "f16" (pero solo 16, no parece que este formato aceptase 1 bit previamente, y no se cómo es el de 32, probablemente aquí si que use las funciones de Bennu, pero voy a ocupar el doble de memoria creando un fpg))
Cualquier sugerencia, crítica o jamón será bien recibida.
FNTConv (ejecutable) (http://www.fenixworld.com/e107_plugins//depot/files/fw75.fntconv.rar)
en bennu no hace falta cambiar de modo de video para crear o usar un mapa de otra profundidad...
no coincido, pensar en ponerme a hacer las libs basicas de C por decir que no tengo el control, entonces seria mejor que me ponga a trabajar en asm... a mi me parece ridiculo...
dependerias solo de mi si esto fuera un proyecto cerrado, pero es un proyecto abierto opensource...
pero bueno, no todo el mundo tiene la misma forma de ver las cosas...
gracias, vamos a probarlo...
karma up.
Mapas no, fpgs y fuentes si.
Y no es cuestion de control, sino de limitación en este caso. Pero bueno, ese no es el tema ;)
fpg tampoco, la profundidad final es la profundidad del primer mapa encontrado dentro de la lib en memoria, y logicamente, todos los mapas tiene que tener la misma profundidad...
lo mismo para los fonts...
se pueden trabajar perfectamente, no dependen del set_mode, salvo las operaciones de RGB dependientes de la paleta del sistema, pero no las RGB que no lo son, de todas formas las RGB se pueden evitar...
pero si estas trabajando con la wip11, puede que algunas cosas no te funcionen como deberian...
O sea: yo creo un fpg nuevo en memoria, y al asignarle un gráfico, este define los bpp del fpg. Y lo mismo con las fuentes. Pues eso es lo que yo no sabia :(
Pero si que estoy teniendo problemas, sobre todo con set_colors y get_colors, que me salta error en ejecución (ventanita alarmista con windos queriendo llamar a casa).
Pero bueno, eso ya da casi igual, pues las funciones de carga y salvado, tanto de FNT como de FPG están casi terminadas, tengo que probar la carga de fpgs porque al crear una fuente a partir de estos no se ve nada (aunque claro, no era un fpg de fuentes :D).
Por cierto, he corregido algunos fallos respecto al guardado de fuentes, pues si el último caracter está vacío, se da un mensaje de error (aun asi, la fuente se genera). Y algun otro que no recuerdo. Pero como hoy me toca volver a casa, no he podido guardar los cambios en la SD, así que subiré los fuentes en otra ocasion ^^U
Superado el escollo de los FPG, podría decirse que llevo un 50% del programa hecho. El otro 50% es el entorno interactivo, y con eso voy a tardar muchiiiiiisimo tiempo (gráficos, siempre son gráficos).
los set y get colors, proba con la r28... creo que habia un bug en determinadas circunstancias
Bueno, un fin de semana de locos que se termina. No he podido hacer casi nada, pero lo prometido es deuda, así que antes de salir de vaje a tierras de estudio, os subo los nuevos fuentes.
No tengo lista de cambios, pero está arreglado el problema que daba con los fuentes sin el último caracter, y teóricamente funciona la importación de FPGs, pero lo he probado poco y no me ha funcionado con un FPG normal (es decir, de otro proyecto que tenia por ahi). Sois libres de usar partes de código si los necesitais, buscar fallos y dar sugerencias, pues en cuanto funcione la importación y exportación de FPGs, empezará el baile de gráficos (diseño del ide).
muchas gracias
Un proyecto muy interesante, bajando la ultima versión. karma up para ti!
Hola a todos:
Bueno, como he dicho en varios hilos, he estado mirando por encima este programa, aprovechando que se ha puesto de moda el tratar con fuentes de 1 bit :D
He conseguido que funcione la conversión de FNT DIV-style a 1 bit, y creo que va bien a 16 bits. No he hecho pruebas exaustivas, así que, aunque suene mal, no garantizo un correcto funcionamiento (salvo lo dicho: 8->1 bits).
Podeis mirar el código si quereis, aunque os adelanto que hay muchísimas funciones a bajo nivel, tanto que no le afectan posibles bugs o cambios del intérprete (los ficheros se generan dato a dato, y la información se guarda en memoria como gráficos independientes, y se analizan pixel a pixel). De haber usado funciones de Bennu, lo mismo el código ocuparía la mitad :D :D :D
Otra cosa, este es de mis primeros códigos en Bennu, por lo que puede que esté un poco desorganizado.
Funciona mediante comandos, no hay interfaz gráfica, así que para hacer la conversión de 8 a 1 bit, un ejemplo sería:
bgdi fntconv -nc -1 fuente.fnt fuente_1bit.fnt
Para obtener ayuda, usar -h como único parámetro.
Quote from: Drumpi on December 15, 2010, 08:32:49 PM
Hola a todos:
Bueno, como he dicho en varios hilos, he estado mirando por encima este programa, aprovechando que se ha puesto de moda el tratar con fuentes de 1 bit :D
He conseguido que funcione la conversión de FNT DIV-style a 1 bit, y creo que va bien a 16 bits. No he hecho pruebas exaustivas, así que, aunque suene mal, no garantizo un correcto funcionamiento (salvo lo dicho: 8->1 bits).
Podeis mirar el código si quereis, aunque os adelanto que hay muchísimas funciones a bajo nivel, tanto que no le afectan posibles bugs o cambios del intérprete (los ficheros se generan dato a dato, y la información se guarda en memoria como gráficos independientes, y se analizan pixel a pixel). De haber usado funciones de Bennu, lo mismo el código ocuparía la mitad :D :D :D
Otra cosa, este es de mis primeros códigos en Bennu, por lo que puede que esté un poco desorganizado.
Funciona mediante comandos, no hay interfaz gráfica, así que para hacer la conversión de 8 a 1 bit, un ejemplo sería:
bgdi fntconv -nc -1 fuente.fnt fuente_1bit.fnt
Para obtener ayuda, usar -h como único parámetro.
¿bgdi -h? :D
Quote from: DCelso on December 15, 2010, 08:38:38 PM
¿bgdi -h? :D
¬¬U
bgdi fntconv.dcb -h
O bien:
fntconv -h
Si tienes las librerías en la misma carpeta y renombras el BGDI.exe, que es como lo tenía yo
Quote from: DCelso on December 15, 2010, 08:38:38 PM
Quote from: Drumpi on December 15, 2010, 08:32:49 PM
Hola a todos:
Bueno, como he dicho en varios hilos, he estado mirando por encima este programa, aprovechando que se ha puesto de moda el tratar con fuentes de 1 bit :D
He conseguido que funcione la conversión de FNT DIV-style a 1 bit, y creo que va bien a 16 bits. No he hecho pruebas exaustivas, así que, aunque suene mal, no garantizo un correcto funcionamiento (salvo lo dicho: 8->1 bits).
Podeis mirar el código si quereis, aunque os adelanto que hay muchísimas funciones a bajo nivel, tanto que no le afectan posibles bugs o cambios del intérprete (los ficheros se generan dato a dato, y la información se guarda en memoria como gráficos independientes, y se analizan pixel a pixel). De haber usado funciones de Bennu, lo mismo el código ocuparía la mitad :D :D :D
Otra cosa, este es de mis primeros códigos en Bennu, por lo que puede que esté un poco desorganizado.
Funciona mediante comandos, no hay interfaz gráfica, así que para hacer la conversión de 8 a 1 bit, un ejemplo sería:
bgdi fntconv -nc -1 fuente.fnt fuente_1bit.fnt
Para obtener ayuda, usar -h como único parámetro.
¿bgdi -h? :D
imagino que lo preguntas en broma, pero sin embargo es una buena pregunta para los novatos...
lo que dice drumpi es...
bgdi fntconv -h