Game loading delay

[duzenko]

I noticed that when the map loading GUI is shown nothing is being actually loaded for a second or so. It affects quick loads too.

Can we please get rid of the loop since it's useless in TDM.

• It's really annoying to wait each run when testing code changes.
• I think everyone will appreciate one less second of loading.

Here's the patch

 

 

Index: framework/Session.cpp
===================================================================
--- framework/Session.cpp    (revision 6635)
+++ framework/Session.cpp    (working copy)
@@ -437,9 +437,9 @@
 
     // introduced in D3XP code. don't think it actually fixes anything, but doesn't hurt either
     // Try and prevent the while loop from being skipped over (long hitch on the main thread?)
-    int stop = Sys_Milliseconds() + 1000;
+    /*int stop = Sys_Milliseconds() + 1000;
     int force = 10;
-    while ( Sys_Milliseconds() < stop || force-- > 0 ) {
+    while ( Sys_Milliseconds() < stop || force-- > 0 )*/ {
         com_frameTime = com_ticNumber * USERCMD_MSEC;
         session->Frame();
         session->UpdateScreen( false );

 

Edited October 22, 2016 by duzenko

[grayman]

I noticed that when the map loading GUI is shown nothing is being actually loaded for a second or so. It affects quick loads too.

Could you be more specific?

 

At what point is "nothing is being actually loaded"?

 

Is this when the loading bar is starting?

 

Or during the loading bar working its way from 0 to 100%?

 

Or after the loading bar is at 100%, but before control is handed to the player?

[New Horizon]

Nice!

[grayman]

Serpentine removed "most" of the d3xp code back in January 2012, but left this bit of code in ShowLoadingGui() in place.

 

If he's still reachable, I'd be interested in his reasons for leaving it.

 

The code prior to his edits was:

 

void idSessionLocal::ShowLoadingGui() {
	if ( com_ticNumber == 0 ) {
		return;
	}
	console->Close();

	// introduced in D3XP code. don't think it actually fixes anything, but doesn't hurt either
#if 1
	// Try and prevent the while loop from being skipped over (long hitch on the main thread?)
	int stop = Sys_Milliseconds() + 1000;
	int force = 10;
	while ( Sys_Milliseconds() < stop || force-- > 0 ) {
		com_frameTime = com_ticNumber * USERCMD_MSEC;
		session->Frame();
		session->UpdateScreen( false );
	}
#else
	int stop = com_ticNumber + 1000.0f / USERCMD_MSEC * 1.0f;
	while ( com_ticNumber < stop ) {
		com_frameTime = com_ticNumber * USERCMD_MSEC;
		session->Frame();
		session->UpdateScreen( false );
	}
#endif
}

[duzenko]

Could you be more specific?

I assume you have noticed the diff patch and don't need me to answer that.

[grayman]

Of course I've seen the patch.

 

But I'm interested in the point at which the player notices the difference, should we apply the patch.

 

You're the first one to notice, so I'm seeking information.

[duzenko]

Umm...

Sorry, are you saying that since nobody complained then it's ok or what???

I thought that everybody wants loading times as short as possible, not padded with artificial delays - but you sound like I want too much here???

Maybe I should create a poll or something to see if anyone else wants faster map loading and how much delay would be "unnoticeable" for average player.

Heck, maybe increase delay to 10 seconds and see if anybody notices.

Edited October 22, 2016 by duzenko

[grayman]

Cool yer jets.

 

We have a 5s wait at the end of map loading so mappers can paint tips on their loading screen should they want to. I don't think this applies to loading savegames, but I doubt it, because most savegame loading happens in less than 5s).

 

My interest in gathering as much info as I can helps me better understand how the delay you want to remove relates to the 5s delay. Nothing more, nothing less. Does it change the delay to 4s, thus affecting tip painting?

 

Had you answered, "This delay occurs at the start of loading" or "this delay happens at the 50% mark", then I'd be less concerned about the above.

 

Since you don't have specific info to clarify this for me, I'll investigate the effect of the patch and be back l8r.

[New Horizon]

Grayman is asking for information. That's kind of what we do around here. lol. He's our lead coder, so it's to be expected that a question might arise.

[Anderson]

 

Sorry, are you saying that since nobody complained then it's ok or what???

 

No, he's asking only for information on questions pointed earlier in post #2.

[grayman]

It appears that this is a reasonable change. Testing shows it knocks a second off the loading process, just prior to the loading bar starting its climb from 0->100%. (It doesn't make the loading bar go faster, if that's what folks are thinking.)

 

So it won't affect the 5s delay at the end for displaying tips.

 

From reading the code, it looks like the load screen is painted, and then given 1s to settle down (start any initial animations?) before starting the load process and painting of the loading bar. I'm guessing that's what this extra second was intended to do.

 

But since I don't think we have any load screens that care about that 1s spin-up time (they're static), it looks like it's okay for us to take the 1s out.

 

I'll make a bugtracker issue for it and commit the code change.

 

Thank you!

[duzenko]

Thanks.

I apologize for any misunderstanding.

[grayman]

np.

 

Thanks for contributing.