Weird linedefs behavior In NUTS.WAD in Vanilla Doom

Try this on dosbox:

C:\DOOM2 -file nuts.wad -nomonsters -warp 1

then strafe right slowly until the walls disappear. WHY?

Vanilla engine limits? Considering all the things in the level doing anything, maybe it's the super long linedefs making it act weird.

On 3/22/2018 at 4:50 AM, Glaice said:

Vanilla engine limits? Considering all the things in the level doing anything, maybe it's the super long linedefs making it act weird.

So it must be an overflow. What type overflow is this?

Long wall error? If not, not sure.

27 minutes ago, Glaice said:

Long wall error? If not, not sure.

The long wall error happens when theres a wall that its too long (1024 map units) The long wall error appears that the wall is dancing like an idiot. The wall is still rendered, not disappearing.

Drawsegs overflow. Even if the wall might appear as one piece on the automap, for rendering purposes it's actually partitioned into many smaller pieces due to the BSP, and so portions of it may not be rendered if the static drawsegs limit is exceeded.

Maes you don't seriously think nuts.wad has too many segs do you?

I actually tried the WAD in Chocolate Doom and my initial guess is that the nodes for the map are messed up in some subtle way that is only an issue in vanilla.

[edit: I just tried rebuilding the nodes and played it again and the effect is gone, so yeah, nodes.]

Well... at first glance it wouldn't make much sense, as it's basically just 3 long walls plus one broken by a door, but it's the only mechanism I know that can negate the rendering of walls. Then again I am not sure if there's a limit to any individual drawseg's length, which would force breaking it up in more than the engine can handle.

Only a port with real-time rendering metrics could shed some light into the mystery. Also, the OP didn't say which version of vanilla Doom engine they're using: if it's v1.666, the static drawseg limit is much lower (128 in v1.666, but was lower still before, e.g. 64 in v1.1). While 256 may seem a fair amount, 128 could start struggling.

So the part of linedef that were disappearing was too long, there are too many segs that triggered drawsegs overflow, isn't? 

If it was too long, we can see the long wall error, right?

Well, I was curious and tried this in ChocoRenderLimits: no drawseg overflow, however there's quite some bleeding from the second area. That's technically not the same thing as either the long wall error or a drawseg overflow.  Is that what you saw in Vanilla doom?

20 hours ago, Maes said:

Well, I was curious and tried this in ChocoRenderLimits: no drawseg overflow, however there's quite some bleeding from the second area. That's technically not the same thing as either the long wall error or a drawseg overflow.  Is that what you saw in Vanilla doom?

yes, exactly.

I found this kind of shit after editing the map, but i didnt touch any walls, just flooding the entire map with bfgs then i play with my mate, deathmatch

If it was the map error, i didnt see it in any source ports, only vanilla doom. so it must be vanilla rendering engine error.

Still, I cannot put my finger exactly on what kind of error this is. I guess this is yet another job for @Linguica?

Edit: nm, I just saw the nodes response. What's interesting is that VS claims to have rebuilt the map too...So no nodes were rebuilt in his case, or they ended up borked again?

I remember seeing a similar error in Shareware Doom in the outdoor area of E1M8...

2 hours ago, GoatLord said:

I remember seeing a similar error in Shareware Doom in the outdoor area of E1M8...

ikr, but its harder to reproduce and its sometimes crashes the game xD

I'm surprised no one's offered the solution after a week. Yes, it's the nodes; more specifically, a slime trail.

Hey, I found this internet(Youtube)A guy name Zedek (fomerly known as NoMac90) make a video about this loooooong ago.

It was Slope Div overflow, and its already discussed before in Doomworld Forums!

(Note: I didnt paste the video link here because it is copyrighted.)

Link: