Level loading time is added onto game start time (up to 0.1 seconds) about joequake HOT 23 CLOSED

Did this work differently in the vanilla Win/GLQuake?
This is from the original source code:

but was playing it in a debug build, which pushed the load time over 0.1 seconds

So does this only occur in a debug build?

from joequake.

So does this only occur in a debug build?

It doesn't only occur in debug mode, it's just that I happened to see it when switching between debug and release since debug mode put me over the 0.1 second boundary and release slightly under, on the fmb_bdg2 map (large enough that it takes approx 0.1 seconds to load on a modern machine).

Did this work differently in the vanilla Win/GLQuake?

I just tested this with quakegeneric which is the closest thing to original source I can get that builds easily. It does in fact have a similar effect, although slightly different. The behaviour is the same for load times less than 0.1 seconds --- in these cases the start time is delayed by the same amount as the load time. For load times greater than 0.1 second, the original source delays the start by 0.1 seconds, whereas JQ eliminates the delay so you're technically at an advantage in JQ if you have a slower load.

Having said this, since a very similar feature is present in the original source, I guess we don't care too much about it?

from joequake.

FWIW I just tried with cl_independentphysics 0 and it behaves identically to quakegeneric (delays by 0.1 seconds for a load time > 0.1 second)

from joequake.

Our check tool flagged your fmb2_113 demo for the start time.

I've seen the same "firsttime" happen on a couple hipnotic demos, but didn't think much of it at the time since it wouldn't of given them another second.

from joequake.

Yeah this definately needs to be addressed.

from joequake.

It would be good if you can check it works on windows. Putting a 0.2 second sleep in SV_SpawnServer, recording a 100m demo, then running the check tool should be enough to confirm it

from joequake.

I also see it just recording a demo on ad_sepulcher without any modification, since that takes > 0.1 seconds to load in any case.

from joequake.

Can confirm it happens on Windows too. Tried with a 0.2 seconds sleep as you suggested.

from joequake.

I am pretty sure the issue centres around this code in _Host_Frame and what happens on the frame after the level load:

extraphysframetime += host_frametime;
if (extraphysframetime < physframetime)
{
        physframe = false;
}
else
{
        physframe = true;
        extraphysframetime -= physframetime;
}

In the long load time case, we hit the first case and SV_Physics is not run. The next time SV_Physics is run it is with a 1./72 frame time.

In the short load time case, we hit the second case and SV_Physics is run. It is run with a frame time of however long the level load frame took.

The first time recorded in the demo corresponds with the time after this run of SV_Physics, and so is 1.3 + 1/72 = 1.313888 for long loads, and larger otherwise.

from joequake.

As long as the load is longer than 1/72 s, both host_frametime and physframetime will be set on the frame after the load. If the load frame was < 0.1 seconds, they'll both be have the same value: the length of the load frame. If the load time is greater than 0.1 seconds, host_frametime will be clamped to 0.1, and will be less than physframetime. Assuming extraphysframetime is small, this means we fall in the second case if the load time is < 0.1s, and the first case otherwise.

from joequake.

Great findings, thanks Matt!

from joequake.

Now that I actually had some time to understand what's going on, I came up with this (easiest?) fix:

minphysframetime = MinPhysFrameTime();
if (cls.capturedemo || cls.timedemo || realtime - oldphysrealtime >= minphysframetime)
{
	physframetime = realtime - oldphysrealtime;
	oldphysrealtime = realtime;

	// joe: never allow physframetime to go above 0.1
	// this guarantees that after a longer map load (> 0.1s), a physical server frame is executed immediately
	physframetime = min(physframetime, 0.1);
}

So if we clamp physframetime at max 0.1, just as we do with host_frametime, the condition
if (extraphysframetime < physframetime)
wouldn't be true and therefore we could force out the proper physical frame to be performed.
I believe there isn't any danger with this, as with normal circumstances the server can never run smaller than 10 fps (0.1 frametime) anyways.
Tested on many long-loading AD maps, none of them resulted the early 1.318888 start time with the fix.

@matthewearl, what do you think?

from joequake.

I think that addresses the issue as described in my post, but I'm still seeing the 1.31888 initial time with a different setup, and slightly intermittently:

1. Set cl_maxfps 500 (exact value probably not important).
2. Bind record 100m 100m to something.
3. Hit the bind.

Most of the time I end up with the 1.31888 initial time start time. If you use my load-delay-repro repro branch you can see the issue occurs without having to check the demo: Just hit the bind until the line thinking 1.327778 appears on the console, then stop, check the demo, and it should have an initial time of 1.31888. Make sure you have sv_loaddelay 0.

This seems to occur when Host_FilterTime updates host_frametime but does not update physframetime, which is likely to happen since host_frametime ticks at 500 fps, and physframetime ticks at 72fps. As long as the level load time falls somewhere between 1/500 seconds and 1/72 seconds this can happen.

When host_frametime is updated, it is updated to whatever the level load time is, however, physframetime remains at 0.1: the value which was set in SV_SpawnServer. In this case the if (extraphysframetime < physframetime) check will pass and we won't run a physics frame.

If you can repro this too that'd be good to know, just in case I've made a mistake.

from joequake.

When host_frametime is updated, it is updated to whatever the level load time is, however, physframetime remains at 0.1

As far I see host_frametime is always clamped to 0.1

And exactly the opposite, physframetime was that could go beyond 0.1 due to the bug. With the fix it remains at 0.1 max.
I tried to reproduce it with the steps you described, but now the start times are always 1.3999999 to me.

from joequake.

Do you have a delay in SV_SpawnServer? For the new issue I'm seeing there should be no delay

from joequake.

Ok, I could reproduce it with a release build, not with a previously built debug build.
This experience popped the idea out of my head that it's simply that fast with today's computers. So I started my good old GLQuake.exe (v0.96) and repeated the steps. Guess what? Yeah, you guessed right.

@Flecked42 I'm gonna update the SDA validator tool to warn only demos with start times below 1.31x (in the current version the threshold is 1.32x).

from joequake.

Are both of those recorded with the old glquake exe? Seems weird you're getting times less than 1.31888

from joequake.

Yes, both. No, I don't think it is weird.

• sv.time starts from 1.0 sec
• 3 physics frame runs before serverinfo (3 x 0.1 sec)
• 1st frametime at 72 fps is 0.0138888888

The summed up minimal time is: 1.3138888888

from joequake.

Fixed in commit 8130554
Thanks for the help @matthewearl

from joequake.

Oh, my mistake, I forgot what 1./72 was 😅. Yeah what GLQuake is doing makes perfect sense. But still, there seems to be a difference with JQ in that it's possible to get an initial time of exactly 1.3+1/72=1.3138888, whereas with GLQuake I don't think that is possible?

from joequake.

Well I haven't tested thoroughly. I believe it should be possible with GLQuake too, at least when I implemented independent physics, I payed very high attention to not break anything but keep the server side fps calculation 100% accurate.

from joequake.

Just recorded this with original GLQuake:

from joequake.

You're right, thanks for indulging me :)

from joequake.