gerbilOFdoom Posted January 25, 2015 Posted January 25, 2015 Just a curiosity here... There is an entity limit of 1024-2. Now, I know OpenJK will not raise this limit for compatibility reasons but would there be any technical issues in doing so independently?
Didz Posted January 25, 2015 Posted January 25, 2015 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.
ensiform Posted January 26, 2015 Posted January 26, 2015 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...
Raz0r Posted January 26, 2015 Posted January 26, 2015 Yes, but MP has 32 reserved client slots. (1024-2) + 31 = 1053 Didz likes this
gerbilOFdoom Posted January 26, 2015 Author Posted January 26, 2015 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?
Didz Posted January 26, 2015 Posted January 26, 2015 No one can predict how much the impact of doubling the entity limit can be. It's something that would just require experimentation. Archangel35757 likes this
Raz0r Posted January 27, 2015 Posted January 27, 2015 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.
Futuza Posted January 27, 2015 Posted January 27, 2015 You should do something crazy and increase it to 20,000 and tell us what the performance is like.
eezstreet Posted January 27, 2015 Posted January 27, 2015 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.
gerbilOFdoom Posted January 27, 2015 Author Posted January 27, 2015 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.
Didz Posted January 27, 2015 Posted January 27, 2015 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. Futuza and gerbilOFdoom like this
Xycaleth Posted January 27, 2015 Posted January 27, 2015 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 Just need some sucker one to add it in... Archangel35757, gerbilOFdoom, Futuza and 1 other like this
Xycaleth Posted January 27, 2015 Posted January 27, 2015 @@Scooper #PlzScooper gerbilOFdoom likes this
gerbilOFdoom Posted January 27, 2015 Author Posted January 27, 2015 @@Xycaleth, ... you got that wrong, sir. @@Scooper #ScooperPlz Xycaleth, Stoiss and Tempust85 like this
Scooper Posted January 29, 2015 Posted January 29, 2015 I'm busy making mmo's for a living here! What on EARTH could I POSSIBLY know about loading times and optimizing many entities network traffic. =p
eezstreet Posted January 30, 2015 Posted January 30, 2015 er, nothing, nothing at allthese guys have it all wrong although give the guy some credit, dis dood literally helped me send a second playerstate and entitystate in JKG before the source code was even released. scooper is genius Futuza and Stoiss like this
Futuza Posted January 30, 2015 Posted January 30, 2015 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 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...
Stoiss Posted January 30, 2015 Posted January 30, 2015 Boba did make a load screen where it show the % of data it was loading, but not all the weapons if i remember right, it loaded them in categories of each weapons types i think
Xycaleth Posted January 30, 2015 Posted January 30, 2015 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.
Futuza Posted January 31, 2015 Posted January 31, 2015 No, Boba only made it show a loading bar. Didz was talking about loading stuff in the background while you're playing the game.Oh right. I just reread what he wrote, didn't read it very carefully.
Recommended Posts
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 accountSign in
Already have an account? Sign in here.
Sign In Now