Decoding unknown font file format

[holon]

I've been reversing some old Lego video game formats, but I'm stuck on this one. If anybody has any knowledge on how the .fnt file might be structured, it would be of great help. I'm also thinking it might be a regular font format that I've just not encountered before.

The most I've discovered is that:

struct header {
    int unknown; // always 0x00000000
    int unknown; // always 0x00000000
    int unknown;
    int charCount;
    int finalSectionOffset;
}

[URL="https://dl.dropboxusercontent.com/u/16266581/Balloon24.tga"]Balloon24.tga[/URL]
[URL="https://dl.dropboxusercontent.com/u/16266581/Balloon24.fnt"]Balloon24.fnt[/URL]

[NovembrDobby]

Char count looks to be correct, there are 114 on the texture.

There's a buffer of size 256 between the header and the start of the character layout info, may be the character codes?

Layout info starts at 276 (dec), as expected there are 114:

struct character
{
    //normalised co-ordinates: multiply by texture size
    float left;
    float top;
    float right;
    float bottom;

    int unknown5;
    int unknown6;
    int unknown7;
    int unknown8;
};

Reading those in gives you this:

[img]http://i.imgur.com/QoAlgKY.gif[/img]

:)

[editline]14th September 2014[/editline]

Is the texture itself part of the .fnt? Just wondering what all the gunk at the end is...

[holon]

Holy crap, thanks. Like the touch with the animated test there. The texture is separate, I figured that the section at 276 was the location information, but I had no idea how it was laid out. The formats I'm trying to read all seem to have junk information, I'm working on the idea that they are just artefacts from old versions of the format.

[NovembrDobby]

Ah, thought you may have grabbed the texture from memory separately or something.

I realised that #5 and #6 are the character sizes in pixels, maybe those are used in code whereas the normalised co-ords are for the shader.

struct character
{
    //normalised co-ordinates: multiply by texture size
    float left;
    float top;
    float right;
    float bottom;

    //dimensions in pixels
    int pWidth;
    int pHeight;

    int unknown7;
    int unknown8;
};

unknown7 is 0 for every entry, then the unknown8's look like they could be flags:

0
8
8
8
8
8
8
8
8
8
8
8
8
8
8
7
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
7
8
8
8
8
8
8
8
8
8
8
8
7
8
8
8
8
8
8
8
8
8
12
8
8
17
8
17
26
26
7
8
8
17
7
8
8
8
6
6
8
8
1
1
1
2
1
0
8
8
1
1
1
1
1
1
1
1
6
2
1
1
1
2
1
7
1
1
1
1
6
6
8

[proboardslol]

[QUOTE=NovembrDobby;45976465]Char count looks to be correct, there are 114 on the texture.

There's a buffer of size 256 between the header and the start of the character layout info, may be the character codes?

Layout info starts at 276 (dec), as expected there are 114:

struct character
{
    //normalised co-ordinates: multiply by texture size
    float left;
    float top;
    float right;
    float bottom;

    int unknown5;
    int unknown6;
    int unknown7;
    int unknown8;
};

Reading those in gives you this:

[img]http://i.imgur.com/QoAlgKY.gif[/img]

:)

[editline]14th September 2014[/editline]

Is the texture itself part of the .fnt? Just wondering what all the gunk at the end is...[/QUOTE]

Wtf how did you do that

[NovembrDobby]

[QUOTE=proboardslol;46012161]Wtf how did you do that[/QUOTE]

Opening the font in XVI32 you can see a pattern after the first bit of data:

[img]http://i.imgur.com/ofjRBk8.png[/img]

The pattern repeats after 32 bytes, so I guessed there would be 8 elements of 4 bytes each.

Interpreting the first two elements as floats (aka IEEE single in XVI32), I tried mapping them on a texture using SFML's Image class. It was a lucky guess as multiplying them by the texture size gave valid co-ordinates.

The next two elements also looked like floats, so using the same process I figured out they were the right/bottom co-ords. SFML saved out the plot images used to create the gif.

Realised what the next two were by coincidence when using the debugger. I had it set up to calculate the pixel width & height, and noticed that the numbers matched if #5 and #6 were interpreted as ints.

That's about all I managed!