ZDoom

Personally I think that any binary storage format that contains binary float representations is playing with fire. Unless there's a very good reason to support it it won't happen.
'Just in case' won't do and for integers there's really no reason to implement this.

I can do that, sure (which I have in the past for earlier builds, by generating an assload of zscript), but where's the fun in that?

Plus, it adds an annoying step in the middle of having to run the conversion tool over everything every time I need to make a change. If I can load the QAVs directly (which I do currently, loading floats isn't an immediate issue right now, I made this feature suggestion for when it [i]does[/i] become a problem)

Sure, there's still a conversion step to convert the images from build tiles, but that only needs to happen once. If changes need to be made to how weapons and such are animated, that needs a re-run of the tool.

Then also consider that for such a mod to be "legally" distributed, it would have to include the conversion tool (since it can't include the assets), and chances are a significant portion of players would have trouble with it, as opposed to just adding the relevant files to a separate pk3.

Why don't you write a conversion tool that will run once and produce assets directly usable by GZDoom?
I see no point in doing this every launch for every user, especially via ZScript.
IMHO the overall approach with loading various binary files and parse/convert then on the fly is wrong.

In a development build of Extra Crispy (a mod where I aim to recreate Blood's weapons as accurately as possible) I am loading Blood's animation files (.QAV) via ZScript at load time, so weapons from Blood mods can be loaded as well as regular Blood weapons. The .QAV files are a binary format, and while that specific format doesn't contain any floating point values, other data files I may wish/need to load in the future could.

Where's the use case?
There is no binary save mechanism and before any binary loading mechanism is implemented there will rather be an actual text parser.

[quote="Graf Zahl"]Floating point representation is implementation dependent and should not be exposed this way.[/quote]
Then the functions are simply made to expect a specific floating-point representation (such as IEEE 754).

[quote="Graf Zahl"]And splitting integers is trivial to do on the script side.[/quote]
That was for consistency in the API.

No, absolutely not. Floating point representation is implementation dependent and should not be exposed this way.
And splitting integers is trivial to do on the script side.

If you're going to add such an API, make sure there's also differentiation between Little Endian and Big Endian byte order.

class BitConverter
{
    static int BytesToInt16(int a, int b);
    static int BytesToInt32(int a, int b, int c, int d);

    static float BytesToFloat32(int a, int b, int c, int d);
    static double BytesToFloat64(int a, int b, int c, int d, int e, int f, int g, int h);

    static int, int Int16ToBytes(int n);
    static int, int, int, int Int32ToBytes(int n);
    static int, int, int, int Float32ToBytes(float f);
    static int, int, int, int, int, int, int, int Float64ToBytes(double d);
}

Currently, there is no way to convert a series of bytes to a float or a double in ZScript (you can get around it by marshalling data using ScriptCall and C via GDCC, but this limits you to play scope, and requires you to be ingame, ruling out StaticEventHandler::OnRegister).

Perhaps a class like the following could be implemented?

[code=php]class BitConverter
{
    static int BytesToInt16(int a, int b);
    static int BytesToInt32(int a, int b, int c, int d);

    static float BytesToFloat32(int a, int b, int c, int d);
    static double BytesToFloat64(int a, int b, int c, int d, int e, int f, int g, int h);

    static int, int Int16ToBytes(int n);
    static int, int, int, int Int32ToBytes(int n);
    static int, int, int, int Float32ToBytes(float f);
    static int, int, int, int, int, int, int, int Float64ToBytes(double d);
}[/code]