Float to Fixed Behavior

Converting from floating to fixed point in Doom is essentially:

fixed_t float_to_fixed(float f) {
    return (fixed_t)(f * ((float)FRACUNIT));
}

But this can result in undefined behavior: it's possible for the multiplication operation to yield +INF, and casting that to an integral type is undefined.

 

My question is what Doom expects in this case?  Does it want a clamp at 0xFFFFFFFF or 0x00000000?  Does it expect wraparound?

 

In advance, I'm not interested in "this rarely if ever happens".  I would guess that's the case.  I'm just trying to avoid undefined behavior if I can at all help it.

Share this post


Link to post
23 minutes ago, Ladna said:

My question is what Doom expects in this case? 

Uh, nothing? Doom doesn't use any floating point conversions? Are you talking about some particular source port?

Share this post


Link to post

You have to be very, very careful here. Whatever some Doom port may expect solely depends on the CPU it was developed on.

And there's different behavior here between Intel and ARM CPUs, and on some compilers even differences between instruction sets (Visual Studio will produce different results on non-SSE2 vs. SSE2 enabled systems, even from the same binary!)

 

If you need defined behavior here, check out xs_Float.h in ZDoom, or its wrapper function FLOAT2FIXED. This is basically the only way to guarantee consistent results.

 

Share this post


Link to post

Yeah like basically anything modern.  Like this is in PrBoom+:

static float GetTexelDistance(int dx, int dy)
{
    //return (float)((int)(GetDistance(dx, dy) + 0.5f));
    float fx = (float)(dx)/FRACUNIT, fy = (float)(dy)/FRACUNIT;
    return (float)((int)(0.5f + (float)sqrt(fx*fx + fy*fy)));
}

I imagine Cardboard does similar float -> fixed stuff, or a GL renderer.

 

EDIT: Thanks Graf; I'll have a look :)

Edited by Ladna

Posted (edited)

Share this post


Link to post

That function has another far more subtle problem:

 

Complex math functions can produce off-by-one-bit results on different compilers.

For renderer-side code this is not relevant but when porting the entire play code to floating point, ZDoom only uses math functions it compiles itself to ensure consistency.

Share this post


Link to post

Shouldn't it be safer to use functions like `floor()` here to convert from float to int? Or multiplication with "1.0" instead of casting from int to float?

Share this post


Link to post

Multiplication with 1.0 and casting is identical. An int -> float cast will always lose the same amount of information, no matter how you do it.

The problem with 'floor' is that they return a float again so you'd still have to cast it back to int and have the same issues to deal with. And the native conversion operations are implementation dependent (so if you need reproducable results, stuff like xs_Float.h is the only viable option.

 

This stuff was actually causing major headaches in some parts of ZDoom's node builder because it only worked on platforms that do a float->int cast with wraparound, but neither ARM nor SSE2 are handling it that way and worse, use different cutoff values. Trying to fix it for one platform would break it even more for the other and vice versa.

 

Share this post


Link to post

To kind of provide closure: I'm planning on doing this kind of thing only for the renderer, so I went with a clamp inside an #ifdef.  It may turn out that I can't confine floats to the renderer, in which case it looks like I'll have to do something like what ZDoom does, but we'll see.  Thanks again everyone.

Edited by Ladna

Share this post


Link to post
6 hours ago, Ladna said:

To kind of provide closure: I'm planning on doing this kind of thing only for the renderer, so I went with a clamp inside an #ifdef.  It may turn out that I can't confine floats to the renderer, in which case it looks like I'll have to do something like what ZDoom does, but we'll see.  Thanks again everyone.

You can always maintain a float for the renderer, and keep the integer var for the logic, insulating yourself from tiny accuracy bugs. This confines any slight math inaccuracies to the renderer, where no one will notice. This has the added benefit that you can avoid having to constantly cast back and forth.

2 people like this

Share this post


Link to post

So here's a question. What source ports provide consistent multiplayer support when someone compiles the same build on multiple CPU's, and which are more prone to desyncs when running different architectures?

Share this post


Link to post

I don't know if a lot of research has been done on this.  Odamex will run on ARM, like a Raspberry Pi, but you probably want to test on wired LAN so as to increase the likelihood that any desync you experience is because of architecture differences and not packet loss.  Chocolate Doom (I think also Crispy) is another candidate, but I don't think you'll have any float-based problems there.

 

I do know that if you goof with the compiler's float flags in Odamex you'll cause desyncs (fast-math; but I can't remember if it should be on or off... probably off), so that indicates vulnerability there, but it's not certain.

Share this post


Link to post

You can't use an asynchronous netcode to test mathematical desyncs in generic cases. Only Doom's original netcode (and demos, as the exact same concept is required) can be used. Thus, Odamex netplay is useless to test such a thing.

 

Safest answer is any port that offers demo compatibility and on multiple platforms usually is fine, but the thing is they are all vanilla compatible ports, so only fixed point math is available. Nobody uses ZDoom to even play back its own demos, and most people only use it on x86 anyway.

Edited by Edward850

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now