फिक्स्ड3डी, बॉक्स3डी का एक निश्चित बिंदु रूपांतरण (box2d.org)(github.com)
github.com
Fixed3D, a fixed point conversion of Box3D (box2d.org)
https://github.com/mas-bandwidth/fixed3d/blob/main/README.md
4 comments
Unfortunately, despite the warnings and mostly-generated code, having deterministic(?) 3D rigid-body physics is kinda cool and I'm a little tempted to use this - is the joke that fixed-point actually isn't necessary for cross-platform deterministic lockstep, or that Box3D's maintainer would be upset at someone doing specifically this ("please have Claude make a new fixed-point version of Box3D?")
Erin and I have had a long running debate for the past year about fixed point vs. floating point for Box3D, especially around very large worlds like the space game I'm working on (https://spacegame.dev) which uses Box3D.
Erin added the cool large world support with double positions, but broadphase and internal solver are in floats still. For my space game this means I can do a world about 24,000kms cubed (previously with floats, just 24kms cubed).
Arguably this is enough, and Box3D with floats + double positions enabled is within 3% of single precision float performance in CPU cost.
So it's PROBABLY not the case that the fixed point implementation has any real benefit, unless 24,000kms cubed is not big enough. It's probably going to land slower than 3% vs. the single precision float implementation.
So this is simultaneously an honest exploration of what would happen if we go fixed point, but also a joke between Erin and I (in good spirits, we are friends) to see how far we can push the fixed point performance :)
Personally, I believe that fixed point is going to land slower than float, but we'll see what the AI comes up with over the next day.
ps. Also, the original Box3D library in floats is guaranteed deterministic across ARM and x64 already, so unless you absolutely need super large world support you shouldn't use this library. :)
cheers
- Glenn
Erin added the cool large world support with double positions, but broadphase and internal solver are in floats still. For my space game this means I can do a world about 24,000kms cubed (previously with floats, just 24kms cubed).
Arguably this is enough, and Box3D with floats + double positions enabled is within 3% of single precision float performance in CPU cost.
So it's PROBABLY not the case that the fixed point implementation has any real benefit, unless 24,000kms cubed is not big enough. It's probably going to land slower than 3% vs. the single precision float implementation.
So this is simultaneously an honest exploration of what would happen if we go fixed point, but also a joke between Erin and I (in good spirits, we are friends) to see how far we can push the fixed point performance :)
Personally, I believe that fixed point is going to land slower than float, but we'll see what the AI comes up with over the next day.
ps. Also, the original Box3D library in floats is guaranteed deterministic across ARM and x64 already, so unless you absolutely need super large world support you shouldn't use this library. :)
cheers
- Glenn
Oh, good to hear it was just good-natured teasing :)
I did kind of expect the loss of SIMD to make it paradoxically slower than the floating point version, I am curious what kind of equivalent integer/fixed-point tricks exist!
> Also, the original Box3D library in floats is guaranteed deterministic across ARM and x64 already
Oh, that rocks!
I did kind of expect the loss of SIMD to make it paradoxically slower than the floating point version, I am curious what kind of equivalent integer/fixed-point tricks exist!
> Also, the original Box3D library in floats is guaranteed deterministic across ARM and x64 already
Oh, that rocks!
Yeah Erin did awesome work. This part is huge! Also check out #define BOX3D_DOUBLE_PRECISION 1 -- it's really good