ZDoom

by **Hirogen2** » Sat Sep 13, 2003 2:36 am

Hi,

when I tried some bad-and-good things on ZDBSP. In all these cases, the input WAD is filled with one Hexen-style map level (MAP01).

1. removing the BLOCKMAP entry in the input, creates the BLOCKMAPs in the output, as well as a duplicate BEHAVIOR entry.
2. removing one of the vital node parts (SEGS,SSECTORS,NODES) -- I tried with NODES -- zdbsp skips the map, even though NODES is not needed as input, as it is being rebuilt.

That's all so far. And a suggestion: add a REJECT builder to it.

by **HotWax** » Sat Sep 13, 2003 2:39 am

As has been discussed here before, the reject map was only put in as a speed hack, and apparently wasn't all that wonderful even back in '93. On today's systems, it's a waste of space in the WAD file. The only practical use is to create special effects such as "dark areas" where the monsters "have trouble seeing you" by making specific entries, certainly not something a node builder should be doing.

by **Graf Zahl** » Sat Sep 13, 2003 3:10 am

Reject is utterly useless on modern computers. A year ago I did some tests and even in the most extreme cases (huge maps with several 100's of monsters) it barely saved 5% of execution time. If a map needs reject for a speed up it is in serious problems anyway. The real performance problems are elsewhere.

by **Hirogen2** » Sat Sep 13, 2003 3:59 am

Ah ok. Then I just remove all REJECT from the IWADs

But still, there is those two bugs...
And I got the warning "GL_SEGS is too big for some ports. (36477 GL segs)", so I hope ZDoom(GL) do handle more than that.
Similar arose for a rebsp'ing of P:AR, which also had normal SEGS overflow, w/reason "Some ports can't handle that" or so. Since P:AR is Boom, either 1. Boom was already that enhanced to support *many* segs (and thus all other ports, and then this message is useless), or, 2. everbody played P:AR in Zdoom anyways.

by **Graf Zahl** » Sat Sep 13, 2003 4:43 am

Hirogen2 wrote:Ah ok. Then I just remove all REJECT from the IWADs
But still, there is those two bugs...
And I got the warning "GL_SEGS is too big for some ports. (36477 GL segs)", so I hope ZDoom(GL) do handle more than that.
Similar arose for a rebsp'ing of P:AR, which also had normal SEGS overflow, w/reason "Some ports can't handle that" or so. Since P:AR is Boom, either 1. Boom was already that enhanced to support *many* segs (and thus all other ports, and then this message is useless), or, 2. everbody played P:AR in Zdoom anyways.

P:AR M6 contains 32662 segs which is not far from the limit. As different node builders yield different results some will overflow on this level. One node builder I tried did. (I don't remember which)

Another question: What if someone makes a map that even overflows ZDoom's file limit for segs (65536)? If the nodes have to rebuilt every time such a level is started it would become a major annoyance. Is there a chance to define an enhanced (32 bit) node format so the nodes for huge levels can be prebuilt so starting such a level is quicker?

by **Enjay** » Sat Sep 13, 2003 5:31 am

Just a comment...

The problem I have with big levels is less the node building time and more the performance hit they can have when playing the level. Hundreds, even thousands of monsters running around and views over thousands of 2S lines etc can really hit the fps on slower machines. That slowness affects the entire duration of the play, not just the level load time - more important IMO. There seems to be a bit of a macho "hey look at the size of my level" thing going on ATM. A well constructed hub will work much better than a massive level, especially if your machine specs are lower end. Fine, push the limits simply to say they can and have been pushed, but keep the levels playable too.

And that comment comes from someone who has sufficient machine specs not to really be hit by performance issues. More of a feel thing for me; I feel huge levels tend to "chug", and are unecessarily unweildy. But that is a less tangible "touchy feely" argument.

by **Graf Zahl** » Sat Sep 13, 2003 6:21 am

Enjay wrote:Just a comment...

The problem I have with big levels is less the node building time and more the performance hit they can have when playing the level. Hundreds, even thousands of monsters running around and views over thousands of 2S lines etc can really hit the fps on slower machines. That slowness affects the entire duration of the play, not just the level load time - more important IMO. There seems to be a bit of a macho "hey look at the size of my level" thing going on ATM. A well constructed hub will work much better than a massive level, especially if your machine specs are lower end. Fine, push the limits simply to say they can and have been pushed, but keep the levels playable too.

And that comment comes from someone who has sufficient machine specs not to really be hit by performance issues. More of a feel thing for me; I feel huge levels tend to "chug", and are unecessarily unweildy. But that is a less tangible "touchy feely" argument.

Hmm, I have never had any performance problems due to level size. Even the largest ones possible with the 32768 limit for segs, nodes and ssectors played without problem on my old 1Mhz machine. The real performance killers are mostly the monsters and other actors. The only level where I experienced real problems was TNT3 Map01 but that was only due to the snow in it. After deactivating the snow script even that level played without the hint of a slowdown.

by **Hirogen2** » Sat Sep 13, 2003 7:13 am

C'mon, wads like dwspd018.zip/MAP03 even compile relatively fast. For me, but
probably not for you out there

Still this ZDBSP is a wonder. And IIRC P:AR had levels with more than 32767
segs.

by **Graf Zahl** » Sat Sep 13, 2003 8:21 am

Hirogen2 wrote:C'mon, wads like dwspd018.zip/MAP03 even compile relatively fast. For me, but
probably not for you out there
Still this ZDBSP is a wonder. And IIRC P:AR had levels with more than 32767
segs.

I just checked. E1M7 has the most with 32733. If it had more than 32767 it wouldn't work with MBF which was the engine it was developed on.

by **HotWax** » Sat Sep 13, 2003 10:08 am

Graf Zahl wrote:Hmm, I have never had any performance problems due to level size. Even the largest ones possible with the 32768 limit for segs, nodes and ssectors played without problem on my old 1Mhz machine.

Heh, 1MHz huh? Interesting, seeing as how the minimum spec for Doom itself was what... 25MHz?

Assuming you mean 1GHz, that machine is still faster (in some cases, alot faster) than what many people are using on this board. I have a 1.67GHz, so yeah I'm not going to see many performances issues, but you have to also think about the people using P233's.

by **Hirogen2** » Sat Sep 13, 2003 10:11 am

Graf Zahl wrote:I just checked. E1M7 has the most with 32733. If it had more than 32767 it wouldn't work with MBF which was the engine it was developed on.

I just checked again.

Code: Select all • Expand view: ----E1M2---- SEGS is too big for vanilla Doom and some ports. (34558 segs)M

by **Graf Zahl** » Sat Sep 13, 2003 10:37 am

You are using a different node builder than has been originally used so this isn't a surprise.

by **Hirogen2** » Sat Sep 13, 2003 10:41 am

Randy, what is the Time/Split ratio, that is, is more time taken to search for
a bigger convex area or not?

by **randi** » Sat Sep 13, 2003 10:48 am

You can decrease the number of segs in the BSP by increasing the split cost to something above 8.

The node builder does not care about area at all; only the number of segs on each side of a splitter is important.

by **Hirogen2** » Sat Sep 13, 2003 11:44 am

If ZDBSP is based on DEU5/Doombsp (doombsp.sf.net), is the default cost also 17?

ZDoom

[Fixed] ZDBSP bugs

ZDBSP bugs

Who is online