Reducing level load time

#1 I belive the "Loading Objects" progress bar occurs when the Loaded Datablocks , are being sent from the server to the client.

#2 If you are making a single player game you can increase the following vars in your defaults.cs file:

$Pref::Net::PacketRateToClient = 32; //Rate controls for client/server communication; ranges of 1-32
$Pref::Net::PacketRateToServer = 32; //Rate controls for client/server communication; ranges of 8-32
$Pref::Net::PacketSize = 450; //Initial size in bytes of the comm buffer (may be enlarged if necessary); range 100-450.


I noticed a difference in datablock loading after doing this. Thank Rick for the info. He told me abotu this at the GDC.

#3 Thanks! I wonder what else can be changed to improve performance when making a singe player game...

Nick

#4 Is the packet size max absolute? No way to go over 450 bytes?

#5 Unless you make engine modifications. I havn't played with that.

Perhaps someone can shed some light?

#6 I believe I tried upping the packet size to 1024 bytes only to have 'odd' things happen (mission loading getting stuck at 'Loading Objects', etc.).

I never bothered to track down why as the speed increase was negligble.

#7 450 bytes is most likely a targetted packet size to avoid having network packets getting split up if passed through a very low MTU (550 rings a bell for the "lowest allowed MTU") internet node.

I think the technique was developed in the early 90's, where MTU was a very important aspect of latency (and may very well still be), and the "smart" internet game developers used the very small packet size to make sure their packets didn't get broken up and strung out over the connection.

I can't honestly say that increasing packet size would hurt you at this point, but it's not an arbitrary number someone came up with out of their head--it has some very slick design concepts behind it!

#8 If it's strictly single player I don't see how it could hurt - I mean, if you have serious latency to localhost you might want a new computer....

Rich

#9 I've done this. You can get it to load 2-3 times faster by bumping up the packet size and rate. It also fixes some latency issues for single player.

in sim/netConnection.cc change the function NetConnection::checkMaxRate() to look like this:
(new code is in bold)

void NetConnection::checkMaxRate()
{
   // Limit packet rate to server.
   if(gPacketRateToServer > 32)
      gPacketRateToServer = 32;
   if(gPacketRateToServer < 8)
      gPacketRateToServer = 8;

   // Limit packet rate to client.
   if(gPacketRateToClient > 32)
      gPacketRateToClient = 32;
   if(gPacketRateToClient < 1)
      gPacketRateToClient = 1;
   
   // Limit packet size.
   if(gPacketSize > 450)
      gPacketSize = 450;
   if(gPacketSize < 100)
      gPacketSize = 100;

	  
	 [b] //go faster in single player mode
	if (Con::getFloatVariable("$pref::HostMultiPlayer") == 0)
	{
		gPacketRateToClient = 128;
		gPacketRateToServer = 128;
		gPacketSize = 5000;
	}[/b]

   gPacketUpdateDelayToServer = 1024 / gPacketRateToServer;
   U32 toClientUpdateDelay = 1024 / gPacketRateToClient;

   if(mMaxRate.updateDelay != toClientUpdateDelay || mMaxRate.packetSize != gPacketSize)
   {
      mMaxRate.updateDelay = toClientUpdateDelay;
      mMaxRate.packetSize = gPacketSize;
      mMaxRate.changed = true;
   }
}

I arrived at those values purely by experimentation, if you go too high it crashes, if you go too low there are latency problems.

#10 Eric, can you submit a simple resource for this? Just so it doesn't get lost.

#11 You should probably be using getIntVariable there, or getBoolVariable (not 100% sure the latter exists, but I think it does).

If you absolutely have to have loading go faster, I'd suggest short circuiting the init phase so that it doesn't send any data at all.

#12 @Ben Garney: What do you mean by short circuit exactly? Where should I start looking?

I tried killing SimDataBlockEvent::pack() and SimDataBlockEvent::unpack() as an experiment and it did indeed make things go faster and most everything still worked. The only problem is that things arent getting preloaded, so things like particle textures and debris dont show up.

#13 Inside the function: ConsoleMethod( GameConnection, transmitDataBlocks, void, 3, 3, "(int sequence)")

change the last for loop to something like this:

U32 max = getMin(i + DataBlockQueueCount, groupCount);
if ( GameConnection::getLocalClientConnection() == object )
{
// if we're single player, just finish loading the data blocks...
char errorBuffer[256];
for (;i < max; i++)
{
SimDataBlock *data = (SimDataBlock *)(*g)[i];
data->preload( false, errorBuffer );
}
Con::executef(object, 2, "onDataBlocksDone", "1" );

} else
{
// Ship the rest off...
for (;i < max; i++)
{
SimDataBlock *data = (SimDataBlock *)(*g)[i];
object->postNetEvent(new SimDataBlockEvent(data, i, groupCount, object->getDataBlockSequence()));
}
}


this changed my load time from about 12 seconds to 3.

#14 Maybe it's already around... but I would like some explicit instructions on how to remove the networking code from stock TGE. That would really help out my single player game.

#15 @Ben - How about getting Cameron's shortcut for local client games into 1.4?

#16 This stuff rocks hard... I went from like a 20 second load to less than 3!!!!

-Josh Ritter
Prairie Games

#17 I think i spoke too soon... i'm having trouble with Cameron's code. In my TSE based project the load is super quick, but i get a black screen with the default cross reticule on the screen. Any ideas?

So far i've found that PlayGui::onWake() isn't being called... now trace back why this is.

#18 I also have some trouble with the above code in my TGE game, it looks like all is well at first, but then I have some problems with footstep decals, and animations.

#19 I think that just calling preload() on the datablock isn't enough. Looking at the datablocks they are missing some of the strings you would normally have on the client side. Seems like you need to do more there to make this work.

#20 @Eric, that's a Gem! Thanks. In a stupid test I ran on the Orc demo, those 4 lines of code made the mission load 40% faster!!