Max number of entities.
-
daemonicky
- Posts: 185
- Joined: Wed Apr 13, 2011 1:34 pm
Max number of entities.
I would like to make a level with up to 10 000 entites (I guess it is limit). What is limit in each quake engine on amount of entities?
limits are generally based upon a few different things...
nq engine hardcoded limit: 600
nq protocol limit: 32767 or 65535 (if unsigned is supported)
quakeworld engine/protocol limit: 512
FTE protocol: 2048 (entities beyond will be invisible)
DP5+ protocol: 32767 (15bit, the extra bit is a 'remove' flag)
The way I see it, most engines either have the original unmodified limit, have some small bump primarily to cover slightly larger maps within the confines of quake, or have fixed up the limits and now support the limit of their protocol.
I would not recommend ever exceeding 32k, because that's generally the protocol limit.
I would assume that engines that exceed a 1k limit are generally okay up until 32k, the exception to that is my own engine, which has the excuse that its protocol is based upon quakeworld's original 512 limit. I do not believe there are any engines that have an actual limit around 10k, that is, if you reach 10k you can get 3 times as many before it becomes a problem to any engine that supports 10k.
The higher you go, the more the engine has to do for various builtins like find/findradius, and other similar things. A client should give linear slowdowns based upon the number of ents currently visible, but a server might give exponential slowdowns.
In all cases, too many entities visible at once will result in unplayable framerates, and bloated, oversized network messages.
nq engine hardcoded limit: 600
nq protocol limit: 32767 or 65535 (if unsigned is supported)
quakeworld engine/protocol limit: 512
FTE protocol: 2048 (entities beyond will be invisible)
DP5+ protocol: 32767 (15bit, the extra bit is a 'remove' flag)
The way I see it, most engines either have the original unmodified limit, have some small bump primarily to cover slightly larger maps within the confines of quake, or have fixed up the limits and now support the limit of their protocol.
I would not recommend ever exceeding 32k, because that's generally the protocol limit.
I would assume that engines that exceed a 1k limit are generally okay up until 32k, the exception to that is my own engine, which has the excuse that its protocol is based upon quakeworld's original 512 limit. I do not believe there are any engines that have an actual limit around 10k, that is, if you reach 10k you can get 3 times as many before it becomes a problem to any engine that supports 10k.
The higher you go, the more the engine has to do for various builtins like find/findradius, and other similar things. A client should give linear slowdowns based upon the number of ents currently visible, but a server might give exponential slowdowns.
In all cases, too many entities visible at once will result in unplayable framerates, and bloated, oversized network messages.
If I recall correctly, over 2048 entities and the Quake map compiling tools that are most commonly used won't work without a recompile bumping the limits. Maybe I'm wrong.
A couple of maps in ARWOP are simply gigantic. And they only have like 300-400 monsters, although I bet they have an entity count nearing 1800 to 2000 after everything is said and done (guns, ammo, lifts, etc.)
Every non-static entity gets a "turn" in SV_Physics which does all the entity "thinking" every time the server runs a frame. You'd think that at some point that could become a bottleneck, but I guess all we have seen is "frames-per-second" bottlenecks on maps with 10,000 knights and such.
A couple of maps in ARWOP are simply gigantic. And they only have like 300-400 monsters, although I bet they have an entity count nearing 1800 to 2000 after everything is said and done (guns, ammo, lifts, etc.)
Every non-static entity gets a "turn" in SV_Physics which does all the entity "thinking" every time the server runs a frame. You'd think that at some point that could become a bottleneck, but I guess all we have seen is "frames-per-second" bottlenecks on maps with 10,000 knights and such.
The night is young. How else can I annoy the world before sunsrise? 
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..
Inquisitive minds want to know ! And if they don't -- well like that ever has stopped me before ..Thinking is a bottleneck, especially if the QC is more complex or makes heavier use of expensive builtins than normal (lots of tracelines, etc). That can quickly enough become your primary bottleneck in SP games or listen servers. In an MP/dedicated (or QW) setup it's not so relevant and so can be easily overlooked, but that doesn't mean that it's irrelevant for SP/listen.
Memory can quickly enough become an insane bottleneck. By default server-side entities are edict_t * and client-side are entity_t []. Just naively bump the maxes in the #defines and you may find yourself needing > 128 MB for entities alone. The job needs more serious work than that; server-side needs to go to edict_t ** (which needs some real pretty code in PR_ExecuteProgram and elsewhere to support it) and client-side needs to go to entity_t * [] (which is quite trivial).
The same applies to bumping maxes for other entity types (static, temp, etc). Hugely memory-intensive.
Memory can quickly enough become an insane bottleneck. By default server-side entities are edict_t * and client-side are entity_t []. Just naively bump the maxes in the #defines and you may find yourself needing > 128 MB for entities alone. The job needs more serious work than that; server-side needs to go to edict_t ** (which needs some real pretty code in PR_ExecuteProgram and elsewhere to support it) and client-side needs to go to entity_t * [] (which is quite trivial).
The same applies to bumping maxes for other entity types (static, temp, etc). Hugely memory-intensive.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
Warpspasm warpc starts with 1418 entities and 1623 edicts. Most of those entities list as "empty" at beginning of map, not sure what that means. More entities will be needed during gameplay. Guessing 2048 is enough for anything out there (except intentional limit test maps). What are the best existing released maps to use as a stress test?
How much memory does each reserved but unused entity slot consume in single player? I'm getting 320 bytes for entity_t and 523 bytes for edict_t structures. Numbers would vary depending on how modded a particular engine is (added variables in entity and edict).
Yeah, just because a MAX is set high in a #DEFINE doesn't mean the engine has been stress-tested at that value. Other defines, protocol limits, or memory limits could undercut a MAX.
How much memory does each reserved but unused entity slot consume in single player? I'm getting 320 bytes for entity_t and 523 bytes for edict_t structures. Numbers would vary depending on how modded a particular engine is (added variables in entity and edict).
Yeah, just because a MAX is set high in a #DEFINE doesn't mean the engine has been stress-tested at that value. Other defines, protocol limits, or memory limits could undercut a MAX.
Marcher Fortress, Masque of the Red Death, pretty much anything by Tronyn in his Drake-enhanced revival. As for demos (wasn't asked for here, but listing anyway), bigass1 is the classic benchmark demo, but also consider qdq_1949.qbism wrote:What are the best existing released maps to use as a stress test?
Actually, this has very little to do witht he progs.dat, and everything to do with the QuakeC, because additional fields can be created there. That said, it's still better to create additional fields if you need them. Yes, .button1 and .aflag abusers, I'm taling to you...How much memory does each reserved but unused entity slot consume in single player? I'm getting 320 bytes for entity_t and 523 bytes for edict_t structures. Numbers would vary depending on how modded a particular engine is (added variables in entity and edict).
Roaming status: Testing and documentation
Improve Quaddicted, send me a pull request: https://github.com/Quaddicted/quaddicted-data
Try this map in Darkplaces (it will bog down your system). I did not make this map. Someone remind me who did.
That's how many entities your map should have!
That's how many entities your map should have!
-
daemonicky
- Posts: 185
- Joined: Wed Apr 13, 2011 1:34 pm
Is there a reason for such small (256, 512) number of static entities ? I mean those which you spawn tied with a brush and you can set them alpha value (in glquake ...; for example make them dissapear).Yup, and a very good reason.
When Quake was originally released in 1996 it had to run on a p60 with 8MB of memory.
In GLQuake there is absolutely no reason whatsoever why static entities (and efrags) cannot be drawn down from hunk memory as required. That would bump the limit to effectively infinite - at least until you run out of memory.
In software Quake things are more difficult as efrags are also used for regular entities, so you'll need to come up with a dynamic allocation scheme for them. But you can do the same with static entities (alloc from hunk as required) so long as you're aware that each static entity also needs one or more efrags.
When Quake was originally released in 1996 it had to run on a p60 with 8MB of memory.
In GLQuake there is absolutely no reason whatsoever why static entities (and efrags) cannot be drawn down from hunk memory as required. That would bump the limit to effectively infinite - at least until you run out of memory.
In software Quake things are more difficult as efrags are also used for regular entities, so you'll need to come up with a dynamic allocation scheme for them. But you can do the same with static entities (alloc from hunk as required) so long as you're aware that each static entity also needs one or more efrags.
We had the power, we had the space, we had a sense of time and place
We knew the words, we knew the score, we knew what we were fighting for
We knew the words, we knew the score, we knew what we were fighting for
-
daemonicky
- Posts: 185
- Joined: Wed Apr 13, 2011 1:34 pm