Fire Emblem Shadow Dragon font format

Discussion in 'NDS - ROM Hacking and Translations' started by duckbill007, May 24, 2011.

May 24, 2011
  1. duckbill007
    OP

    Newcomer duckbill007 Newbie

    Joined:
    May 5, 2011
    Messages:
    5
    Country:
    Russia
    Hi!

    Can somebody help me with understanding of compression, used in Fire Emblem Font?

    Other detail of font format are quite easy but I can not get the compression.

    Each letter is 16x16 pixels but I do not know how much bits per pixel. I think that it is 4bpp, because it uses at least 5 different colors and 3 bpp is very rare.

    I think that this compression is one of the RLE variant.

    Here is the examples of compression:


    M
    5F FF FF FF 4F 49 8F 52 5F 8F 12 F2 FF 8F F5 11 05 FF 8F 5F 51 0F 5F 8F 0F 55 0F 0F 8F 09 54 F9 0F 8F 1F 55 1F 8F 19 1F 07 FF 80

    y
    FF FF FF FF FF AB F2 F1 FB F1 AA FB F1 FB F0 84 5F BF FF 5B 84 F3 D5 FF


    .
    FF FF FF FF FF BF FF FF F5 FF 03 F8

    :
    FF FF FF FF FF 7D 5F FF FF EF 07 FF

    l
    7F FF FF FF 5F 55 EF EF EF EF D5 EF EF EF FF 01 80

    I
    BF FF FF F5 FE AA FE FE FE FE AA FE FE FE FF 03 F8

    !
    3F FF FF F4 CF 49 DF FD CF D9 6A FE FE FF EF 1D EF FF 80

    |
    5F FF FF 5F EF 55 EF EF EF EF 55 EF EF EF EF 07 FF 80

    -
    FF FF FF FF FF E3 F3 FF FF FF 0F FF F8

    _
    FF FF FF FF FF 3F FF FF F3 FF 0E FF F8

    =
    FF FF FF FF FF C1 1F FF FF FA E0 FF FF FF FF 07 FF 80
     
  2. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,711
    Country:
    United Kingdom
    Quick question is this an additional font to those NFTR fonts (crystaltile2 and http://gbatemp.net/t105060-nftr-editor? although read the last page or two both support this format) in the /font directory?
     
  3. duckbill007
    OP

    Newcomer duckbill007 Newbie

    Joined:
    May 5, 2011
    Messages:
    5
    Country:
    Russia
    Maybe I incorrect wrote Game title. I mean US release of Fire Emblem DS (Fire Emblem 11).

    There is no NFTR fonts in this ROM as far as I know.

    Folder fonts contains following files: aplpha, bit, pal, sys_wars and talk.
     
  4. rastsan

    Member rastsan 8 baller, Death Wizard

    Joined:
    May 28, 2008
    Messages:
    963
    Location:
    toronto
    Country:
    Canada
    Did you read the docs at the fire emblem shrine about fire emblem 11?
     
  5. duckbill007
    OP

    Newcomer duckbill007 Newbie

    Joined:
    May 5, 2011
    Messages:
    5
    Country:
    Russia
    Yes. Absolutely no technical info about fonts.
     
  6. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,711
    Country:
    United Kingdom
    Wait I grabbed the wrong rom (not the first time I have done such a thing either and I had been up for a few hours).... Anybody looking to fiddle with Blue Dragon -Awakened Shadow there are NFTR fonts in there.

    Compression fragments are not ideal things to work with (such things are usually done across an entire file) although RLE and packing are a bit different.

    General pulling the rom apart.

    The utility.bin (the download play component) did have a couple of compressed NFTR fonts but I am not going to go there yet- it can be that it is a mini rom but I doubt it in this case.

    A bunch of files with font in the name- crystaltile2 displayed stafffont.cg quite nicely although I am willing to bet that is end credits related.

    The directory "m" clearly contains messages (LZ compressed in almost pure ASCII) as does the script directory.
    In the directory "mm" there are a bunch of compressed files with font in the name although a quick scan did not drum up anything useful.

    The tpl files in the "onmap" appear to be palettes of some form. .cl files appear to be palettes elsewhere wiht .cg files being the images- I managed to generate what appears to be a few characters from gradefont.cg (basic crystaltile2 decompression) and gradefont.cl in the mm directory and likewise with chapterfont files.
    I also pulled apart the "extramenu" files and got a bunch of text hardcoded in the image ( http://pix.gbatemp.net/32303/fedsextramenu.jpg ) but I guess you already saw that sort of thing.

    The face.bin in the "f" directory caught my eye and had a nice list and seemingly some pointers but that is not helping with the font.

    The ASCII subdirectory contained 32, 64 and 128 files all with the extension .cg and these did appear to have a few characters in once decompressed although they were very "puffy" and not really suited to general text. Standard GBA 4bpp again
    [​IMG]

    Apologies for the size and improper colouring- I was too lazy to printscreen it and for some reason skipped over the cl file until after I had uploaded that- the text is white with a black shading on a blue not entirely different to the background of this site- just a bit lighter (if I remember my Russian more ????? than ??????? - sorry about that the whole Russian language and blue thing amuses me).
    The 64 and 128 files look more or less the same just that they have bigger gaps in (I guess as padding to allow for longer addressing or something).
     
  7. rastsan

    Member rastsan 8 baller, Death Wizard

    Joined:
    May 28, 2008
    Messages:
    963
    Location:
    toronto
    Country:
    Canada
    tokemeki girlside story 3 font looks slightly the same. Couldn't figure that one out either. this one looks like it has a pointer table.

    although after lz extracting the sys_wars font something closer to (but not quite i'm still off a little) 8 by 14 vb2bpp. although it did make some sense looking at it ngp 90+ angle thats when ct2 crashes when I try to change the width.
    but for alpha nothing. type 40 compression maybe for alpha.
    sorry I wasn't that much help.
     
  8. duckbill007
    OP

    Newcomer duckbill007 Newbie

    Joined:
    May 5, 2011
    Messages:
    5
    Country:
    Russia
    Fonts that is used for dialogs and menues are in the fonts folder. For dialogs (That is what I want to translate first) used font "talk". I figured that out by corrupting this file.

    Files "alpha" and "talk" uses the same format.


    As far as I understand file structure:
    [Header Section]
    [Data Section]

    Header section:
    4 bytes: Total file length
    4 bytes: Offset in Data section of some table (Table1)
    4 bytes: length of Table1
    20 bytes: Unknown (padding?)

    Table1 contains two sets of pointers (4 bytes each).
    First half of table:
    offset in the data section of pointer to glyph attributes record
    Second half of table - offset in the data section of pointer to glyph image

    Glyph record is:
    2 bytes: Code of symbol (I do not determine code page, but probably ShiftJIS)
    2 bytes: width of symbol
    4 bytes: pointer in data section for glyph image
    4 bytes: unknown (always 0, padding?)


    That's why I use compressed sequences in the first message. By randomly corrupting that sequences I got that glyph image is 16x16 pointers with at least 5 different colors (I think they are used for font antialiasing).


    BTW, what is type 40 for compression? I know 10, 11, 20, 30, but what is 40? Some LZ family?
     
  9. FAST6191

    Reporter FAST6191 Techromancer

    pip
    Joined:
    Nov 21, 2005
    Messages:
    21,711
    Country:
    United Kingdom
    I forgot to do it for my last post but I scanned through the ARM9.bin and overlays as well- a bunch of text in there too (ASCII again and mainly wifi related but not all of it).

    Anyhow nice- I have not used much corruption lately.

    Yeah type 40 is a relatively new type of LZ- Golden sun had it first apparently although this does not look like it (loads of 6 byte runs of 00 for one and nothing to indicate LZ- no flags or anything beyond the initial flag as it were).
    DSdecmp and http://gbatemp.net/t274472-codec-lzss-ds-released should support it.

    Anyhow I started to pull apart the alpha file after rastsan pointed me at it although I fear I am only going to half confirm some of the things you mentioned.
    First value as you say is the length and appears to hold for both
    Second if taken to be a pointer does appear to coincide with a shift in patterns but if you lose the initial header and start at 20 it lines up even better (pointers in DS roms have a habit of doing this).

    alpha is rather clean and has a bunch of values (that count upwards C at a time- nothing unusual for something as regular as fonts/glyphs/characters though) and then padding.
    talk has a bunch of values (again counting up C every time) and then random stuff dropped around and no clear shift to anything.

    Anyhow getting back to business

    alpha
    At 320 the file stops having 00's and has something nice for 2F4
    This section has 12 byte entries (or more likely 2 bytes, 2 bytes and 8 bytes)
    First 2 bytes appear to be counting upwards in hex.
    No idea what the second 2 do yet but you say width which works for me (values more or less work for it at a glance)
    Punctuation makes this tricky so a kind of relative search to try and confirm this I think is in order
    The usual suspects (ijl and on the flip side wmo and the like) would go in the order ijkl so I would expect. two small, one normal, one small although if it is a serif font that can throw things. I might also try for a comparison between alpha and talk but I will stow that for a minute.

    4 is the smallest entry at 2d2 (sorry I should have stated I punted the second table as it were to another file)
    It appears to be one odd character and then maybe the alphabet
    One case
    Code:
    Readouts from my hex editor as follows
    First characters are my own I added for clarity, the next is location/offset (new file remember), the next is data and the next is ASCII readout)
    H 00000060 0048 000F 0F46 0000 0000 0000 .H...F......
    I 0000006C 0049 0008 1274 0000 0000 0000 .I...t......
    J 00000078 004A 0009 14BF 0000 0000 0000 .J..........
    K 00000084 004B 000F 175B 0000 0000 0000 .K...[......
    L 00000090 004C 000C 10D5 0000 0000 0000 .L..........
    M 0000009C 004D 0012 16C1 0000 0000 0000 .M..........

    The other case
    Code:
    H 000001E0 0068 000B 15CD 0000 0000 0000 .h..........
    I 000001EC 0069 0005 13E5 0000 0000 0000 .i..........
    J 000001F8 006A 0005 1389 0000 0000 0000 .j..........
    K 00000204 006B 000B 11A4 0000 0000 0000 .k..........
    L 00000210 006C 0005 131E 0000 0000 0000 .l..........
    M 0000021C 006D 0011 154A 0000 0000 0000 .m...J......
    N 00000228 006E 000B 13AE 0000 0000 0000 .n..........
    File then has enough left over to get to Z with the W position also being large.
    Something of a coincidence with the ASCII readout there- it might still be swapped cases but even so.....

    Passes first blush test. Proof is obviously in the doing (I would just change lengths to be far wider and hopefully see it as a quick test) but I am far too lazy for that right now.
    Also I have never done that before- linguistics/relative order to feed fuzzy width calculations.... I shall have to remember it.

    Having had my fun back to work
    Pointers..... very odd order but we are dealing with a truly custom font format (well I have not checked against NFTR and other known custom formats yet so truly custom might be a bit premature) on a game with at least 5 fonts at this point so I am not inclined to doubt it.
    Still no collisions that I can see and nothing that immediately jumps out (one entry 13F0 and another 13F2 or something like that).

    005F 000A "1982" is the longest length in alpha and seems to be in punctuation or numbers country rather than a roman character but I will come back to that later.
    If I drop the as yet unknown section in a new file 1982 is way outside the file so moving back to a normal file- I have to decide whether to keep or lose the header.

    Also the second table the header points at appears to count up in 4 with 4 byte entries starting at 00
    alpha makes it to 05EC where talk makes it 0AB0 - talk is the bigger file as it were so that is nothing drastic.
    I should probably check it against the initial table for amount of values (doing the new file thing again alpha has the last entry at 00FA where talk has the last entry finish at 017c) but my stomach is rumbling so I am out for an hour or two (just as it gets interesting I know).

    All I will say is there are lot of F characters (presumably a blank colour) in the unknown section. Padding or maybe something like palette then data?
     
  10. duckbill007
    OP

    Newcomer duckbill007 Newbie

    Joined:
    May 5, 2011
    Messages:
    5
    Country:
    Russia
    Ok. You just confirmed my thoughts about file format. Those FF definetly blank spaces but it is a compressed format. Look at my first message in this thread. There I posted some sequences that are confirmed to be compressed form for some characters. For example look at sequence for = character.
    If I replace first two FF with C1 1F, I get upper stroke of = sign at the first line of the character glyph, but following lines will be damaged. That's why I decided that compression is some sort or RLE.I can be wrong, But I always thought that LZ type of compressiongives less count of equal bytes (subsequent FFs).

    Sorry if my post is hard to understand, but it is really late now in St.Petersburg, Russia and I had a very hard day today.
     

Share This Page