Improving Map Performance

I've been experimenting with larger maps with more enemies and am curious as to which factors most affect the FPS in a given section of the map and what to cut down on if I wish to improve performance. Specifically in ZDoom-based GL ports which tend to chug before GLBoom+.

I have a windows XP PC that generally runs doom pretty well on software mode. In my experience, the frame rates only trend to chug in places with excessive middle texture usage (stuff like Valiant and Bloody Steel's fences, hanging vines, and individual blades of grass) and having too many active monsters at once. 2,000 idle monsters is okay, 2,000 moving, chasing monsters makes the frame rate chunky.

Do active monsters outside the map, say in teleport hallways, have the same effect or only visible, projectile chucking ones? i.e. Shooting at the start of the map wakes up 1k enemies that are later progressively teleported at different parts of the map.

All active monsters affect performance negatively - each of them calls A_Chase every 2 or 3 tics, and A_Chase is a considerably time-demanding function, especially if the monsters are stuffed in a small space where they bump into walls and each other often (so that active monsters walking in place inside teleport hallways can easily cost much more performance than ones freely roaming the map and attacking the player). Having thousands of active monsters at a time is definitely very bad for performance. You should seek ways to only activate them just before they're going to actually fight the player.

If the map has a REJECT table, and the monsters are within a dummy sector outside the map that isn't itself joined with the map (that is, the sector with monsters merely neighbors with another dummy sector that is joined with the map, but which the monsters can't physically enter), then the REJECT table can save some performance by immediately rejecting the possibility of clean line of sight between the monsters and the player - this applies to passive monsters as well, who usually call A_Look to check line of sight every 10 tics, which itself costs some performance, too.

40oz said:

I have a windows XP PC that generally runs doom pretty well on software mode. In my experience, the frame rates only trend to chug in places with excessive middle texture usage (stuff like Valiant and Bloody Steel's fences, hanging vines, and individual blades of grass)...

Some ports (like PrBoom) have an optimization for completely solid midtextures. Otherwise, midtextures (and sprites) are considered 'overdraw', which means that the same pixels are drawn over more than once per-frame, which is very detrimental to performance. Things like blade of grass textures are deceptive, cause there's some overhead involved in drawing a thing or midtexture, so when it's small, it becomes expensive, for what you get, performace vs. sizewise (though it can look very nice!) Any slowdown of this kind should disappear when looking away, though.

scifista42 said:

(good advice)

Yes, running monsters impact performance a lot, whether they are currently visible or not. Collision detection is fairly expensive, for example. As for the REJECT table, it is least effective in Doom v1.2 or below, Heretic (and maybe Hexen), slightly more effective in ZDoom, and most effective with Doom > v1.2, due to the line-of-sight algorithms used. But it is effective for most all maps, directly related to the number of monsters idle, monsters seeking targets, and monsters throwing missiles in the map. There is absolutely no performance penalty from having a fully-built REJECT map (except the amount of time to build it), and there's almost always some benefit. For thousand-monster-maps, the difference can be dramatic.

Other slowdowns include:
* The number of differing floors/ceilings visible at once, to include different brightness, height, or image (visplanes).

* The number of things visible at once, especially if they are laying on top of each other (corpses, ammo piles).

* Advanced port constructs, like 3d floors, mirrors, cameras, slopes, portals, polyobjects, splats, and others.

* Translucent (not transparent) walls, floors (3d floors), and things.

* Runtime scripting, especially when not written to be optimal in performance.

* The number and size of plats moving, especially if there are things standing/walking/laying on the plat floor. (This one is rarely accused, but can be huge - Check out Doom II, map 30: after 30 minutes of IDDQD, drop the wide platforms, and check performance, when there's tons of monsters.)