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

[MAINTENANCE] Stepping #1735

Closed
AndreaCatania opened this issue Jun 19, 2019 · 6 comments
Closed

[MAINTENANCE] Stepping #1735

AndreaCatania opened this issue Jun 19, 2019 · 6 comments

Comments

@AndreaCatania
Copy link
Contributor

@AndreaCatania AndreaCatania commented Jun 19, 2019

Description

While looking at the stepping function, I've noticed that we don't have a fail safe algorithm for the fixed update stepping.
This mean that if we run amethyst and a process takes too much to process something the fixed update is called multiple times due to the large time step which again will increase the time step of next frame which mean again more fixed update calls and so on in an infinite loop.

A good thing would be have a fail safe algorithm that limit the fixed updates to something like 8.

However if the fail safe algorithm exist, worth mention it anyway, but I would like to see it so I will appreciate if you tell me where I can find it.

@jaynus

This comment has been minimized.

Copy link
Contributor

@jaynus jaynus commented Jun 19, 2019

This is by design. If your fixed update is taking too long, then you are inherently breaking the design of your game. A fixed update is not inherently a guarantee that an update will run every X seconds - it is a guarantee that the a simulation will be ran at every N interval.

This means that even if your simulation runs slower, or faster, you will always get a simulation step at N interval. This is also why we use accumulators instead of strictly time comparisons. An accumulator allows us to run N simulation steps for every X time, regardless of actual run time.

If your simulation is inherently way too slow for such a operation, then your design is inherently flawed and you should reconsider your execution and/or step interval. I do not believe it is in the best interest of the engine to soften the blow for these situations, as that will then soften guarantees and may cause issues down the line with other simulations.

More reading: http://web.archive.org/web/20190403012130/https://gafferongames.com/post/fix_your_timestep/

@AndreaCatania

This comment has been minimized.

Copy link
Contributor Author

@AndreaCatania AndreaCatania commented Jun 20, 2019

This is not what I mean, probably my explanation is not enough detailed so let me enrich it.
But let's assume that we are working with integers rather than floats to make my life easier :)


We have the following execution process:

  • Normal process that takes 1 second
  • Fixed process that take 1 second per each execution. The fixed time is set at 1 second

The first step we have a scenario where the actual DT is 0 so only the Normal process is executed:
1 + Normal process
= 1 Second Execution time

The second step we have the DT to 1 so:
1 + Normal process
1 + Fixed process
= 2 Second Execution time

The result is that the DT of the next frame is 2 so:
1 + Normal process
1 + Fixed process
1 + Fixed process
= 3 Second Execution time

The result again is that the DT of the next frame is 3 so:
1 + Normal process
1 + Fixed process
1 + Fixed process
1 + Fixed process
= 4 Second Execution time

The result again again is that the DT of the next frame is 4 so:
1 + Normal process
1 + Fixed process
1 + Fixed process
1 + Fixed process
1 + Fixed process
= 5 Second Execution time

And so on....

As you can see without a fallback algorithm that stop it the performances of your application keep degrading because the fixed algorithm is executed over and over again in the same frame.

Usually in real life this kind of scenario happens when you have a bigger DT due from model loading, or window switching. So a single big DT may execute many fixed process triggering the above scenario where you are forced to shutdown your game and reopen it.

@stale

This comment has been minimized.

Copy link

@stale stale bot commented Aug 19, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Feel free to comment if this ticket is still relevant.

@stale stale bot added the stale label Aug 19, 2019
@jojolepro

This comment has been minimized.

Copy link
Member

@jojolepro jojolepro commented Aug 19, 2019

not stale

@stale stale bot removed the stale label Aug 19, 2019
@stale

This comment has been minimized.

Copy link

@stale stale bot commented Oct 18, 2019

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Feel free to comment if this ticket is still relevant.

@stale stale bot added the stale label Oct 18, 2019
@distransient

This comment has been minimized.

Copy link
Member

@distransient distransient commented Oct 19, 2019

Since this is going stale anyways, closing this for now in lieu of this forum post where we may discuss this issue as well as others with our clock API's.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.