Yet another new ZDBSP!

[randi]

Hot on the heels of ZDBSP 1.6 comes ZDBSP 1.7. This doesn't fix any new bugs introduced in 1.6; instead, it fixes several old bugs from 1.5 that didn't get fixed in 1.6:

• Fixed creation of 1D subsectors in GL mode. (See Deathking's map48)
• Fixed creation of extremely short minisegs in complex areas in GL mode. (See Catastrophe)
• Fixed overflows on extremely large maps in GL mode. (See Cold As Hell's map12 and map13)
• Fixed constructs using overlapping two-sided lines to place multiple textures on a single line. (See Eternal Doom's map28--or basically anything else by Paul Schmitz)

Additionally, ZDBSP now comes in an SSE2 optimized version for additional speed on those processors that support it.

Quick download links for ZDBSP 1.7:

• ZDBSP 1.7 (Regular version)
• ZDBSP 1.7 (SSE2 version)
• ZDBSP 1.7 source code

[stx 2.0]

Wow, That was quick

[Graf Zahl]

This means that I can finally dump glbsp for good.

[BlazingPhoenix]

Heh, so ZDBSP is finally getting an update?

[Enjay]

Heh, so ZDBSP is finally getting an update?

"Finally"? This is the second update in as many days.

Does the SSE2 version simply work a bit quicker on supported processors - no other differences? Just wondering because I can't say I ever found ZDBSP to be particularly slow in the first place.

[Bio Hazard]

The SSE2 version finishes before you even run it!

[Graf Zahl]

I get a 10% speed boost from the SSE version.

However, when I compiled GZDoom with SSE on it was slower than the regular floating point code.

[Wills]

One-Dimensional Subsectors? How is that possible?

[Graf Zahl]

Mapping hacks.

Deathkings for example had some polyobjects placed in the void with no space beyond them.

[randi]

Does the SSE2 version simply work a bit quicker on supported processors - no other differences?

Yes, and you can probably expect another ZDBSP before too long, since I found a bug in the v5 GL node output. But more importantly, I located and removed a major bottleneck when building nodes for large maps. For small maps it's not so noticeable.

But by means of examples, rebuilding all the nodes in doom.wad is about 1% faster. Vrack2.wad and vrack3.wad are both built about 25% faster. Eternal.wad is built 15% faster. Cata.wad is 35% faster. And I'd give a number for cah.wad, but it's not building right now.

So for now, I'm seeing if there are any other easy ways to eek more speed out of it before doing another release. And I also have to see what's up with cah.wad.

Edit: Fixed my stupid errors that prevented cah.wad from rebuilding. It is 20% faster than before. More times: av.wad is 15% faster. mordeth.wad is 8% faster. strain.wad is 5% faster. hexdd.wad is also 5% faster. 3057hub1 is 25% faster. Daedalus.wad is 15% faster.

I should also mention that these improvement percentages are for a GCC 4.0.3-built version, which is already about 15% faster than the VC version I've always supplied up until now.

[Jim]

I guess those new vectorization optimizations in GCC 4 are really paying off!

[Enjay]

Those are pretty impressive improvements, especially on the big maps. So, does (or rather will) this affect the node building that Zdoom does itself, or is this just for the stand-alone ZDBSP? Although the improvements are significant, even big maps only take a few seconds to build with the stand-alone ZDBSP. So I gain by 2 or 3 seconds on a very large map and less than a second on a small one. That's not a huge time saver in the bigger picture of the whole editing process and it happens at a time when I'm expecting it. So, in those circumstances, whilst welcome, a process that only takes a few seconds anyway being shortened is not vastly important (to me anyway). (Heh, I remember one editor I used "back in the day" had a built in node builder that could easily take minutes to build a '94 standard map.)

However, a couple of seconds knocked off the time ZDoom takes to create nodes for a big map when none have been pre-generated (or gennodes 1 is set) would be a huge improvement. That delay can seem painfully long, sometimes, even though it is still only a few seconds.

[Graf Zahl]

To be honest, for levels that require several seconds to build the nodes I normally pre-generate them so that they are there when the level is loaded. And while it is nice to see an improvement in processing times let's not forget that ZDBSP is already magnitudes faster than glbsp or many other node builders.

I really don't think that squeezing yet a few more percents out of this is that important...

[randi]

So, does (or rather will) this affect the node building that Zdoom does itself, or is this just for the stand-alone ZDBSP?

Yes, everything that affects nodebuilding in ZDBSP can easily be merged back into the nodebuilder.

I really don't think that squeezing yet a few more percents out of this is that important...

With SSE disabled, ZDBSP 1.8 can build nodes for vrack3 in 45% of the time taken by 1.7. With SSE enabled, the difference is less impressive, taking 65% of the time used by 1.7. And I've written it in such a way that it can select SSE or non-SSE at runtime, so the internal nodebuilder can also see the benefits of SSE optimization without making the rest of the executable use SSE.

[Hirogen2]

What SSE set exactly does zdbsp have support for?
Most AMD K7 (Duron, Athlon, AXP, etc.) do not have SSE2. Oh BTW, using "-msse -mfpmath=sse" with gcc on regular (i.e. no manual asm statements for SSE) also works wonders.