Comments URL: https://news.ycombinator.com/item?id=49057292

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49041863

Points: 2

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=49010098

Points: 3

# Comments: 0

Comments URL: https://news.ycombinator.com/item?id=48962724

Points: 15

# Comments: 2

Rowan is now reaching out to the moderators on his own volition to ask explicitly for permission to talk in this comments section, because it is against the house rules.

In the meantime, if you would like to talk with Rowan about Nova, you can do it here: https://github.com/mas-bandwidth/nova/discussions/4

Comments URL: https://news.ycombinator.com/item?id=48920057

Points: 3

# Comments: 1

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

Comments URL: https://news.ycombinator.com/item?id=48880997

Points: 4

# Comments: 4

It's sitting in your chair. Or is it?

https://box2d.org/posts/2024/08/determinism/

Physics engines like Box3D have a significant amount of internal state and caching, like contact caching, and other things to speed things up.

I've talked to Erin a lot about stuff like: "Hey, what if I want to do an FPS or a vehicle, but I want to roll back only the character or vehicle, like in an FPS?"

From these discussions (and many other inputs I'm sure) Erin has had a big think about determinism, and come up with his own determinism and replay stuff.

In the article he uses the term "rollback determinism" to mean you'd be able to synchronize (or at least invalidate) any of this caching so that it doesn't affect the way the simulation replays if you were to rollback the simulation fully and then change the state only for a few objects.

For example, if you were to rewind and replay a physics simulation just for say the player predicted object like a vehicle and any objects that it happens to touch, expanding these objects out recursively as they touch other things.

Or if you were to do rollback on the player controller like we normally do in FPS, and the player started predicting a physically simulated door they push into, and then any other object the door pushes and so on, this sort of thing.

This should not affect you if you only step the physics simulation ahead with inputs, and do the GGPO thing where you copy fork, and step that sim ahead with predicted inputs, throw away, copy fork and predict again... that's already deterministic today.

cheers

Comments URL: https://news.ycombinator.com/item?id=48760266

Points: 1

# Comments: 0