Maximum visible double-sided linedefs limit?

[Maes]

I seem to remember that there was a precise limit on the maximum number of double-sided visible linedefs, and it was as low as 16 for the original Doom (at least v1.1 registered) and was raised to 64 for Doom 2 v1.666.

The doom wiki doesn't mention anything about this, however looking at an area with more than #limit double sided linedefs will cause a HOM-like effect, with both vanilla and Doom95. Many "source port" maps seem to only hit this limit, BTW.

So, anyone remembers the exact figures and details of this limit?

[EarthQuake]

I don't believe there is a maximum limit of sidedefs that can be in a view at once. I think you are referring to visplane overflows.

http://doom.wikia.com/wiki/Visplane_overflow

[Graf Zahl]

You apparently have never seen the effect in action. With Doom 1.2 it was quite easy.

[myk]

The wiki mentions it, but you have to know what you're looking for; it's 256 for v1.9, and applying entryway's Doom-plus hack it can be raised to 2048.

[Maes]

EarthQuake said:

I don't believe there is a maximum limit of sidedefs that can be in a view at once. I think you are referring to visplane overflows.

Ehm, please read my post again. I mentioned "double-sided linedefs", which is a quite different thing, and resulted in a non-fatal error (the game didn't crash, you just got a sort of HOM for no apparent reason).

This put some restriction on the levels' architecture (try forcing yourself NOT to use a lot of double-sided sidedefs, and see that it's not that easy)...I just vaguely remember the figures above as limits for double-sided linedefs, and that DOOM II introduced a major change over DOOM 1.2.

This can be easily checked with a lot of source port levels that don't have any special features, such as Ode of Resurrection. It is playable and completable with both vanilla and Doom 95, only that in some areas, and only when viewed from a certain distance, you get HOM effects, while approaching the offending spot (and thus removing other sidedefs from view) fixes it and it doesn't crash.

Could it be that this information has been lost throughout all those years? (Well, it's also a bit hard to estimate how many DS linedefs you will have in view from a given spot...)

[myk]

Maes said:
This can be easily checked with a lot of source port levels that don't have any special features, such as Ode of Resurrection.

Unless I'm mistaken, that one in particular actually has (as its text file suggests) Boom triggers that break it under Doom+ or under PrBoom with Doom compatibility. There's a switch behind a Baron of hell in a wooden room with crates that seems to be nonfunctional. You say you completed it?

[Maes]

myk said:

Unless I'm mistaken, that one in particular actually has (as its text file suggests) Boom triggers that break it under Doom+ or under PrBoom with Doom compatibility. There's a switch behind a Baron of hell in a wooden room with crates that seems to be nonfunctional. You say you completed it?

OK, I didn't actually complete it, but played it up to a certain point apparently seamlessly, if not for the HOM. I just was looking for a typical example of source port map that doesn't have any special bells and whistles such as e.g. slopes, mirrors or animated skies etc. etc. but merely goes over hardcoded architecture limits. OK, maybe that map wasn't a very good example after all, but I think everybody got the point...

BTW, how can the SEGS limit effectively be translated into double-sided linedefs?

[Graf Zahl]

Maes said:

BTW, how can the SEGS limit effectively be translated into double-sided linedefs?

There is no precise translation. The amount of segs depends on the node builder and on the complexity of the map.

[Quasar]

It's not double sided lines that there was a limit on. It was rendered segs, and there could be up to 128 segs in view at once. After the 128th drawseg was rendered, Doom would simply stop drawing, causing the rest of the lines in view to become HOM. Since Doom draws from front to back, the furthest segs away were always the first to turn into HOM.

I intend to add emulation of this limit back into EE as I did for vissprites in the last version :)

There were also related limitations on openings and other structures related to the drawing of lines and flats that could be triggered on occasion by numbers of segs far less than 128, so sometimes a lesser number could cause more serious problems. It all depended on the architecture of the area in question.

And as Graf said, there's no precise way to determine the number of segs for a given map. However, there IS an absolute lower limit which assumes that no area of the map requires any linedef to be split to build the BSP (this would likely only be possible in a contrived map and possibly with a tweaked node builder as well). In that case, the lower bound for segs could be defined as follows:

minsegs = numlines + num2Slines

Two segs are generated for each two-sided line, and thus you need to count them twice.

[myk]

Quasar said:
It's not double sided lines that there was a limit on. It was rendered segs, and there could be up to 128 segs in view at once.

r_defs.h says:

#define MAXDRAWSEGS		256

[EarthQuake]

Hmm... okay, whoops.

[Quasar]

myk said:

r_defs.h says:

#define MAXDRAWSEGS		256

Hmm, dunno where I got 128 from. But whatever, I was still right on all my other points :P