diff --git a/rfcs/DELETEME.md b/rfcs/DELETEME.md deleted file mode 100644 index 2b210d2f..00000000 --- a/rfcs/DELETEME.md +++ /dev/null @@ -1 +0,0 @@ -Dummy file for git, please delete once the first RFC is merged. diff --git a/rfcs/fixed_point.md b/rfcs/fixed_point.md new file mode 100644 index 00000000..27b16a38 --- /dev/null +++ b/rfcs/fixed_point.md @@ -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. \ No newline at end of file diff --git a/template.md b/template.md deleted file mode 100644 index 8e7bc765..00000000 --- a/template.md +++ /dev/null @@ -1,73 +0,0 @@ -# Feature Name: (fill me in with a unique ident, `my_awesome_feature`) - -## Summary - -One paragraph explanation of the feature. - -## Motivation - -Why are we doing this? What use cases does it support? - -## Guide-level explanation - -Explain the proposal as if it was already included in the engine and you were teaching it to another Bevy user. That generally means: - -- Introducing new named concepts. -- Explaining the feature, ideally through simple examples of solutions to concrete problems. -- Explaining how Bevy users should *think* about the feature, and how it should impact the way they use Bevy. It should explain the impact as concretely as possible. -- If applicable, provide sample error messages, deprecation warnings, or migration guidance. -- If applicable, explain how this feature compares to similar existing features, and in what situations the user would use each one. - -## Reference-level explanation - -This is the technical portion of the RFC. Explain the design in sufficient detail that: - -- Its interaction with other features is clear. -- It is reasonably clear how the feature would be implemented. -- Corner cases are dissected by example. - -The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work. - -## Drawbacks - -Why should we *not* do this? - -## Rationale and alternatives - -- Why is this design the best in the space of possible designs? -- What other designs have been considered and what is the rationale for not choosing them? -- What is the impact of not doing this? -- Why is this important to implement as a feature of Bevy itself, rather than an ecosystem crate? - -## \[Optional\] Prior art - -Discuss prior art, both the good and the bad, in relation to this proposal. -This can include: - -- Does this feature exist in other libraries and what experiences have their community had? -- Papers: Are there any published papers or great posts that discuss this? - -This section is intended to encourage you as an author to think about the lessons from other tools and provide readers of your RFC with a fuller picture. - -Note that while precedent set by other engines is some motivation, it does not on its own motivate an RFC. - -## Unresolved questions - -- What parts of the design do you expect to resolve through the RFC process before this gets merged? -- What parts of the design do you expect to resolve through the implementation of this feature before the feature PR is merged? -- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC? - -## \[Optional\] Future possibilities - -Think about what the natural extension and evolution of your proposal would -be and how it would affect Bevy as a whole in a holistic way. -Try to use this section as a tool to more fully consider other possible -interactions with the engine in your proposal. - -This is also a good place to "dump ideas", if they are out of scope for the -RFC you are writing but otherwise related. - -Note that having something written down in the future-possibilities section -is not a reason to accept the current or a future RFC; such notes should be -in the section on motivation or rationale in this or subsequent RFCs. -If a feature or change has no direct value on its own, expand your RFC to include the first valuable feature that would build on it.