Search In
• More options...
Find results that contain...
Find results in...

# Segs, subsectors and visplanes

## Recommended Posts

What's the difference between 3 identical sectors and 1 sector split into 3 sub-sectors, in terms of counting towards the visplane limit?

(as I know the merging of subsectors brings the visplane count down, but would turning each one into a new, but identical, sector do the same?)

btw, if you're reading this and are a little confused, I edited the post, it says something different now...

Sectors aren't split into segs, sectors are split into subsectors. Segs are parts of linedefs that are contained within subsectors, so one linedef on the map may be made up of several segs (the way to remember this is that seg stands for line segment).

There is no direct relationship between segs or subsectors and visplanes. The only guaranteed way to reduce visplanes is to reduce the number of differing combinations of floor height, light level, and flat that are visible in any one scene (note scene and not location, since visplanes change as you move about -- any concept of visplanes being static is incorrect -- they even change due to flashing lights, which is what causes jumpy floors in DOOM).

Of course, reducing the number of sectors in a scene may reduce the visplanes by necessity, but you COULD have a billion sectors all of the same properties and with nothing cutting into your view of them, and there would only be two visplanes -- one for the floor and one for the ceiling. So remember, there's no direct correspondence.

But I thought that having one sector split into several parts increased the visplane count, as I have maps with only a few sectors on show but have visplane bugs in them (these sectors are big and split into many parts). I also remember something about linedefs and columns affecting the count, too.

you can get a VPO with only two sectors, possibly with one sector (though I haven't seen it done). A visplane is essentially a floor or ceiling that differs from the surrounding area in some way (either by a different texture, light level or height).

For instance:

```|-------------------|
|      C: CEIL5_2   |
|      F: FLAT23    |
|-------------------|
|      C: CEIL5_1   |
|      F: CEIL5_2   |
|-------------------|
```
Such an arrangement would result in four visplanes, assuming you can see the floors and ceilings of both of those sectors. If you were to lower one of the sectors floor height until you couldn't see the floor then there would only be three visplanes. Now say you do this:

```|-------------------|
|      C: CEIL5_2   |
|      F: FLAT23    |
|-------------------|
|      C: CEIL5_1   |
|      F: CEIL5_2   |
|-------------------|
|      C: CEIL5_2   |
|      F: FLAT23    |
|-------------------|
```
Note that the top and bottom sections have the same properties (assume all floor/ceiling/light levels are the same for the three sections). Regardless of weather or not you make the top and bottom sections into the same sector, this arrangement will still have six visplanes, regardless of if the map has two or three sectors, so it has nothing at all to do with sector count or segs or anything like that.

Now you can also run into issues depending on where you view an area from. For instance if you were to stand in the middle sector and look north then you would not be able to see the sector (or subsector) to the south, so there would only be four visplanes.

NOW, if you have something like the following:
```|-------------------|
|      C: CEIL5_2   |
|      F: FLAT23    |
|                   |
|                   |
|      |----|       |
|      |    |       |
|      |----|       |
|                   |
|-------------------|
```
Where that small middle square is a collection of 1s linedefs (aka a solid column). If you were to stand in the right place (somewhere to the north looking south) despite the fact that the map is only one sector you would actually get three or four visplanes because the column would 'divide' the sector in two from your perspective. If you want to see for yourself make a square sector like 512x512 with a 8x8 column in the middle and stand in front of the column so that you can't see the top or the bottom of the column (where it meets the floor and ceiling) and note that there are four distinct planes (two ceiling, two floor) which not only have the same properties, but also are part of the same sector, yet they still count (or at least such is my understanding) as their own visplanes.

Nope, a column won't create any extra visplanes. It will however create a bunch of segs, and too many of those can cause a VPO as well (oddly).

are you sure? I was always under the impression that visplanes didn't really have anything to do with segs but more to do with dividing floors and ceilings in one way or another

I think you're right Cyb, here's something I found, I think this txt file came with an older version of BSP.

The Facts about Visplane Overflows 09/20/1997

Lee Killough
killough@rsn.hp.com
http://classicgaming.com/doom
--------------------------------------------------------------------------

Visplane overflows have long been a mystery (and a source of controversy)
in the Doom editing community.

Here's my best theory to-date about the real cause of visplane overflows:

Too many changing ssectors (sub-sectors) in view at once, with different
floor and/or ceiling properties. Floors and ceilings count separately
towards the limit, and only when each is actually visible to the player.
Two flats are considered compatible if they have the same texture, the same
lighting level, and the same height (unless the texture is F_SKY1, in which
case height does not matter). If two visible flats are compatible, and they
are only separated by a 2s linedef or by flats that are not visible, then
the visible flats are merged into the same visplane.

However, there are some limiting factors -- factors that the number of
visplanes cannot exceed a constant multiple of:

1. Number of 2s linedefs in view with different flats properties on
either side of the linedef.
2. Number of distinct floor sub-sectors + distinct ceiling subsectors
in view.

Cyb said:

are you sure?

Yep. You can check it in prboom with the idrate code. I get two visplanes no matter how many pillars I place in a sector.

I was always under the impression that visplanes didn't really have anything to do with segs but more to do with dividing floors and ceilings in one way or another

Yeah, but a visplane overflow is what you get anyway with too many segs in view (IIRC).

Oops, I wonder how that happened :P

Cyb said:

If this was true this thread wouldn't exist... :-(

You don't have to worry about it. You only worry about it if you want to.

Well, I left out the detail about 2S lines, because I tend to forget about how they mess up the otherwise elegant DOOM renderer (they are by far the slowest thing to draw, aside from TRANSLUCENT 2S lines, which are of course, even worse).

Graf Zahl said:

If this was true this thread wouldn't exist... :-(

not at all, it can meerly be viewed as a discussion on historical aspects of the old engine. and personally I find that stuff interesting, even if I don't have to worry about the doom2.exe limits when I edit

Cyb said:

...unless you're testing and tweaking Plutonia II maps.

"Too many segs" do not cause visplane overflows, NO MATTER WHAT. I want to make that absolutely clear. There has never been any limit on segs aside from the hard data type limit of 32768. However, DOOM will only *render* the first 128 segs in view; the rest become HOM (DOOM renders front to back, explaining why the first segs to disappear are those furthest from the camera). This is NOT a bug in the engine and cannot result in bomb-outs, hang ups, or segv crashes. It is an intentionally coded limitation.

There WAS another limit in the DOOM engine, however, which was a limit on something called openings. I have never been precisely sure of what an opening is, but DOOM only had a static array for them and didn't even bother to check if it was being overflowed. Once it overflowed, the engine would randomly venetian-blinds crash soon afterward (but when and where could be unpredictable depending on the timing and extent of the overflow).

DOOM also did not check if VPO had occured until well after the fact (which is why the error can report #'s of visplanes WELL in excess of 128). The fact this doesn't usually crash is a happy coincidence, because DOOM can corrupt memory past the 128th visplane. It is well possible that an extreme VPO could cause a venetian blinds crash before the engine bombs out to report the error.

Segs being the offender is the explanation i got from cph. Maybe it wasn't them directly but something they triggered, though.

Quasar : Just a guess, but maybe openings have something to do with sectors made up of 2s-Linedefs? By the way, what do you mean by "venitian-blinds" crashes?

And if Doom didn't bother to check if the "openings" limit were being overflowed, why bother even putting a limit on them?

And what about segs, what exactly is a seg?

But more to my point, if things like VPO's occur, why hasn't anyone
ever bothered to create a REAL limit-removing port, meaning, a
higher sector limit
, a higher segs limit, lindefs limit, and so
on?

And by the way, the fact that Doom didn't check until VPO's had occured until well after the fact, then wouldn't that make the engine pretty unstable at that point?

And if Doom didn't bother to check if the "openings" limit were being overflowed, why bother even putting a limit on them?

In order to remove the limit they'd have to allocate the memory dynamically. Technically, that would be the better way, but it means more processing compared to a predetermined amount of memory. It was probably the right decision for the time.

And by the way, the fact that Doom didn't check until VPO's had occured until well after the fact,

DooM doesn't even draw the frame that causes the VPO. The check comes right at the beginning of the drawing routine.

Also, the check for max openings is right there, too. Couldn't tell you what an opening is, though. The limit is defined as SCREENWIDTH*64.

heh, the original exe just isn't coded all that well, this being a perfect example. not checking for array bounds is a horribly, yet often easy to avoid, error

Darkhaven4 said:

why hasn't anyone
ever bothered to create a REAL limit-removing port, meaning, a
higher sector limit
, a higher segs limit, lindefs limit, and so
on?

Because it requires a new map format. You can double the amount of most resources by making the fields unsigned (like ZDoom did) but beyond that you need more than 2 bytes and that cannot be stored in Doom's map format.

Darkhaven4 said:

And by the way, the fact that Doom didn't check until VPO's had occured until well after the fact, then wouldn't that make the engine pretty unstable at that point?

Considering the fact that doom2.exe is very segfault happy to maps on the limits and don't even bother switching back to text mode then, you can say it IS unstable at that point.

I made a goof actually. It wasn't openings, but rather spans, which had an insufficient static limit in the original engine. Openings also had a problem during BOOM development related to not enough memory being allocated for them, but I don't know if this was a problem in the original source or not. The spans problem WAS in the original engine, though, and here's Killough's changelog notes about them:

Lee Killough said:

Fixed span limit problem -- this was apparently the bug which was affecting Lisa's wad, and it has probably been in every version of Doom.

When scan lines (rows) are drawn, there are spans along the x-axis which are simply intervals (x1,x2) which have been drawn already. When Doom draws a texture, it clips it against previously established spans, and if the texture is non-transparent, adds it to the list by computing the union of the previous set of intervals and the interval of the new texture...

The bug was that Doom only allocated 32 elements in an array for the spans. On a complicated wad like Lisa's, where a large outdoor scene has many "posts" which consist of alternating transparent and non-transparent regions (like the pilliars in her wad), the limit can add up. Doom never kept track of the limit or whether it was even exceeded, so if it was exceeded, it simply overwrote memory and the result was usually a venentian blinds crash, or a seg fault in this version.

So, there you have it. BTW, "Venetian Blinds" is the old name for the peculiar way in which DOOM crashed under DOS. Sometimes, when you were lucky, you'd get a DOS4GW stack dump and be able to reboot your system normally. But most of the time, DOOM's picture would suddenly just "fold up" into little lines, which would look like window blinds closing, and then it would leave you stuck at a black 320x200 window with some extremely dark text in the upper left corner. All of DOOM's system handler code, such as for the keyboard, would be left installed, so the system was totally unrecoverable and had to be cold booted (ie, power off and back on). Occasionally, there would be a loud, roaring, constantly repeating sound accompanying this, but it was rare compared to the incidence of "normal" venetian blinds crashes.

One time on my old 486, I had my printer turned on when DOOM crashed, and my printer started printing a solid page of garbage characters. Since DOOM has no code in it to print ANYTHING on a printer, I can only assume it corrupted some part of DOS which then sent instructions to print to my printer. DOOM was supposed to be a protected mode program, but apparently under the lax DOS4GW extender, it was still possible to do damage to the system.

Ugh, I always useed to get that relaoding after an Archvile toasted my ass.

Graf Zahl said:

Because it requires a new map format. You can double the amount of most resources by making the fields unsigned (like ZDoom did) but beyond that you need more than 2 bytes and that cannot be stored in Doom's map format.

I knew that it was the actual wad format, not the engine, that causes the limits, I just wasn't thinking when I said that.

So DooM's map format can only store 2 bytes of signed/unsigned data?
I didn't know that...

Yeah, I can just imagine it : Doom in .HNK format. As a matter of fact, does anyone know where I can snag the Doom source?

But back on the subject, is there some kind of .WAD code anywhere within the Doom source, or is it just...Well, that filetype in general?

In order to lift the data type limit on level resources, you would literally need to rewrite all the math in the engine to ensure that everything remains within bounds or is otherwise done correctly. This can certainly be done; zdoom uses floating-point math internally so it could technically support a floating-point wad format as well.

You'd also have to create editing utilities -- map makers, BSP, reject, etc -- which can handle the new format.

It is true that you could expand the numbers to 4 byte integers, but that's really a half-assed solution to what is really the ultimate problem of DOOM using fixed-point math. See, map coordinates and the such, once inside the engine, have to fall within the range of -32768 to 32767 because of fixed-point math, which shifts a 16-bit number up 16 bits and stores it into a 32-bit integer, allowing the lower 16 bits to be used as decimal places. It was good back then, but is really antiquated for use on PCs now.

Quasar said:

It is true that you could expand the numbers to 4 byte integers, but that's really a half-assed solution to what is really the ultimate problem of DOOM using fixed-point math.

I agree that this is a huge problem and have seen far too many problems coming from it.

But this discussion was about limits like number of linedefs/sidedefs/segs etc. And for that extending the respective fields in the WAD to 4 bytes would be the only way to increase them. Internally the engine can easily handle the numbers.

Quasar said:

One time on my old 486, I had my printer turned on when DOOM crashed, and my printer started printing a solid page of garbage characters. Since DOOM has no code in it to print ANYTHING on a printer, I can only assume it corrupted some part of DOS which then sent instructions to print to my printer. DOOM was supposed to be a protected mode program, but apparently under the lax DOS4GW extender, it was still possible to do damage to the system.

Protected mode doesn't imply a software doesn't have access to the DOS routines. It is very possible to call DOS INT's randomly and trigger printer output. A correctly configured multi user system like Linux is required to prevent things like this.

Though DOS4GW doesn't seem to prevent access out of array boundaries, which could cause many strange behaviors like the "all ghosts"-bug, but this would be limited to the own segments or it would cause a seg fault for sure. I guess, the array boundary check is a compiler option, since several of those bugs cause a seg fault in the Final Doom EXE while it doesn't in regular v1.9.

DOS4GW really is more lax than a proper DPMI host should be, which is why DOOM could get away with having so many otherwise fatal problems. CWSDPMI, which is what pretty much any program compiled by DJGPP uses, is much more strict (and correct), therefore the earliest DOOM ports had lots of problems -- it's surprising to me that the initial DosDOOM port can even run at all, considering how many problems in it remained unfixed until the BOOM team got ahold of it.

Graf Zahl said:

Because it requires a new map format. You can double the amount of most resources by making the fields unsigned (like ZDoom did) but beyond that you need more than 2 bytes and that cannot be stored in Doom's map format.

Yeah, that was something Randy listened to me about - trivial change:)

Now the first limit that is reached is not the format of the level (even at unsigned 2). The real limit is with the nodes. For some ports the BLOCKMAP, but a lot of ports have internal blockmap code (a -0- blockmap size is ok), so n/a for those (internal generation only takes a few ticks).

IOW, the real concern thing that should be done is expand the node control set to 4 byte fields where applicable. There are already a few test levels I've tested that can't be played because of this problem (authors had no idea they wouldn't work with anything out there).

Along those lines, I've added GL nodes to DeePBSP (next release 11.9) and although this now supports >32k sidedefs/vertices, unfortunately the GL format still suffers in places from unsigned 2 where 4 could have been chosen with no extra effort - at a minimum the node struct so at least 64k nodes could be supported. File size increase is n/a in todays environment (and even back when).