Possible problems with endianess

[Flix01]

I'm using a little endian machine.

I was wondering if the library would still work on big endian systems (I guess I'll never use one, but my mind seems to like to create problems...).

Possible issues I can see:

1. Binary .fnt loading. Is that format endian free ?
2. The bin2c file conversion used by ImGui seems to group bytes into blocks of 4 (4 bytes -> 1 Uin32).

These problems could be solved in two ways:
a) creating all the binaries on the same machine they're supposed to be used.
b) using a more robust approach:

• 1. Adding code to support loading .fnt in text format (currently it's not trivial to extend the ImBitmapFont class, because it seems to store the binary .fnt blob in a single block and use pointers to access its parts.).
• 2. Using a different bin2c file conversion that just stores bytes one after another (producing longer source code, but the binary code size should be equal).

I don't think this is a high-priority problem [solution (a) above needs no code change], but maybe some note should be written about it...

[ocornut]

Hello,
I am hesitant to look into a problem before we have an actual use case, aka someone trying to use ImGui on a big-endian machine.

1. I don't know!
2. That could be fixed. Currently using ~11 ascii bytes per 4 bytes. Naively expanding to single byte would cost ~20 ascii bytes per 4 bytes. Would grow imgui.cpp by about 12K bytes. Could use a macro to keep it small. I'd prefer keeping the binary format, it's optimal to store and parse, and b) is fixable.

There's no "need" to extend the ImBitmapFont class since it is meant to load that specific format. Why I might end up with is a way to load TTF via stb_truetype and still support Angel bitmap format as well.

For now I'd rather close this to focus on important stuff, add a "Support big-endian" in the todo list. If someone shows up with that need they or us can find a solution. Unless you are feeling like investigating this on an actual big-endian architecture I'd close this and we can reopen in the future.

[Flix01]

Unless you are feeling like investigating this on an actual big-endian architecture I'd close this and we can reopen in the future.

Agreed: my main purpose was just to address a possible issue.

[ocornut]

It's a fair issue! I added a reference to the bug number to the ImGui TODO list. Thanks.

[ocornut]

The embedded font data now used a base85 encoded string processed byte a byte and should be working on big-endian machines.

[ocornut]

I switched the font back to regular encoding to reduce binary space, source code is in a way that is big-endianess compatible.