[Fixed] ZDBSP bugs

Bugs that have been investigated and resolved somehow.

Moderator: GZDoom Developers

Forum rules
Please don't bump threads here if you have a problem - it will often be forgotten about if you do. Instead, make a new thread here.

ZDBSP bugs

Postby 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.
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Postby 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.
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby Hirogen2 » Sat Sep 13, 2003 3:59 am

Ah ok. Then I just remove all REJECT from the IWADs :P
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.
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

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

Hirogen2 wrote:Ah ok. Then I just remove all REJECT from the IWADs :P
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?
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby 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. :)
User avatar
Enjay
Everyone is a moon, and has a dark side which he never shows to anybody. Twain
 
 
 
Joined: 15 Jul 2003
Location: Scotland

Postby 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby 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.
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Postby 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby 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.
User avatar
HotWax
Do what you must, and pay the price later.
 
Joined: 18 Jul 2003
Location: Idaho Falls, ID

Postby 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 allExpand view
----E1M2----
SEGS is too big for vanilla Doom and some ports. (34558 segs)M
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Postby 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.
User avatar
Graf Zahl
Lead GZDoom+Raze Developer
Lead GZDoom+Raze Developer
 
Joined: 19 Jul 2003
Location: Germany

Postby 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?
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Postby 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.
User avatar
randi
Site Admin
 
Joined: 09 Jul 2003

Postby Hirogen2 » Sat Sep 13, 2003 11:44 am

If ZDBSP is based on DEU5/Doombsp (doombsp.sf.net), is the default cost also 17?
User avatar
Hirogen2
 
Joined: 19 Jul 2003
Location: Central Germany
Github ID: jengelh
Operating System: RedHat-like Linux (RHEL, Fedora, CentOS, etc) 64-bit
Graphics Processor: Intel (Modern GZDoom)

Next

Return to Closed Bugs

Who is online

Users browsing this forum: No registered users and 0 guests