d-side / ftl_font Goto Github PK

The manual is using more advanced English than it needs to, which gets in the way of users that don't know English very well — which, considering that the tool's original purpose was to facilitate translation of FTL into Russian, might hurt other fan translation teams too.

The target language level would be the level used in FTL, since the translators would have to handle that much in order to translate the game itself.

I'm putting this here as a backlog item, I have no scheduled plans to do it; to one person that asked so far I confirmed a few details personally, but if there are more of you out there, a clearer manual would help all of us.

I'm trying to use the fonts within FTL in another project. Disassembling them helps, but it would be extremely nice to be able to convert them into a bitmap font.

I apologize to you, but I am bad at understanding and it is difficult to understand. Can you help me step by step?
1: i download and install ruby installer-2.4.1-1-x64
then ?

Just in case it's still helpful

Also it looks like you're off by 8 bits in the character itself, "spacing before" is 8 bits later and there's "pad" there.

Texture section appears to have 2 versions supported by FTL.
Texture header is:
MAGIC always 4 characters TEX\n I think (0xa584554)... appears big-endian maybe?

Tex V2's format is:

char[4] magic
uint8_t version
uint8_t format
uint8_t mipmaps
unit8_t opaque_bitmap
int16_t width
int16_t height
int32_t field_7 // I think this is some sort of scale or font size field
int32_t pixels_offset
int32_t pixels_size
int32_t bitmap_offset
int32_t bitmap_size

Tex V1's format is:

char[4] magic
uint8_t version
uint8_t[3] // 3 bytes unused, probably padding in the original struct
int16_t width
int16_t height
uint8_t field_7  // I think this is some sort of scale or font size field
uint8_t format
uint8_t mipmaps
uint8_t opaque_bitmap
int32_t pixels_offset
int32_t pixels_size
int32_t bitmap_offset
int32_t bitmap_size

There's some weird flipping of values in the assembly code so it looks like any 2 or 4 bytes value is actually stored big-endian (this is true for both the TEX & FONT headers).

This appears to be the different texture format values supported, again v1 does something weird with remapping some of these but I think these values are valid for v2

This all came from decompiling FTL in Ghidra.