Designing with performance in mind

[fiend-o-hell]

Designing with performance in mind with the kind of computer we have today can be thrown out the window completely if you stick to making maps that conform to a classic doom paradigm layout. But with the advent of the limit removing port and the types of maps I have been designing lately, I'm starting to question weather I should trim off a couple of sectors here or simply a structure there in a superstitious kind of way.

I had a very specific questions, but before I post them, I would also like to continue this thread further and learn more about what I should be doing to optimize my editing techniques.

So to start things off:

1.what degrades performance more? sector count or sector size? How do lines and vertices play a roll?

2.What is the difference -in terms of system resources - between using a software renderer and OpenGL? Are their different kinds of each? Should I be worried about how they are implemented in each port?

[ReX]

fiend-o-hell said:

1.what degrades performance more? sector count or sector size?

Sector count (but see reference to linedef, below). If you had a single massive sector it would load up very fast. If you broke up that sector into multiple, smaller sectors, it would require the computer to do more calculations to render the player's view, "degrading performance".

How do lines and vertices play a roll?

Lines actually play more of a role in computer performance than sectors. If you had a single sector with many angles and faces, it may take longer for the computer to "process" than if you had several sectors with fewer lines.

Vertices only exist in the context of lines, and so the answer above applies to vertices as well.

The bottom line, actually, is how many surfaces are visible to the player at any given time. You can create maps with a great deal of lines, but if you can cleverly arrange the map so that only a small portion of the multitude of lines is visible to the player at any given time, you can reduce some performance lag.

Also, proper node building speeds up the loading and playing of large and complex maps.

[EarthQuake]

Although ReX's suggestions are recommended, I have some doubts about whether sector counts directly contribute to rendering times... Sectors are normally broken up into convex subsectors (SSECTORS), even a sector that spans across several isolated areas across the map. These subsectors are referenced in the BSP tree (NODES), and the engine has to run through this tree to figure out what needs to be rendered to the screen. The same goes for linedefs; they are split into line segments (SEGS). As for vertexes though, they play a negligent role. They just glue SEGS together (the nodebuilder will actually add vertexes where a linedef is split into two SEGS).

That's the purpose of the BSP tree, to make rendering the game more efficient. So it's not really the sector and linedef counts that matter... it's more about the constituent parts of them that are generated by the nodesbuilder. A good nodebuilder, especially one with optimizations for making a less complex BSP tree, can dramatically increase the speed of rendering a each scene in the map. Pretty much all nodebuilders will have custom parameters that determine where and how often a split will occur. It can be worth it to play around with such options if you're pushing the map format.

In this age though... software rendering in Doom is a pretty trivial thing for a processor to do, so I doubt you really need to worry too much about this kind of stuff. I haven't played a Doom map that has slowed down my computer in quite some time.

[printz]

What about Nuts.wad style maps? There, it's the number of chasing actors that slows down the game. Kill them all (or don't be seen), and it becomes fast again.

[fiend-o-hell]

I'll admit that I start to nod off anytime I start reading to deeply into the technicalities of doom's node builder. ReX's explanation really helps put things into perspective.

EarthQuake said:

Pretty much all nodebuilders will have custom parameters that determine where and how often a split will occur. It can be worth it to play around with such options if you're pushing the map format.

Now that's something I have never considered before; playing around with node builder perimeter's. A while back I switched over to ZDBSP from ZenNode solely on the reason that it fixed random see-through texture bugs that otherwise wouldn't go away. Ha, I think I'll read up on exactly what the differences are between the two.

printz said:

What about Nuts.wad style maps? There, it's the number of chasing actors that slows down the game. Kill them all (or don't be seen), and it becomes fast again.

Ah! Which brings us to how doom processes monster AI behavior.

Obviously, handling active monsters is a more system intensive process than handling inactive monsters. I figure optimizing on this front would require one to take advantage of this fact as much as possible if a large monster count is involved. Of course, if your using a port with scripting capabilities, than you just spawn the precise amount of enemies you want at any time.

I'm curious:
3.There a large amount of enemies on the map (like in nutz.wad). Will the game chug no matter where you are on the map(out of view or not)?

[ReX]

fiend-o-hell said:

Of course, if your using a port with scripting capabilities, than you just spawn the precise amount of enemies you want at any time.

There are also features in ports that will allow you to suppress resource-demanding features when they are not visible to the player. As an example, let's say you have plenty of special effects such as sparks, bubbles, (particle) water-falls, rain, snow, etc. They can be set up so that they only activate when the player is in the line of sight, rather than being constantly active and draining system resources.

I'm curious:
3.There a large amount of enemies on the map (like in nutz.wad). Will the game chug no matter where you are on the map(out of view or not)?

As printz indicated, while the enemies are not in sight and not active, the game will not slow down appreciably. However, as soon as the enemies become active, the computer has to individually calculate each enemy's path as it tried to approach/attack the player. These myriad calculations are what slow down the system.

[tempun]

ReX said:

As printz indicated, while the enemies are not in sight and not active, the game will not slow down appreciably.

Not in my experience. For me, there's sometimes virtually no difference between wakened and not wakened monsters, but kill monsters cheat helps.

[printz]

Do A_Look and REJECT tables matter in ultra-modern maps with all sorts of slowdown? Or are today's computers impossibly fast to be surpassed by anything doable in advanced Doom ports?

Does ZDoom take into account the REJECT table in the WAD when saving performance for A_Look?

[Gez]

tempun said:

Not in my experience. For me, there's sometimes virtually no difference between wakened and not wakened monsters, but kill monsters cheat helps.

Depends on the port and how it handles AI routine. I can run around nuts.wad on ZDoom with the notarget cheat perfectly fine. However, once the monsters are active, it's an unplayable slideshow.

On the other hand, PrBoom+ handles it like a champ. I don't feel any difference in performances between active monsters and inactive monsters on that map.

[fiend-o-hell]

Gez said:

On the other hand, PrBoom+ handles it like a champ. I don't feel any difference in performances between active monsters and inactive monsters on that map.

: 0> How is that possible? I just tried it too and it ran without a hitch. What is PrBoom+ doing differently than all the other ports!?!

[tempun]

fiend-o-hell said:

: 0> How is that possible? I just tried it too and it ran without a hitch. What is PrBoom+ doing differently than all the other ports!?!

Uses less memory actively, I guess.

[RjY]

Instead of trying to abstract out every possible facet of game behaviour into a class hierarchy for maximum flexibility, PrBoom+ (and all engines it is descended from) just have everything hard-coded directly into the executable. As one wag on some website I was reading put it: "All problems in computer science can be solved by another level of indirection except performance"

[DaniJ]

So very true. Often the best solution is a hybrid approach which implements a class hierarchy for logical manipulations of objects, from which a "lean and mean" representation is then distilled (upon change) for performance.

Its more work but this approach often has intrinsic benefits (e.g., no blurring of the lines between the model and view).

[fiend-o-hell]

I think source code manipulation is out of the question for most mappers out there (including myself) and it does little good to hyper-abstract the issue at hand. The fact is, most ports can only handle so many lines on screen and calculate so many monster AI routines at any point in time. My intent here is to circumvent bottlenecks on a wide ranging assortment of platforms as practically as possible.

I wanted to bring things back around to rendering methods. As I understand it, a software renderer is handled entirely by the CPU while graphic's API's such as OpenGL and DirectX rely heavily on video cards.

I am wondering which renderer people like to play their vanilla maps with and why.

The majority of the time I use software rendering on medium resolutions, default port settings. For me, its more about preserving doom's gritty, pixeleted look. It also just seems faster to me. Is it my imagination at play here? I know the fps count says otherwise, but to hell with it.