Built-in Fixed Update

[DarkMara]

What problem does this solve or what need does it fill?

As most people know, a fixed timestep is important for making gameplay consistent and repeatable. It's currently possible to do it in Bevy by adding a stage with a fixed timestep, but a built-in stage could make things more streamlined and have some extra features to have the stage behave as expected.

What solution would you like?

There should be a built-in stage that runs after Update called FixedUpdate. The special thing about a built-in FixedUpdate is that it should run commands after every loop. So each run of FixedUpdate would be treated as its own stage. Currently, in a Fixed Timestep, at least the way I understand it, there is no way of knowing when the commands will be processed, since you don't know how many times it will run per frame.

I also think the fixed timestep information should be added to the Time resource, so it can easily be accessed from any system without using the string key that FixedTimesteps currently uses.

What alternative(s) have you considered?

I am not sure how to get commands to run after every run of a fixed timestep currently.

Additional context

It seems like the new change detection in #1471 will solve the issue of detecting changes during a fixed timestep, but I don't think there is a way to have events work seamlessly with a fixed timestep and with other stages together. If a built-in fixed update is added, maybe that could also be addressed.

A built-in fixed update would also make it easier to implement interpolation, as proposed in #1259.

Edit: Apparently commands are already run after every update of a fixed timestep.

[alice-i-cecile]

Related to #1343. Probably obviated by #1613.

[TheRawMeatball]

FYI, Commands already run after every iteration of a system set with a FixedTimestep run criteria.

[DarkMara]

FYI, Commands already run after every iteration of a system set with a FixedTimestep run criteria.

Ok, I did not know that. It could be a good idea to explain that in the fixed_timestep example.

I guess the only problem still remaining (after the new change detection is implemented) is events, but there is a workaround for that if you don't update them every frame.

[alice-i-cecile]

I'm hoping to get an RFC together for "reliable events" using exactly the same strategy as we do for change detection. Should be landing shortly after 0.5 launches and should solve the remaining difficulties.

[tigregalis]

I like the idea of shipping FixedUpdate "out of the box", e.g. as a (default) plugin - this plugin can be opted out of as required, but I think it's a sensible default.

Rendering the interpolated state could be done automatically: User game logic gets added to the fixed update schedule ordinarily, where for example it updates the Transform. Within the fixed update schedule, at the start of it, you have a system that copies and stores last game tick's Transform (as e.g. PreviousTransform). Just before rendering, you lerp/slerp the current PreviousTransform to current Transform with the overstep percentage. (This would mean adding a PreviousTransform component to each of the relevant bundles, and now you have all of PreviousTransform, Transform, GlobalTransform as a minimum for every "positioned" entity).

[alice-i-cecile]

Closing this out; this is tackled nicely in the stageless design. bevyengine/rfcs#45