Search In
• More options...
Find results that contain...
Find results in...

# Theoretical # of monsters possible

## Recommended Posts

I was doing some math today, and I think I figured out the theoretical # of monsters you could smash into a level, provided doombuilder and your computer don't spit at you for trying. Anyway, a lost soul takes up 32 x 32 grid square and the total grid area is 65535 x 65535, so then the # of monsters possible in a map that big would be (65535^2)/(32^2) = 4,194,176 monsters. Am I correct any math whiz's out there?

You'll have to leave space for the player, otherwise there's no point. Also you could consider monsters stuck on each other or ports without infinitely tall monsters, where you can put monsters on top of each other.

Oh true, so then all that -4 then.

E: I mean if all the monsters can move freely.

There are more subtle limits though. The number of THINGS to place on the map (including items) is determined at runtime by looking at the length of the THINGS lump while loading a level, and dividing that length by 10 (that's the size of normal Doom mapthings). Therefore, even if you didn't have map size or movement freedom limits, there would be other limits having to with how large structures can get on-disk and in-RAM.

For mapthings, that could grow to quite respectable numbers indeed. Assuming that you can allocate 2 GB of RAM tops on a 32-bit OS, that would mean that you can have just short of 200 million monsters. That is, assuming that the OS you're using could also handle such large files without crapping out, and without taking data structure alignment or overhead issues into account. On a 64-bit OS, perversely, you'd waste up to 6 bytes for each map object (8-byte boundary alignment), so accessing more RAM wouldn't bring immediately benefits.

If you generated those monsters or things in memory though, that obviously wouldn't be a problem. However acting monsters and projectyles would also need to be allocated "map object" structures, and these are at least 152 bytes long, plus they need to be allocated and deallocated dynamically all the time. This puts a much harder limit on how many you could have. Still in the range of 10-12 millions for a 2 GB addressable space.

TL; DR: there's no hardcoded inherent limit on the number of things or monsters, only practical ones dictated by the OS, source port and filesystem you are using.

There are however much harder limits on map complexity, number of vertices, sectors, etc. unless extended formats come into play.

Hmm. Interesting. So what about 8 GB of RAM on a 64 bit OS?

DoomHero85 said:

the total grid area is 65535 x 65535

Your level has to be smaller than that however, because the largest distance between any two things on the map has to be less than 32767 map units. And that means you have to take into account not the dimensions of the sides, but also the dimensions of the diagonals. This isn't a limitation of the map format itself but of the engine.

On the other hand, you can use ZDoom and fill the third dimension with stacks upon stacks of lost souls (cacos are too large for this exercise). You'll have to use UDMF or the Hexen format since the Doom map format does not let you give a Z-height value to things.

heh.

If someone made a Lost Soul Cube I would play it.

DoomHero85 said:

Hmm. Interesting. So what about 8 GB of RAM on a 64 bit OS?

Assuming that you get a round 8000000000 of memory to play with (after we took out all other OS overhead etc.), then the top limit for filling this memory with just map objects (thinking monsters) would be 50.000.000 (160 bytes per object, due to data alignment).

Of course, at this point the source port itself would have to be modified to allow 64-bit pointers too, so the weight per object would likely go up quite a bit, considering that a significant portion of its size is pointers to other objects, so that would decrease this number further. Otherwise, you'd be limited to memory allocations within 4 GB (on a 32-bit OS and hardware combination that doesn't suffer from the PC-AT 3 GB barrier, which probably boils down to Intel based Macs or exotic older SUN machines or Itanium 32 servers).

Maes said:

(on a 32-bit OS and hardware combination that doesn't suffer from the PC-AT 3 GB barrier, which probably boils down to Intel based Macs or exotic older SUN machines or Itanium 32 servers).

pentium 4 + windows server OS works pretty well with PAE. it never caught on in desktop land because drivers need to be modified to work with it, and you know how hardware vendors are...

I was once able to get a level with over 200 thousand monsters to run. It was a HUGE box map with zombies in it. It ran extremely slowly however (in Zdoom anyways) and sometimes the level would not even run.

I did not test it with Prboom though which I hear can render levels with lots of monster better much better.

Hmm if you still have it around somewhere could you put it up for downloading? I'd like to do some benchmarks ;-)

A room with 66007 cacos - http://www.mediafire.com/?kf7382x9elnbter
Doom Builder crashes when I try to add more.

Maes said:

Hmm if you still have it around somewhere could you put it up for downloading? I'd like to do some benchmarks ;-)

Nope, but for fun I am going to see how many monsters I can add into a level without it crashing. If I get enough monsters into the room without the editor crashing like I did last time I will post the file here.

EDIT: I was able to create a similar map again though the editor did crash a number of times.

Here it is:

It has over 140 thousand zombies. Good luck getting a smooth framerate.

Here is a editor screenshot:

hardcore_gamer said:

This should be the new benchmark for gaming hardware. I was literally getting zero frames per second and I never even got to flip the switch to see what happened.

Marnetmar said:

This should be the new benchmark for gaming hardware. I was literally getting zero frames per second and I never even got to flip the switch to see what happened.

lol.

For me the framerate is actually ok until you flip the switch causing the floor to lower, but after that the framerate drops massively and after a while the game crashed. I was using prboom by the way.

It should be interesting to see if anyone on the forums actually has the monster rig required to run this thing.

hardcore_gamer said:

lol.

For me the framerate is actually ok until you flip the switch causing the floor to lower, but after that the framerate drops massively and after a while the game crashed. I was using prboom by the way.

It should be interesting to see if anyone on the forums actually has the monster rig required to run this thing.

You must have a monster rig yourself. Would you mind if I asked what your specs were?

Thanks, hardcore_gamer.

Marnetmar said:

You must have a monster rig yourself. Would you mind if I asked what your specs were?

CPU:AMD Phenom(tm) II X2 550
CPU SPEED: 3.1 GHz Performance Rated at: 5.89 GHz
RAM: 5GB
GPU: GeForce 8800 GT

This information was obtained via systemrequirementslab.com

hardcore_gamer said:

CPU:AMD Phenom(tm) II X2 550
CPU SPEED: 3.1 GHz Performance Rated at: 5.89 GHz
RAM: 5GB
GPU: GeForce 8800 GT

This information was obtained via systemrequirementslab.com

Huh, my machine's quite a bit more powerful (not to brag) and I don't get decent frame rates at all.

Marnetmar said:

Huh, my machine's quite a bit more powerful (not to brag) and I don't get decent frame rates at all.

What port are you using?

I hear prboom runs much smoother. Also note that I did not claim to have a good framerate once the monsters react to you, but merely a so so framerate before the switch is pressed.

I got it to run okay. I flipped the switch and went up, then a lot of the zombies on the other side woke up and the framerate dropped, but once most of the guys they shot died, it went back to good again. So I went to the other side of the map, same thing happened, framerate drop followed by a return. Then I just sat there and watched the numbers change for awhile til i got bored around 40000 dead and quit.

My specs are
AMD Phenom II Black 965 X4
6GB RAM,
Geforce 9600 GT 512MB
Using Prboom+ 2.5.1.2

Gonna get another stick of Ram so i can have 8 GB soon and uprgrade my video card soon too, probably within the next two months.

EE runs the zombieman wad on my Core 2 Quad at about 3.5 seconds per frame, even looking at the automap. Thinker processing is dominating execution time even just for dead corpses and bullet clips >_>

I originally went with 1024x1024 sectors because DB2 doesn't seem to like huge sectors, but after some point got bored. I didn't get crashes up until the end where I started getting out of memory errors (though it allowed me to keep moving stuff, but as the error message popped up 3 times out of 4 I stopped there).

Haven't tried to load it up yet, one earlier version with 1/3 as much monsters already took minutes to load for me.

I get maybe 3-4 fps with Mocha Doom when everything is activated, and then maybe 10 or so when enough baddies have died. Seeing how extreme this is, I'd say it's overall acceptable. It also prompted me to remove the intercepts overflow limit, which is always a welcome stimulus ;-)

P.S. LOL saving and loading a game actually worked. Size of savegame: 43 MB ;-)

Quasar said:

Thinker processing is dominating execution time even just for dead corpses and bullet clips >_>

Yeah, for me it really helps to use whacked and replace decorations with monsters and give the replacements the lost soul death frame, or another frame that disappears.

Quasar said:

Thinker processing is dominating execution time even just for dead corpses and bullet clips >_>

Can't that be optimized?

Or worked around by making the corpses disappear (dehacked patch) like in other games?

Marnetmar said:

Huh, my machine's quite a bit more powerful (not to brag) and I don't get decent frame rates at all.

Remember that Doom is mostly singlethreaded, so if you have more cores than him, it doesn't really matter.

printz said:

Can't that be optimized?

Or worked around by making the corpses disappear (dehacked patch) like in other games?

Even when a monster dies it's never removed from the thinkers list (with the exception of Lost Souls and any monster/projectile that ends up with a S_NULL frame), since it retains its P_MobjThinker codepointer and continues "thinking" even after its dead. Even "dumb" stuff like clips and decorations that are spawned via P_SpawnMobj get it invariably.

There's no other place where even "dumb and dead" object reside, and even inert objects will at least get a movement and position checks when their turn to "think" comes. There's no way to skip that unless you assign a special "no thinking" codepointer which does NOT result in removal from the map (unlike the NOP codepointer), OR maintaining a parallel list of "non thinker" map objects which is not trasversed during thinking (however, it should be during rendering).

Unfortunately, the solution is not as simple as assigning dead objects a "do not think" type of codepointer. This may work for inert decorations with no animation frames (because you need the P_MobjThinker codepointer to animate them), but for dead monsters that leave a corpse it's a bit trickier: they must still "think" during their death sequence, otherwise they simply freeze in place. Such a "do not think" codepointer should only be applied AFTER they finally are laid to rest, and would have to be different than the "NOP" codepointer used to remove stuff from the list. There would still be some overhead when their turn to "think" would come up, since they'd be still linked to the thinkers list, but must less severe than calling P_MobjFunction without reason.

Exploding projectiles and objects which eventually fall back to the S_NULL state are special because after their "death" they are assigned a special "NOP" codepointer which triggers their removal from the thinkers list and even reclaims their memory back. The same thing happens during level restarts/changes, where all of the older mobj_t's are destroyed.

Any "general" fix that would reduce processing for all corpses or for inerts such as pickup items will break compatibility, both for demos and for DeHackEd patches, which can cause such effects as walking/attacking corpses and pickup items that move or explode, etc.

DeHackEd and the ability to create custom actors (ex: through EDF) are a thorn in the side of doing any sort of optimization of thinker processing ;) Every object has to be treated in the most general way possible in order to allow every possible combination of effects on any type of object :>