Reasonable static limit for MAXOPENINGS?

Hi there,

I wonder if there is a reasonable static limit for the openings[] array, i.e. the MAXOPENINGS macro that determines its size. In this thread at [1], Quasar cites Lee Killough that the size of the array should be the maximum screen dimensions times the size of the data type. In the case of Crispy Doom this would be

int32_t openings[640*400]

and thus result in quite a large memory area.

I wonder if this is really necessary? I mean, what's the worst that could happen. If every single pixel on the screen is part of a opening, wouldn't this be merely *one single large* opening? Isn't the worst that could happen that all adjacent pixels of the screen would be either part of an opening or opaque (like a checker board) so that we end up with SCREENWIDTH*SCREENHEIGHT/2 as the maximum number of possible openings?

Or is this too naive and I am missing something?

[1] https://www.doomworld.com/vb/post/619569

Thanks!

What do openings do anyway? I've never really figured that out. I guess it has something to do with sprite clipping but the code referencing it is pretty arcane.

int32_t openings[640*400]

^ Is that 1000 kilobytes? If so, less than a megabyte, doesn't seem too large to me, for the platforms Crispy Doom runs on.

I'm not sure if I understand the concept of openings properly, but I see it as possible for their number to go up to "screen width * screen height", thanks to the fact how segs are processed from the nearest ones to the camera to the furthest ones, and assuming that nested openings aren't overwriting each other. Imagine that, in a certain column, a single pixel gets drawn at the very bottom of the screen (because the respective seg/plane is low in player's view). An opening gets created above the pixel, covering the entire rest of the column. In next iteration of seg processing, a single pixel gets drawn at the very top of the screen. Another opening gets created below it, covering the entire column except the 2 already established pixels. This can go on for every pixel in the column, with upper limit = screen height. And this all can go on for every column, with upper limit = screen width * screen height. Now please correct me if I'm completely wrong in my assumptions, because it's quite possible.

fabian said:

...I wonder if there is a reasonable static limit for the openings[] array, i.e. the MAXOPENINGS macro that determines its size...
Thanks!

Well, you either make it the right size, or test for overflow (slow? difficult?), or settle for the possibility that your engine might crash...apparently at a fun time during the game :)

Optimization is the root of all evil, sir! Don't worry, I burn way more memory than that, for my in-game console, of all things.

In all seriousness, I don't know who your target audience is (or, rather, their computers). If you want to target the '90s-era boxes, and you want it to be just as lean as possible, you could compile a normal version, and a super-lean version, with a disclaimer that it doesn't remove limits like the normal version. Otherwise, we've all got the RAM - might as well use it. (W * H) is the proper count to set-and-forget, after all.

I have no doubt that Carmack knew his limits were insufficient to cover user-made levels, and he knew that building all of the arrays statically made his engine unstable. But you have to remember his goal: 27 tested (over-tested) levels, running in 4Mb, on a sad 486. And, dynamic allocation = more code, more time to debug, bigger .exe, memory fragmentation possibilities on a memory-starved box, etc, etc.

Point is: Yes, his approach made sense then, but not in this day and age, unless you target an early 90s box.

The openings array *must* be width*height in size in order to be large enough to hold the theoretical bounds of generated data.

^ And the theoretical way how the rendering engine could practically reach the theoretical bounds of generated data, what exactly is it? Something like what I said in my post above, or something completely different?

Visplane Explorer used to have the ability to show the # of openings.

I removed it because the only time it even came close to overflowing was when visplanes or drawsegs were well over their limits (like two or three times the limit).

If you want to keep it a fixed size, I suggest make it SCREENWIDTH * 128. Using width*height is totally overkill imho.

If I recall the engine's workings correctly, any visible "see through" section of a wall (door, window or handing architecture) during rendering constitutes an "opening", and is expressed in terms of bottom/top coord for each x-coordinate (hence the SCREENWIDTH constant).

Now, in theory, with a given vertical resolution N, you could have up to N/2 openings (a window inside a window inside a window etc.), each with at least a single pixel of its "frame" visible at the top and the bottom.

I'm not sure about how openings where only e.g. the top or bottom parts of a window are visible are counted, e.g. looking at a series of doorways behind doorways behind doorways.... at such an angle that you cannot see the bottom rows of each, only the top of their frames/ceilings. I think in this case they all have the same bottom coord, but it's not shared, it's simply repeated. In such a scenario, you could render up to N openings, and so not even a SCREENWIDTH*N array would suffice.

So, any takers for a concept map pushing the boundaries? ;-)

My port has the code copied from <somewhere> that increases the max openings as they overflow. I started with 10,000. it would be really handy if there was a known source of test wads for this sort of stuff. The best (worst?) wad that I've found so far is herian2.wad map 23 exit room which tops out at around 60,000.

OT: There really needs to be somewhere that source port authors can find test wads!

The minimal concept map to result in maximum number of openings would have to place 168 2-sided linedefs into the player's view, all of them orthogonal to the player's direction of view, into specific distances where each one only displays as 1 pixel tall on the player's screen. The problem with this setup is that, since (as I believe) there need to be height variations between floors so that the openings would be created, the view in question would also contain 168 visplanes, which is above vanilla's critical limit. Maes's setup where each seg would be visible both as 1 pixel on the top and 1 pixel on the bottom of the screen should be affordable though, as the required number of linedefs and also visplanes would be twice lower and under the limit, but the number of openings would be twice lower than screen width * screen height too.

Thank you for your replies. I'd still love to see an actual map that exceeds this limit, though. I have just seen that indeed MBF keeps a static array of SCREENWIDTH*SCREENHEIGHT dimensions, so I'll either stick to that or implement dynamic array resizing. Until someone else comes up with a better idea, that is. ;)

Quasar said:

The openings array *must* be width*height in size in order to be large enough to hold the theoretical bounds of generated data.

Hm, doesn't this apply more or less to all rendering limits? I mean, isn't it possible to render *at most* SCREENWIDTH*SCREENHEIGHT segs or even visplanes at a time? However, I still don't think that hard-coding the corresponding array sizes to width*height is a sensible idea.