3D performance. Which port?

Maes said:

Even glboom+/prboom+ can go VERY slow on nuts.wad if you have MBF's "help friend" option on.

It was a bug and it is fixed for complevel 11 (MBF). I can't fix it for other complevels (>11) because of compatibility purposes.

This line was missed in prboom:

Revision: 3459
Author: entryway
Date: 1:20:20, 15 квітня 2010 р.
Message:
Fixed the latest known incompatibility (MBF)

PrBoom does not freeze with "help_monsters 1" as a bonus.
----
Modified : /branches/prboom-plus-24/prboom2/src/p_inter.c

+ // killough 8/29/98: remove from threaded list
+ P_UpdateThinker(&target->thinker);

Thank you for your answers. I fortunately managed to have gzdoom working acceptably well on my GeForce GT 220 doing two things:
1)Deleting some useless sectors (floor height==ceiling height), so breaking the line of sight
2)Disabling the "Resize textures" options (nothing changed on the rendering quality, this is strange)

My error was to expect from gzdoom a performance like that of modern 3D game engines; but as you've pointed out thare are limitations inherited from the original doom.

John

entryway said:

glboom-plus:
http://prboom-plus.sf.net/glboom_nuts_vtune.png

gzdoom:
http://prboom-plus.sf.net/gzdoom_nuts_vtune.png

FBlockThingsIterator::Next
http://prboom-plus.sf.net/gzdoom_nuts_vtune_01.png
http://prboom-plus.sf.net/gzdoom_nuts_vtune_02.png

Thanks for that info. Unfortunately the thing that's at work here was a necessary attempt of making certain functions reentrant. Doom's original 'validcount' check is causing problems with ZDoom's blockmap code.

So essentially, due to the high monster density in this map the performance hit is stronger both due to more time consuming checks and actors being linked to more than one block.

DaniJ said:

Short answer: Not easily because you cannot predict the outcome.

Long answer:
In DOOM, pretty much all line special logic is designed such that effects are dependent upon the current world state at the time the special is executed. For example, one special may lower a floor in one sector and consequently any door specials that use a relative height offset will have a different outcome than if the door is opened before the floor is lowered.

This behavior means that it is not possible to pre-simulate.

However, it would be possible to re-run the logic after each world geometry change. The problem is that some maps are so dynamic that this process would likely cause even more performance problems than simply assuming all geometry can change at any time.

Dependent mostly on state of neighboring sectors. If sector has no tagged neighbors, then its height probably won't change.(stairbuilder special is an exception, but it's not used often).

'Probably' is not really good enough when it comes to hardware rendering. In addition, in ZDoom this is a lot more blurred and there's many more means to move a sector. Not to mention flat/wall scrollers, light level changes etc., etc. All of this directly modifies the level geometry data.

Add to that that floor height changes may alter the number and the order of vertices a wall polygon uses and the whole thing degenerates into a hopeless mess that's close to impossible to sort out - at least not without prohibitive overhead. It's just faster to redo it each time than to check and recheck and then either copy some cached data or recalculate anyway.

tempun said:

Dependent mostly on state of neighboring sectors. If sector has no tagged neighbors, then its height probably won't change.(stairbuilder special is an exception, but it's not used often).

I'd imagine most ports have the ability to reference a sector by number as well as by tag.

You can also reference sectors by using the front or back sector of a linedef with a tag or a special... Doors are an obvious example, but they're not alone.

Graf Zahl said:

What's your hardware specs?

I get 67 fps on that scene with GZDoom and 72 fps with GLBoom+ on a Geforce 9600GT, 1280x1024 on a first generation 2.4 GHz Core Quad.

Anyway, looks like Risen3D is quite good performance wise.
I get 19 fps with EDGE and 9 fps with Doomsday 1.8.6 on that scene (all enhanced features switched off.)

It's quite embarrassing to say actually, but here goes ...

AMD Athlon 2800+, NVidia 6600GT, 1GB RAM. XP pro.

Yes, I know, a dinosaur by todays standards ...

Anyway, using your comparitive testing, what results did you get using Risen3D in basic Doom mode ?

From my favorite vantage point on the steeple I get 42 fps (latest download as available today)

So it seems that although the engine still comfortably rests in third place, it doesn't scale as well with faster hardware than GZDoom and GlBoom+.

tempun said:

Dependent mostly on state of neighboring sectors. If sector has no tagged neighbors, then its height probably won't change.(stairbuilder special is an exception, but it's not used often).

I've never tested in ports, but in vanilla a tag of zero is quite valid, and thus a switch with a tag of zero can cause the entire map to rearrange itself with hilarious results.

Tag 0 sectors don't seem to bother ZDoom. They do horrible things to vanilla DOOM, though, and PrBoom doesn't seem to fare much better.

That would be because only ZDoom (and derivatives) changed the behaviour of how tag 0 is interpreted compared to Vanilla Doom; in ZDoom a trigger with a tag of 0 only affects the sector on the backside of the trigger.

It was in hindsight probably a poor decision of ZDoom to change this behaviour. But there is nothing stopping other ports supporting it as the odds of an old vanilla wad using tag 0 for something are, probably, zero.

That would at least minimize the issues caused by ZDoom's changing the behaviour (i.e. such maps obviously still won't work in Vanilla Doom itself).

If you're going to apportion blame for the mess caused by the tag 0 map shattering business, then I'd nominate Doom Builder, which actively encouraged this to be used, and didn't flag it as an error in non-Zdoom-specific maps. After DB became the most popular editor, the number of wads released with this problem increased enormously.

...not to mention that Doom Builder ascribed MBF features to Boom...

Vermil said:

It was in hindsight probably a poor decision of ZDoom to change this behaviour. But there is nothing stopping other ports supporting it as the odds of an old vanilla wad using tag 0 for something are, probably, zero.

Actually, it was more or less an oversight in how Doom format linedefs are translated to Hexen format, rather than an intentional change.

The tag 0 behavior as used by ZDoom is how Hexen deals with it - and for Hexen format maps this is necessary.

The problem occured because the linedef translation table did not have a flag for 'no zero-tag' and thus silently mapped these incorrectly defined lines into something that just happened to work. Now, when this was made out to be a problem it was too late to change.