Jump to content

Entities


gerbilOFdoom

Recommended Posts

The main issue is just likely to be reduced performance and increased network traffic consumption.

 

Here's a comment left in the source code by rww (Richard Whiteouse) explaining why he didn't increase the limit to 2048:

//rww - we do have enough room to send over 2048 ents now. However, I cannot live with the guilt of
//actually increasing the entity limit to 2048 (as it would slow down countless things, and
//there are tons of ent list traversals all over the place).

rww had also planned to increase the limit to 1053 entities in this same section of code (to ensure MP could load SP maps that were close to the limit), but he commented all that change out for some reason.

Link to comment

The main issue is just likely to be reduced performance and increased network traffic consumption.

 

Here's a comment left in the source code by rww (Richard Whiteouse) explaining why he didn't increase the limit to 2048:

//rww - we do have enough room to send over 2048 ents now. However, I cannot live with the guilt of
//actually increasing the entity limit to 2048 (as it would slow down countless things, and
//there are tons of ent list traversals all over the place).

rww had also planned to increase the limit to 1053 entities in this same section of code (to ensure MP could load SP maps that were close to the limit), but he commented all that change out for some reason.

Uhh... SP has a max of 1024 entities too...

Link to comment

So, JK was built in a day before modern processing power/internet bandwidth. How terribly would performance be reduced by doubling or tripling the entity count? Is the performance reduction linear?

Technically, not linear. Each entity has to access each other entity multiple times per frame. Depending on what they're accessing it for (collision etc) it could be quite an exponential performance hit.

This is usually a minimal issue if the entity/player slot is not in use.

Link to comment

Yes, but MP has 32 reserved client slots. (1024-2) + 31 = 1053

+bodyque

+lightsabers

+NPCs (if any)

 

So, JK was built in a day before modern processing power/internet bandwidth. How terribly would performance be reduced by doubling or tripling the entity count? Is the performance reduction linear?

It depends on the logical operations being performed. Suppose you have 10000 entities that have no thinking functions and are just static. The netcode wouldn't take a hit, because the game only sends information when something in the world is being altered. The server processor on the other hand would take a bigger load as you now have to iterate through 10000 entities every frame, and sv_fps determines how many frames per second is being done...so in other words, you'd have 10000 * sv_fps entites being processed on the server per second. Understand the g_entities is a static chunk of memory that can't be reallocated, and even if you don't have 10000 entities on the map, you still need to loop through all 10000 entities and make sure that they're either valid or invalid for later processing.

 

And yes, as Raz0r said, entities can affect other entities. In theory if you have just 10000 entities that are static, the performance would be (most likely) linear. If you have more complex entities, the performance is either quadratic or exponential, depending on the entity type. Bots and NPCs drain the highest amount of performance, since AI is quite CPU-intensive.

Link to comment

Even if performance is quadratic the improvement in CPU power over 10 years ago should help cover the processing cost of increasing the entity limit. 

 

The question is: would multithreading be a viable solution to improving the performance of an increased entity limit? I would imagine that object locking could cause some hitches in processing while one thread waits to modify an entity that is being modified by another thread.

Link to comment

The entire architecture of the game code was built for a single thread of execution. It would be a massive undertaking and a monumental waste of time (imo) trying to retrofit multi-threading/parallelism into the Q3 engine to try to squeeze out more performance for the increase in entities. You'd need to do detailed profiling comparisons on the code (with original entity limit, and with increased entity limit) before thinking of taking this on. If you can't pin-point the critical sections of bad performance, there's no hope of trying to parallelise it.

 

Off-the-topic of more entities, but on-topic on performance: One very noticable source of bad performance in the game is synchronous file loading where the game pauses for several frames in order to load files in (like when players change their models). This could be fixed by loading in files asynchronously, and you don't even need to implement multi-threading to do this (the system will let you know when the file has been read). Many of these can be set off in parallel and you can carry on running the game while files are being loaded in the background if the file is not critical to the gameplay.

gerbilOFdoom and Futuza like this
Link to comment

Off-the-topic of more entities, but on-topic on performance: One very noticable source of bad performance in the game is synchronous file loading where the game pauses for several frames in order to load files in (like when players change their models). This could be fixed by loading in files asynchronously, and you don't even need to implement multi-threading to do this (the system will let you know when the file has been read). Many of these can be set off in parallel and you can carry on running the game while files are being loaded in the background if the file is not critical to the gameplay.

And it could be done entirely in the renderer. No changes to the client game would need to be made which makes this a very appealing change :D Just need some sucker one to add it in...

Link to comment

Off-the-topic of more entities, but on-topic on performance: One very noticable source of bad performance in the game is synchronous file loading where the game pauses for several frames in order to load files in (like when players change their models). This could be fixed by loading in files asynchronously, and you don't even need to implement multi-threading to do this (the system will let you know when the file has been read). Many of these can be set off in parallel and you can carry on running the game while files are being loaded in the background if the file is not critical to the gameplay.

 

And it could be done entirely in the renderer. No changes to the client game would need to be made which makes this a very appealing change :D Just need some sucker one to add it in...

 

Didn't Boba Fett do this with JKG at one point?  I seem to remember at one point it had a nice loading screen where it gave you details all the way through each file being loaded...

JKG Developer

Link to comment

Didn't Boba Fett do this with JKG at one point?  I seem to remember at one point it had a nice loading screen where it gave you details all the way through each file being loaded...

No, Boba only made it show a loading bar. Didz was talking about loading stuff in the background while you're playing the game.

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...