Sólo he encontrado las expecificaciones del formato fnt para 8 bits, el cual ya lo tengo. Existe el formato fnt para 16, 32 bits de profundidad? Si existe o se ha creado la expecificación, la necesito para mejorar el visor de FBMX.
Un saludo y gracias de antemano
Depaso comentar también que habría que crear un programa para crear FNTs con caracteres especiales (tildes, eñes, etc...) ya que FNT Edit no lo soporta.
Actualmente hago las fuentes con el DIV 2.
el formato de 16 y 32 es el mismo que el de 8 bits... hay un campo que indica la profundidad...
Y la parte de la paleta se queda vacío?
Por cierto, también recordar que existe la de 1 bit.
exacto, no hay paleta... 1 bit tampoco tiene paleta... tambien obviamente el dato pixel es del tamaño que corresponde.
Splinter, no tendrás por ahí un fuente de 32 bits. Es para probar el visor de FBMX, así tengo con qué trabajar.
Gracias
no, no tengo...
pero podes usar las funciones:
* FNT_NEW (DEPTH)
Create a new font in memory (returns the font ID)
* GET_GLYPH (FONT, GLYPH)
Create a system map as a copy of one of the font glyphs (returns the map ID)
* SET_GLYPH (FONT, GLYPH, LIBRARY, GRAPHIC)
Change one of the font's glyphs
* SAVE_FNT (FONT, STRING FILENAME)
Saves a font to disk
y crearte tu propio font de la profundidad que quieras (de las soportadas por el render, obviamente)
Bueno,vengo con otra pregunta:
¿Exactamente qué carácteres o letras entran en los grupos de symbols y extendend? He estado mirando en el manual de DIV porque me sonaba que aparecían qué carácteres contenía cada grupo, pero no he encontrado nada.
Un saludo
los 256 caracteres ASCII.
Quote from: SplinterGU on February 09, 2009, 06:42:20 PM
los 256 caracteres ASCII.
Supongo que lo son. Pero no sé cómo se dividen en esos dos grupos, cuáles pertenecen a los símbolos y cuáles a los extendidos (ideas generales aparte).
Eso realmente no importa mucho, son 256 caracteres que corresponden al valor numerico de 0-255 (1-255 en realidad)...
Representen lo que representen... uno puede crear un font completo que no contenga ni un solo caracter, que solo contenga dibujitos... o lo que sea...
Bueno, en el viejo manual de DIV encontré al final dónde se nombraban.
Lista de símbolos: # ª º $ P f (función) Libra Yen C-extraño
Extendido: ñ ç ae(junto) âäàa(con º encima)á e i o u ÿ
Me parece que son pocos, ¿falta alguno verdad?
aca te paso la tabla de ascii que yo usaria
(http://www.asciitable.com/asciifull.gif)
(http://www.asciitable.com/extend.gif)
Otra cosa. Para diferenciar si el fnt está en formato 8bpp, 16bpp ó 32bpp, se debería mirar en el dato de versión, ¿me equivoco? Hasta ahora esto estaba siempre a cero.
Cabecera
Un fichero FNT comienza con la siguiente cabecera:
MAGIC 3 bytes Cadena de caracteres de identificación del fichero. Debe contener exactamente "fnt", en minusculas.
TERMINACION MS-DOS 4 bytes A continuación, los cuatro bytes 1Ah, 0Dh, 0Ah y 00h. Esta terminación indica, en un fichero MS-DOS, final de fichero. Gracias a ella un comando TYPE en MS-DOS no mostraría los datos binarios del fichero.
VERSION 1 byte Código de versión. Debido a que no se han introducido cambios en el formato, este valor es siempre 00h.
No se si será demasiado tarde, pero ya he descifrado el contenido del formato FNT de Fenix.
Hay muchos más cambios de los que parecen a simple vista. Si esperais, el proximo día os traigo un documento completo con lo que yo he visto.
Puedo adelantar que el campo magic varía, empezando por "fnx" en lugar de "fnt" y que el octavo byte ya no indica la version, sino la profundidad de la fuente (1, 8, 16, 32).
Los descriptores de los caracteres pasan de tener 4 campos int a 7, pero como no se el orden, esperad y os lo digo seguro más tarde. Se ha añadido un campo llamado xoffset (similar al yoffset antiguo pero para el eje x, y otros dos campos que parecen expresar el ancho y alto definitivos de la fuente, sumando, por ejemplo, el ancho del mapa y el offset, aunque según comenta splinter, son las medidas que se toman para dibujar el siguiente caracter.
Y el campo que indicaban los grupos de caracteres añadidos (numeros, letras, etc...) tambien tiene un significado distinto: el charset utilizado.
-CHARSET_CP850=1
-CHARSET_ISO8859=0
Y luego ya vienen los datos de los mapas.
el orden lo tenes aca
http://forum.bennugd.org/index.php?topic=464.msg5766#msg5766
*offset es del caracter actual... *advance es el avance al siguiente... y luego a este advance se le aplica el offset del proximo y ahi va ubicado el primer pixel del caracter...
Bueno, pues aqui subo la especificación completa del formato FNX, para el que quiera conocerla. Puede que alguna descripcion no sea muy acertada, pero os hareis una idea. Fenixwiki modification powa :D
Gracias drumpi (karmaUp), realmente no tenía ni idea de que Fenix usaba un formato de fuentes distinto al de Div hasta que leí este post...
Una pregunta, entonces lo lógico sería que las fuentes de Bennu lleven la extensión "fnx", no?
Otra cosa más: en la especificación del FNX no hay ningún bit que indique la versión del formato... ¿es así?
Bennu usa las mismas fuentes que Fenix, sólo que ahora añade el modo 32bits de color, que se explica cambiando el respectivo campo y tomando los datos de 4 en 4 bytes, en lugar de 2 en 2 como en 16bits
No, no hay campo que especifique la version, ha sido sustituida por el bpp. De todas formas, en DIV existía ese campo y nunca pasó de valer 0 ¿por qué iba a ser necesario? :P
Siento sacar este hilo de nuevo, pero creo que los que habéis escrito aquí podréis asesorarme con esto:
¿Actualmente es imposible con una fuente .fnt escribir caracteres con tilde?
¿Qué tipo de formato de fuente debo usar para que write_var muestre correctamente vocales con tilde guardadas en una string?
Estoy teniendo un problema porque estoy haciendo un juego con "historia" y no consigo que ninguna tilde salga bien, la verdad es que queda muy raro y le he puesto mucho mimo como para quedarme sin poder usar tilde :-[
Cosorro, cosorro...!!! ;)
Refloto el tema para refrescar las preguntas de Windgate, y también para preguntar yo si habría alguna posibilidad, por pequeña que fuera, de actualizar el FNTEdit al igual que se ha hecho con el FPGEdit para que soporte fuente de 32 bits.
Gracias.
seria interesante tambien que den soporte a fonts de 1bit...
yo tuve que hacer un conversor muy basico, de font de 8 a 1, pero solo si existe pixel es 1, si no existe es 0... demasiado basico.
Sí que molaría, sí.
Prg no sabía algo de ese tema de fuentes en 32 bits...?
La verdad pensaba que alguien ya había hecho algo en ese sentido, cierto es que habiendo gráficos en 32 bits las fuentes en 32 bits serían otro puntazo a favor de Bennu.
Ahora mismo estoy creando fuentes de gran tamaño para mostrar los nombres de mis juegos en la pantalla de presentación, pero las transparencias, la suavidad de bordes, etc. en una fuente en 32 bits quedarían mucho mejor.
Viendo el código fuente de fntedit, no le veo ventajas para que cree fuentes de 32 bits, solo usa 4 colores para generar el fnt, así que lo veo bastante tonto hacerlo en 32 bits ya que ocupa bastante más que en 8 bits y no aporta nada.
Otra cosa sería si se pudieran editar las imágenes de cada una de las letras o algo así.
Puede que dar soporte a 1 bit sí que sea útil, ocuparían menos las letras, lo analizaré a ver si cuesta poco insertarlo.
la utilidad de fonts de 32 bits... es que podrias hacer las sombras con alpha, o incluso la letra o lo que sea, y elegir el nivel de la misma... con lo que la sombra con alpha quedaria excelente... incluso podria hacerse algun efecto blur a la misma...
la ventaja de usar las fonts de 1bpp es que se les puede aplicar color con SET_TEXT_COLOR... las fonts con mas bpp hacen caso omiso a este comando.
:D, visto así, miraré que tal sería.
windgate, osk, no se si ya lo sabeis pero, en lo referente a hacer fuentes con tildes y eñes puedo decir que actualmente fntedit lo permite, solo tienes que activar la casilla del grupo contenido llamada "Extendido" y generar la fuente. Esto añade los 128 nuevos caracteres que inserta el ascii extendido a la tabla ascii y entre ellos está nuestra querida ñ y las vocales acentuadas.
Paciencia, paciencia. En el subforo de proyectos tengo algo para trabajar con fuentes:
http://forum.bennugd.org/index.php?topic=464.0
En principio sólo era un conversor de profundidad de color, pero estoy viendo que se podrían hacer más cosas y convertirlo en editor.
La pega es que estaba programándolo usando funciones de pintado pixel a pixel (porque internamente trata las letras como mapas, lo que iba a permitir usar cualquier tipo de gráfico a cada caracter) y generando los ficheros de fuentes byte a byte (sin usar las funciones propias de bennu), lo que me da una serie de fallos que no he tenido tiempo de arreglar.
Posiblemente acabe por usar las funciones que comenta splinter en la primera página del hilo (de las que no tenía documentación cuando lo empecé), pero de todas formas, ahí está el código fuente, para el que quiera modificarlo (o seguirlo, ya sabeis cómo soy, tengo la cabeza en cuarenta sitios a la vez ^^U)
Funciona como cualquier programa de linea de comandos (la GUI para cuando funcione) y, que yo haya probado, la conversión de 8 a 16 bits funciona perfectamente (32 bits no recuerdo si llegué a añadirlo).
Además, creo que también había algo preparado en cierto pack
drumpi, he probado tu conversor con mi fuente de 8 bits y me pasa lo mismo consigo obtenerla convertida en 16 bits pero con los colores cambiados.
el resultado de bgdi fconv fuente8bits.fnt
Compresion = 1
Formato = 1
Bpp = 16
Error de lectura: 0
Datos convertidos.
Error de escritura: 0
luego si usas la fuente 8bit y la fuente convertida en un programa prg de 32bits de profundidad no se ven del mismo color.
Y además si intentas usar la fuente de 16 bits en un prg de 16 bits, el programa se queda colgado
Edit: parece ser que es culpa de la versión que tengo de bennu, así que repetiré la prueba con la siguiente versión de bennu. Mientras ignora el post :D
muchas gracias drumpi, volvere a revisar esto, hoy por la noche... saludos.
Raro, porque ya he dicho que he convertido una fuente 8 bits div-mode a 16 bits fenix-mode, y de momento no me ha dado problemas de cuelgues en modo 16 bits... aunque claro, sólo la he usado en Fenix ^^U (ya sabeis que estoy en periodo de transición, dadme unos meses).
He estado jugando a World of Warcraft estos días, ¿Créeis que las fuentes que usa en la ventana de son de 32 bits? Lo digo por la transparencia y nitidez que tienen... ¿O es que es una Arial y nunca uso fuentes "normales" en mis juegos?
(http://www.wowbash.com/images/1184968509.jpg)
Me ha llamado la atención que se trata de una letra minúscula, pero se lee perfectamente... Aunque como os digo no soy capaz de distinguir si son 16 o 32 bits ;D
No parece que tenga transparencias.El rosa, morado y azul siempre es el miso independientemente de la imagen de atrás.
Puede que sean muchas letras (una para cada color) de 32 bits pero con canal alfa a 255 excepto en los píxeles transparente que está a 0.
O puede que sea una letra de 1 bit a la que cambian el color del bit a mostrar. Si ves última la imagen que adjunté en el post de acerca de fnt y los 8 bits, verás una fuente de un bit en dos colores distintos usando settextcolor.
No me refiero a transparencias totales, me refiero a que no hay pixelado en los bordes de esas fuentes, parece que los pixels del borde de las fuentes tienen una transparencia parcial para lograr más nitidez, desde luego son nítidas de narices y aunque la captura es un poco caca en el juego es soberbio lo bien que se lee.
Voy a mirar la imagen que dices, en temas de fuentes de 1 bit no estoy muy puesto... Y set_text_color nunca lo he usado :-\
Creo que eso es un añadido del sistema operativo llamado "suavizado de bordes" (si no es del operativo será de alguna librería o similar) Creo que es una de las ventajas de usar formatos de fuentes a las que luego se les puede especificar el tamaño. Fijate que la ttf.dll genera FNT a partir de una fuente y un tamaño, y que se puede escribir en word en cualquier tamaño (como si el formato de las fuentes fuera como las imágenes vectoriales).
No es lo mismo que en los FNT, donde cada letra en realidad es una imagen.
Cierto, ya me había percatado que las TTF se comportan como gráficos vectoriales, de hecho con InkScape puedes hacer una letra del tamaño de una casa y los bordes se mantienen suaves e inmaculados.
Quizás en el World of Warcraft hayan puesto alguna especie de soporte para TTF o algún formato similar, eso permitiría incluso realizar zoom a los textos... :D
La verdad, lo comento todo desde una capa muy superficial ya que no conozco cómo están implementados los ficheros .fnt de Bennu, sólo me quedo con la idea de que son gráficos, pero la idea de poder usar fuentes en 32 bits con una relativa sencillez me atrae muy mucho.
(Hablando de gráficos vectoriales, alguien ya comentó algo de una librería libre que soportaba .svg, se llamaba Cairo y le eché un vistazo en su día, aunque la idea de portarlo a Bennu me resulta demasiado compleja)
Windgate, los FNT son básicamente FPG, sólo que tienen información distinta en la cabecera y sólo soportan 255 gráficos. De hecho, y como ya llevo demasiado tiempo retrasándolo y seguramente no lo haga, estuve pensando en diseñar el motor de tiles sustituyendo los procesos que manejan los tiles por cadenas de texto, usando como "fuente" un FNT que guardase los tiles, lo cual hubiese ahorrado la carga de manejar procesos, las variables asociadas, y permitiría una forma completamente sencilla de cambiar los gráficos "in the fly"... pero como tuve problemas raros generando las fuentes y me puse de parto... estooo, de exámenes, pues quedó relegado a una posición poco prioritaria de mi pila.
Respecto a añadir soporte SVG a Bennu, podría ser el inicio de la invasión de los programadores flash :D aunque no se qué es más sencillo, si flash o bennu.
fijate la palabra "moment", la "nt", eso tiene alphas... mira como la parte superior se ve el fondo...
Quote from: Drumpi on July 29, 2009, 11:17:32 PM
Windgate, los FNT son básicamente FPG, sólo que tienen información distinta en la cabecera y sólo soportan 255 gráficos. De hecho, y como ya llevo demasiado tiempo retrasándolo y seguramente no lo haga, estuve pensando en diseñar el motor de tiles sustituyendo los procesos que manejan los tiles por cadenas de texto, usando como "fuente" un FNT que guardase los tiles, lo cual hubiese ahorrado la carga de manejar procesos, las variables asociadas, y permitiría una forma completamente sencilla de cambiar los gráficos "in the fly"... pero como tuve problemas raros generando las fuentes y me puse de parto... estooo, de exámenes, pues quedó relegado a una posición poco prioritaria de mi pila.
Respecto a añadir soporte SVG a Bennu, podría ser el inicio de la invasión de los programadores flash :D aunque no se qué es más sencillo, si flash o bennu.
Jejeje... es buena idea... como experimento... pero yo no te sugiero que hagas eso, los textos consumen muchisimo... muchisimo...
¿Los textos consumen muchísimo...? Me acuerdo de mi carrera en la que durante los 4 primeros años no hicimos más que trabajar con textos, hicimos un par de juegos pero 100% basados en caracteres con mil complicaciones para luego llegar a Bennu y descubrir que todo es muuucho más fácil y que existen librerías gráficas.
No sé si flash es más sencillo que Bennu, sólo sé que me puse con flash en su día y me pareció aburridísimo, apenas logré dibujar un cuadrado y moverlo, y me rendí. Después de 2 años programando en Bennu y en prácticamente nada más para mí Bennu es tan sencillo como el lenguaje hablado xD
Dar soporte a .svg me parecería un punto fuerísimo para Bennu, ya que los efectos de zoom (La variable size en particular...) no tienen nada que ver con lo que permitiría un dibujo vectorial.
Y si vienen flasheros que vengan xD
Me estoy saliendo del hilo... Ahora me viene a la mente que alguien habló recientemente de dar soporte a los textos para poder rotarlos. Nunca he probado el "write_text_in_map" o como se llame, pero con eso debería valer, ¿No? Clonando el mapa base y escribiendo sobre la copia cada vez no le veo mayor complicación.
obviamente que me refiero a los textos de bennu...
los textos en fenix/bennu consumen muchisimo, porque hacen blit de caracter a caracter... lo que representa recalcular cada uno de los mismos, calcular posiciones, dibujarlos, etc...
es una de las cosas mas costosas del motor...
Hombre, pero eso tambien se hace si cada tile usa un proceso. Pero vamos, buscaba formas de optimizar el motor de tiles en GP2X sin usar código C, y tenía que tirar por la vertiente de usar herramientas Fenix/Bennu. Ahora he pensado en usar el scroll con un gráfico grande (640x480 por ejemplo), una técnica similar al graph_tscroll, pero con un mapa más pequeño y sólo modificando parte del gráfico (la fila o columna que está a punto de verse).