Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fixed Point support #13

Closed
wants to merge 4 commits into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 0 additions & 1 deletion rfcs/DELETEME.md

This file was deleted.

50 changes: 50 additions & 0 deletions rfcs/fixed_point.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,50 @@
# Feature Name: Fixed Point Support

## Summary

There should be the ability in bevy to have the option to switch all of the transforms and basic shapes and whatnot to use fixed point. Ideally, it would allow for the user to pick what fixed point version they want to use (22 by 10, 52 by 14, etc), but a standard fixed point number type is fine too.

## Motivation

No other engine I can think of has fixed point support, and yet it is extremely useful for networking purposes, due to the fact that fixed points produce the same results on different architectures. Most people who work in networking and need determinism for their games often have to resort to either building their own fixed point libraries, or using third parties libraries that often times aren't very good. Additionally, trying to integrate a fixed point game system into an existing engine often results in the developer having to put in as much effort as building their own engine anyways.

## Guide-level explanation

Fixed point would fundamentally just require replacing all of the transforms and primitive data types (floats) with fixed points.

- There are two ways to do fixed point - a standard value, and the ability to choose your fixed point type.
- The standard value is the easiest way to go about this, but this would sacrifice flexibility.
- Being able to pick the type of fixed point you want would be a bit harder, but much more flexible.

## Reference-level explanation

* Fixed point numbers are split into two halves
* The upper (for example 22 by 10, the upper would be 22) is the amount of bits that represents the whole number portion of a fixed number
* The lower (22 by 10, lower would be 10) is the amount of bits that represents the fractional portion of a fixed number
* You have to make sure that the amount of bits that make up the upper and lower when added up is a multiple of 32, so that it could fit as a 32bit, 64 bit, or (possibly) a 128 bit fixed point number

## Drawbacks

* It is a lot of work to do this, but since bevy is so young, I don't think it would be as big of a mission as adding it to something as mature as Godot.
* There's also the issue of fixed point numbers being substantially slower than floats.

## Rationale and alternatives

- The reason for fixed point numbers over something like floats is that there is the issue of floating point rounding errors, which can accumulate overtime and can lead to desyncs in networked games, which prevents cross platform gaming.
- Of course, you could do the process of restricting floats to the same architecture, but that would result in a limitation of the potential audience you could reach with your game, and that also has the potential of breaking anyways.
- The reason why we should do this is because no other engine has done this, because its such a specific feature to networking (deterministic lockstep and the like)
- But Bevy is an ECS engine, a organization structure expressly made for networking, and so it makes sense to have a networking focused feature like fixed point numbers in the engine.

## \[Optional\] Prior art

I have done a [sample project](https://github.com/ValorZard/FixedPhysics.rs) testing out existing fixed point systems in rust and they seem to work fine.

## Unresolved questions

- How exactly would we go about adding the option to have fixed point to everything? Would it be a build feature, or a crate?
- Could we integrate this into a possible bevy_physics crate when that comes around?

## Future Plans

* What fixed point should result in is essentially something like Godot's KinematicBody. Most games that use fixed point system (fighting games, RTS) don't really require a complex physics system , or just rebuild their own physics anyways. What fixed point really cares about is collision. Sometime like Godot's KinematicBody, which provides a collider and the ability to code your own physics, is perfect for this type of implementation.
* One of the main reasons for pushing this is the ability to implement something like [fighting game rollback netcode](https://ki.infil.net/w02-netcode.html) into Bevy at some point.
73 changes: 0 additions & 73 deletions template.md

This file was deleted.