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

Tick timers every tick instead of arbitrarily on 100ms thinks, adding a significantly higher amount of precision #2014

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

sapphonie
Copy link
Contributor

Lightly tested, no significant impact on performance I can see, though it should probably be tested a bit more heavily...

@KyleSanderson
Copy link
Member

The wait is in there because there were issues with timers running over eachother (0.0 into a 0.0 into a 0.0... etc). At least this is my memory of the issue when I proposed the same thing many years ago.

@sapphonie
Copy link
Contributor Author

The wait is in there because there were issues with timers running over eachother (0.0 into a 0.0 into a 0.0... etc). At least this is my memory of the issue when I proposed the same thing many years ago.

If this is the case, it should be as simple as setting the think time to the tick interval?

@KyleSanderson
Copy link
Member

Please consider keeping things like this in the same issue if they're directly related to one another. I'm closing this in favour of #2009 where the discussion should continue around this if desired.

@dvander
Copy link
Member

dvander commented Jul 11, 2023 via email

@sapphonie
Copy link
Contributor Author

sapphonie commented Jul 11, 2023

The wait is in there because there were issues with timers running over eachother (0.0 into a 0.0 into a 0.0... etc). At least this is my memory of the issue when I proposed the same thing many years ago.

Do you know of an easy way to make a test case for this? I'm not sure what you mean, do you mean multiple timers running at 0.0? One single timer running at 0.0 executing infinitely? Or wha? I think regardless these could be easily solved by just explicitly limiting timers to <tickinterval> which is probably what users expect anyway

@sapphonie
Copy link
Contributor Author

sapphonie commented Jul 11, 2023

E.g. something like

...
        // RunFrame();

	if (g_fUniversalTime >= g_fTimerThink)
	{
		RunFrame();
		g_fTimerThink = CalcNextThink(g_fTimerThink, gpGlobals->interval_per_tick);
	}
...

Copy link
Member

@dvander dvander left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems fine to me, timers have lots of idiosyncracies but it's not like this can't be reverted if something blows up somewhere.

I think a timer with an interval of 0.0 firing constantly would only be a problem if there were ticks happening < interval_per_tick.

@KyleSanderson
Copy link
Member

The wait is in there because there were issues with timers running over eachother (0.0 into a 0.0 into a 0.0... etc). At least this is my memory of the issue when I proposed the same thing many years ago.

Do you know of an easy way to make a test case for this? I'm not sure what you mean, do you mean multiple timers running at 0.0? One single timer running at 0.0 executing infinitely? Or wha? I think regardless these could be easily solved by just explicitly limiting timers to which is probably what users expect anyway

CreateTimer, in that callback, create another timer, and keep doing that. It may have been from when time was a float as opposed to a double, but do they run properly?

@sapphonie
Copy link
Contributor Author

sapphonie commented Jul 26, 2023

dammit, accidentally force pushed over that work

@sapphonie sapphonie reopened this Jul 26, 2023
@Headline
Copy link
Member

Headline commented Aug 4, 2023

Documenting some discussion that happened on Discord:

What worries me here is that previous reliance on timer behavior definitely will cause breakage. Adding a timer flag, something along the lines of TIMER_FLAG_TICK_PRECISE, will expand functionality here for higher precision timers without breaking bcompat behavior-wise.

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