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

[sapphonie]

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

[KyleSanderson]

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]

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]

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]

Why close? This is a valid PR and orthogonal to the other one. I think this idea should be entertained for simplicity at least...On Jul 10, 2023 6:14 PM, Kyle Sanderson ***@***.***> wrote: Closed #2014. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> On Jul 10, 2023 6:14 PM, Kyle Sanderson ***@***.***> wrote: Closed #2014. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***> On Jul 10, 2023 6:14 PM, Kyle Sanderson ***@***.***> wrote: Closed #2014. —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[sapphonie]

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]

E.g. something like

...
        // RunFrame();

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

[dvander]

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]

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]

dammit, accidentally force pushed over that work

[Headline]

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.