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

Clamp delta time in debugger, or other ways to control delta_time #1543

Conversation

cspotcode
Copy link
Collaborator

@cspotcode cspotcode commented Feb 18, 2023

There are a few different cases where it might be helpful to clamp or control delta_time.

Debugger

When pausing in the debugger, the next frame's delta_time will be massive. Makes sense, if you pause the debugger for a minute, then the delta is 60s.
But engines like Unity clamp delta time for this reason. When you pause and then resume the game in Unity, it will not generate a massive delta_time.
Should we add something like that to arcade?

It could be as simple as my_window.set_max_delta_time(1/30) or set_fixed_delta_time or maybe there's something more auto-magic that would allow detecting when the debugger has paused? if sys.gettrace() is not None

AI

I can't speak to this one, but people want to use arcade for AI simulation or visualization. In these cases, I think the simulation and render loop should run in fast-forward, as fast as the CPU can handle. We can update docs to explain how to do this easily. Maybe we explain how to set a fixed delta_time but for arcade to tick as fast as possible, no sleeping.

@gran4
Copy link
Contributor

gran4 commented May 23, 2024

Maybe the AI section could be a separate issue?

@pushfoo
Copy link
Member

pushfoo commented May 23, 2024

TL;DR: The root issue is still the same: customizing frame / event loops

@FengchiW Since you mentioned being interested in dealing with #1137, i'm tagging you here.

But engines like Unity clamp delta time for this reason. When you pause and then resume the game in Unity, it will not generate a massive delta_time.

Arcade (and pyglet) having poor delineations between system time and game time contexts have hurt us before. One example is a crash when debugging under PulseAudio (#1900) due to an issue with upstream (pyglet/pyglet#952).

What I know at the moment:

  • @DragonMoffon started on some experimental clock-related work over in arcade/experimental/clock, but it's in a very rough state.
  • There's some capacity for custom event loops in pyglet which I haven't had time to fully investigate yet

@DragonMoffon
Copy link
Collaborator

We have the new Clock API now, i will just add the ability to set a clamp on the clock's delta_time

that way, it needs to check only once for debug and can be changed at run time (in response to a lag spike, for example)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants