Stupid BSP Tricks

Jon said:

Thanks for the tips. No, the only reason I'd start with GLBSP is because I know it's been touched recently-ish. I think I packaged it for Debian. The Vanilla-specific stuff in BSP and/or ZenNode would indeed make them better candidates.

BSP's code is quite clean and portable so I don't think you'd have much difficulty with it. There are a few archaic elements that could probably stand to be tweaked, as in any sufficiently useful program.

So what is it exactly that breaks vanilla portals in MBF compared to Boom 2.02? I did a quick source comparison between the two and it seems like the only substantial differences (in r_bsp.c, r_segs.c, r_main.c, etc.) involve sky transfers and tweaking the behavior of "underwater" sectors. Most of Killough's changes to the renderer are already present in Boom 2.02 but don't seem to break support for the effect at all (at least when testing Ling's latest example).

Arctangent said:

I mean, tricks that can be done without hex editing end up unsupported by 3D renderers due to not really working in a 3D environment, so this is kind of like saying plain bread is white and claiming it's not bread because it's not brown. Especially when it's been known that white bread is white.

... Heck, it's even named after it.

Yeah, I know - it was quite dickish. Of course, you know, hex editing just proved the concept. There's no reason why real support cannot be added.

fraggle said:

Graf Zahl's position is reasonable enough to be honest. I totally understand it.

It's still a cool hack though. I wonder if it's possible to come up with a modified version of BSP that will be able to support the most basic type of hack (this one) that seems to work in quite a few source ports.

Again, yeah, agreed. Graf's main complaint is that ZDoom no longer uses the structures that make this work for it's rendering (if I'm not mistaken), so the renderer would have to be reverted back to running the way every other software port runs. Though, it seems to me that ZDoom's philosophy is to be able to render every idTech1 map in existence...

Graf Zahl said:

Get real people.

Translation: "Hacks are bad. Don't do hacks. Cause hacks are bad. If you do hacks, you're bad. Because hacks are bad.

You're gonna need an editor. This won't work without an editor. Who will spend time to make the editor. And you'll need a modified BSP tool. No one will build that BSP tool. It'll be chaos - mayhem! Whatever will we do?"

I smell a megawad...

Firefish is probably right where he needs to be to find the difference between vanilla and the ports that don't currently render Linguica's maps as intended. It might be necessary to detect these structures, and conditionally make some of the new checks inoperative. It's probably easy to comment out some of that code during a debug session, and see if the "portalings" appear.

I'll give it a shot this weekend.

@Linguica: Make more, make more!

Jon said:

Thanks for the tips. No, the only reason I'd start with GLBSP is because I know it's been touched recently-ish. I think I packaged it for Debian. The Vanilla-specific stuff in BSP and/or ZenNode would indeed make them better candidates.

I had a look at the DoomBSP source last night and I think it should be possible to implement the kind of trick Linguica's pulled off in a controlled way.

My idea is to make it possible to define different "domains". Maybe think of a domain like it's a parallel universe coexisting in the same level or something. The default domain is the one that the player normally sees and walks around in. By defining a new linedef type recognized only by the BSP builder, it should be possible to surround a particular area of the level (ie. collection of sectors) to delineate a separate domain. The sector tag can be used to indicate a domain number. For example in the hell portal demo level you would set this linedef type on all the lines on the border of the hell area, and set the sector tag to a domain number of your choosing.

The BSP builder then builds the level as normal, but builds separate BSP trees for each domain. In places where you want a linguortal to appear, you'd give the portal sector a linedef tag corresponding to the domain number that you want it to view (ie. "window into this other domain here"). This acts as a hint to the BSP tool: instead of the normal ssector(s) that would be generated, the root of the other domain's BSP tree gets hooked into the main BSP tree at that point.

The other domains probably won't appear when viewing the level normally - only when viewing them through a linguortal. For example in the demo map if you noclipped to where the hell area is, you wouldn't see it. There might be some way to make them appear normally if we can find some way to keep the different domains part of the same BSP tree. Actually, it might turn out to be essential to do this. We'll have to see.

The DoomBSP algorithm is pretty simple - check out the description at the bottom of makenode.c. It should be a matter of sorting the segs into separate lists by domain and then calling CreateNode() for each in turn.

Actually, I like the new BSP tool linedef number idea. Calamity won't be using the old-school BSP tree, it'll generate its own culling structures. A big giant hint like that will let me kick in the correct code to handle it.

I guess I should explain the trick in a little more detail.



So this is the map as it looks in a map editor. As you can see, the slime area is entirely separate from the main area of the map. I have it vertically aligned from its "final" location, but that was more for the ease of hex editing than any necessity.



Here's the root node of the BSP tree. As you can see, the main area and the slime area are both in their own separate "worlds" so to speak. This part is critical - if the nodes were built in such a way that bits of both were in the same node, it would be much more difficult, and probably impossible.



Now let's zoom down to the bit of the main map we care about.



Here it is zoomed in.

So if you remember how the BSP tree works, all the engine does is test the player's position against an arbitrary line, and then descend to the node on either the front or back side of that line, where "front" and "back" are defined as from the player's current location. So what we want to do here is have the engine draw the green (front) side of this node split, and then instead of next drawing the blue (back) side, have the renderer jump to drawing the slime area instead. This is (relatively) trivially done, because the NODES structure doesn't have any sort of sanity checking or anything - you just go in and have the left side of this node point to the top node for the slime area, instead of the triangle subsector, and the engine will happy descend into the slime area and draw it instead!

(Note: For this particular effect, I edited the partition line for this node to be outside the main map, so it would *always* register as hitting the "front" side of the line which would point to the green bit, and then the blue subsector would reroute to the slime area as the "back" side. Remember that partition lines are completely arbitrary as far as the engine is concerned, and here, we ALWAYS want the redirect to the slime area to be on the BACK side of a partition line. This is important because the engine ONLY checks the bounding box for the BACK side of a line to see if it can skip rendering the bit altogether, and we need that bounding box check to prevent the slime area from being rendered at certain other (bad) positions. This is kind of complex and not really the main point at the moment though.)

Of course, this is only half the battle, because the slime area is still outside the main map, so it's not like it will appear right on the other side of the "window". So next you have to edit the VERTEXES and SEGS lumps as well.



Basically, you imagine realigning the slime area into its "proper" position. Then you add new vertices to the VERTEXES lump that correspond with where the vertices for the slime area would properly be. Then you edit the segs for the slime area to use the new vertices you just created, instead of the ones associated with the linedefs the segs are tied to.

Remember, the vanilla Doom engine doesn't care where segs are physically located. Every Doom node builder just created segs in the exact location of the linedefs they are derived from, but the vanilla Doom engine doesn't enforce this at all.

So the outcome after doing all this is that when the engine is walking the BSP tree and gets to the node with the redirect to the slime area. Now it goes about drawing the subsectors in the slime area, which in other words, means drawing the segs associated with those subsectors. And since those segs have been manually edited to be on the other side of the window, they get drawn there and appear to be part of a non-euclidean space.

So IMO a basic tool should sort of act like the following:

Jon said:

Personally, I don't care whether it makes it into a non-tech-demo map or not. I imagine it will make it into just one "real" map. But that still doesn't make it any less of a cool trick.

I just wanted to quote that. This is something that boggles my mind. Someone discovers a totally new trick that produces some amazing results, never before seen in a 22 year-old game that's arguably the most hacked game in the history of planet Earth.
And a few posts later, here comes this shitstorm of how awful it is, including pledges to not lift a finger to support it.

What does it take to make you people smile??? Can't you take a breath, and enjoy it for what it is, for a few fucking minutes? It presents like deep depression. In all honesty, my heart goes out to you.
In case you missed it, this is a pretty amazing discovery! At a bare minimum, it's using the standard structures and code we know and love, it a totally new, as-of-yet-unexplored way. I'll reserve my concerns about what it will do to my poor lowly port later.

Open the blinds, and let some sun shine through, people! For Goodness sake!

Nice documentation, Linguica!

EDIT: I sure would like to hear SoM's and Quasar's take on this. After all, Eternity is the king of Portals. Specifically I wonder if Eternity is kinda doing this same thing, at runtime in the engine.

So, visually, this is really, truly creating portals. Wow.

<obvious next question>What will it take to get vanilla to do some of the non-visual stuff with these portals? (Walking in/out, firing bullets and missiles, etc) Having the fake area (slime area) in a physically different area causes the engine to get the non-visual stuff wrong. But, can the fake lines be placed somewhat in the real area, invisible to the "standard" renderer pass, but visible when the portal is drawn?

I'm not much of a mapper, so I cannot give good examples, but I'll try:
. Maybe seg angle is purposely hacked to be wrong, or vertexes are flipped, to hide the fake structures?

Never mind, I need to do some research before I can ask decent questions. Hopefully you know what I'm asking, though. Basically, how much more can be done to make this effect more useful gameplay-wise?

Thanks for the detailed explanation. This mostly fits with how I understood things. The one thing I think I missed was the fact that segs don't have to correspond with linedefs. That makes sense now.

I think a good goal would be to implement this incrementally - like you've done discovering things in this thread. We can set some initial foundations and build on them.

Getting a node builder that can do the hell portal trick from earlier in the map would be a good first step. I want to highlight one important thing you pointed out in your post:

Here's the root node of the BSP tree. As you can see, the main area and the slime area are both in their own separate "worlds" so to speak. This part is critical - if the nodes were built in such a way that bits of both were in the same node, it would be much more difficult, and probably impossible.

The exact same thing occurred to me - it's really important the node tree is built such that the two areas are on different branches of the nodes tree. I've been thinking a lot about how this might be done in a BSP builder and it's quite hard because divisions can be kinda arbitrary. In particular, imagine if your demo was part of a much larger, more complicated level - both areas could theoretically be divided in two by a single vertical line.

That's kind of why I wanted to come up with this idea of domains - effectively building multiple BSP trees that get combined together into a single tree in a final stage. Once you have that separation you can reason about things much more easily.

My original idea was to build the separate tree and hook it in, but I think that's likely to have problems. For example if you make a level like the hell portal hack you want the things to be visible too. But I'm pretty sure the BSP tree is used by the engine when spawning objects - to find the sector at a given point it walks down the tree. So if you were looking through the portal you wouldn't see the objects.

Obviously this isn't relevant for the more advanced linguortal case (where you're translating segs to different locations) but it would be nice to be able to support both cases. In particular the basic case (the hell portal one) seems to work in quite a few source ports, while the more advanced one is clearly far more fragile.

So after thinking about this I have this alternative idea which is to build a "shadow" nodes tree for each domain. In a normal nodes tree, subsectors are leaves and only appear once. But I don't see any reason why they couldn't in theory appear multiple times. Suppose you build the level as normal. If you know the domain that every subsector belongs to, you can then transform and reduce the tree into a simplified version with nodes that just describe a particular domain (I can explain this in more detail if it isn't immediately obvious how).

If you do this, you implicitly get that particular area as a tree that can be hooked in at the portal location. Tree splits shouldn't matter - you have your own mini duplicate of the tree just for the area being viewed through the portal.

Once this is in place it should be a lot easier to make the further step to the more advanced case, where you're essentially just doing a coordinate translation between a pair of linedefs.

fraggle said:

Getting a node builder that can do the hell portal trick from earlier in the map would be a good first step.

Sure, if you think so. I find it kind of "half-finished" but it does have the advantage of not requiring seg hacking and the requisite breakage in many source ports.

fraggle said:

For example if you make a level like the hell portal hack you want the things to be visible too. But I'm pretty sure the BSP tree is used by the engine when spawning objects - to find the sector at a given point it walks down the tree. So if you were looking through the portal you wouldn't see the objects.

I think there's always going to be an issue with things being visible, but I haven't studied that aspect yet really. All I know is that sprites are added by *sector*, not by subsector - this could possibly be exploited somehow.

fraggle said:

So after thinking about this I have this alternative idea which is to build a "shadow" nodes tree for each domain. In a normal nodes tree, subsectors are leaves and only appear once. But I don't see any reason why they couldn't in theory appear multiple times. Suppose you build the level as normal. If you know the domain that every subsector belongs to, you can then transform and reduce the tree into a simplified version with nodes that just describe a particular domain (I can explain this in more detail if it isn't immediately obvious how).

So is this functionally indistinguishable from just making sure the root node (or top couple levels of nodes, in the case that you have more than two domains) have properly placed partitions? Because I guess the exact method is irrelevant in the end.

On a related topic, one thing I don't understand is why every node builder (to my knowledge) always chooses linedefs as partition lines. As far as I can tell, there's no reason why this MUST be the case, and yet it's always been treated as a hard-and-fast rule. If you treat partition lines as being able to be totally arbitrary it would make things easier (e.g., making up a partition line separating two domains), but I don't know if there is some reason why this is a bad idea that I don't know about.

Linguica said:

So is this functionally indistinguishable from just making sure the root node (or top couple levels of nodes, in the case that you have more than two domains) have properly placed partitions? Because I guess the exact method is irrelevant in the end.

The key word is "just" - I've been thinking about this quite a bit and I don't think it's that easy.

I'm thinking about this from the perspective of implementing it in a node builder and implementing it in a more general way. A demo level like this is comparatively simple because you can rely on the fact that the two areas are going to be on different branches of the nodes tree. But imagine if you have a far more complicated level, potentially with a whole bunch of different areas. You can't rely on the assumption that they will be different distinct areas.

For example consider this pathological case:



In this case you have a player standing in a middle circle that has linguortals viewing into three surrounding areas. But there's no dividing line you can draw that will not cut across at least one of the portal areas, so it's impossible to build a separate nodes tree for each.

The duplicate nodes tree idea should in theory solve this problem as even though one of the areas would be cut into two subsectors, those subsectors ultimately end up together in the parallel tree.

Linguica said:

On a related topic, one thing I don't understand is why every node builder (to my knowledge) always chooses linedefs as partition lines. As far as I can tell, there's no reason why this MUST be the case, and yet it's always been treated as a hard-and-fast rule. If you treat partition lines as being able to be totally arbitrary it would make things easier (e.g., making up a partition line separating two domains), but I don't know if there is some reason why this is a bad idea that I don't know about.

I've wondered the same thing and I have no idea. My best guess is: it's established that you want to choose dividing lines that minimize the number of splits. If you choose a linedef as the dividing line then you're by definition using the edge of a sector, so there's a good chance you're not cutting across anything. Plus it's just really hard to think of an algorithm for choosing better lines.

Well, if you're not doing the method where you move the segs into position, then yeah, I guess that could happen.

One thing that helps is that to the best of my knowledge, the engine only ever traverses the BSP tree in relation to the player's position, so if you have areas that you can effectively guarantee are outside of where the player is supposed to traverse, you can just ignore those areas when starting to build the BSP tree, and only take them into account when building the tree for that particular linguortal. Which I guess is probably basically what you're suggesting.

kb1 said:

Again, yeah, agreed. Graf's main complaint is that ZDoom no longer uses the structures that make this work for it's rendering (if I'm not mistaken), so the renderer would have to be reverted back to running the way every other software port runs. Though, it seems to me that ZDoom's philosophy is to be able to render every idTech1 map in existence...

Let me be clear here: ZDoom uses a vastly enhanced version of the original Doom renderer. If you think it's something else, you're just misguided. There is some build code, but the drawing process is exactly like vanilla. (You can verify this by watching Edward850's video of the rendering process.) Looking at the description of what the build code touches I wouldn't be surprised if some of that was to blame for the fake SEGS not rendering right, but while I haven't verified it sounds like the other ports are having similar problems anyway.

ZDoom does not fudge the nodes if they're in a usable state. Gez already covered the conditions where ZDoom will run ZDBSP on the map and the most common reason is because the user wants a textured automap. That particular feature requires GL nodes, and ZDoom must use the GL nodes for rendering as well in order to mark visibility on the automap. With that feature off, even the classic E1M1 slime trail appears in ZDoom (and I do recall getting a few bug reports about it that were closed even though we could technically fix it by rebuilding the nodes). Unless there's some easy way for ZDoom to bridge linguortals into native portals, it is very unlikely at this point that ZDoom will attempt to detect and disable the textured automap for this feature.

With all that said, if the nodes are constructed in a proper tree (unlike portal2, which triggers a sanity check which I assume is there to prevent infinite recursion. Make no mistake though, the map does "work" if the check is removed), and if the fake seg drawing issue is a trivial fix I see no reason why ZDoom wouldn't support the trick provided that the user manually turns off the textured automap feature.

I am a little amused that people in this thread make it feel (could just be in my head) like they're trying to turn this into some kind of win for other ports like EE considering the first one to mention this not being supported in advanced source ports was Quasar. Until Graf started stating outright that GZDoom won't support it, the only thing those of us from the ZDoom camp were saying is "uhh, it works 'fine'".

I personally think it's a pretty cool trick. Would rather that people not use it for obvious reasons, but I can see it's starting to come a point where it's looking pretty inevitable.

Oh and one thing that probably isn't clear from this thread is that these portals have much more strict visibility requirements (at least at this point in the game, maybe it can be improved via actual node building?). People give ZDoom's portal implementation a lot of flack for not working the way they expect. If you run portal2.wad in ZDoom (after compiling out the sanity check) you can stand at a point to the left of the portal and see the portal bleed. On that note:

kb1 said:

EDIT: I sure would like to hear SoM's and Quasar's take on this. After all, Eternity is the king of Portals. Specifically I wonder if Eternity is kinda doing this same thing, at runtime in the engine.

While I can't speak for how EE's renderer works, linguortals don't really work anything like portals in ZDoom. For ZDoom the scene is rendered as normal except for the portal surfaces. For each portal surface a clipping region is setup, the camera is physically moved to the portal location, and the renderer is rerun as normal. In Edward850's renderer video there is one map which has a mirror that shows this. (Mirrors are pretty much just portals.)

By the way, if you haven't seen yet ZDoom may be able to give EE a run for its money regarding portal support. Got to get around to reviewing the pull request for the visual side of that.

So, if you translate the segs, this will require the areas to be entirely separate? You cannot have a linedef point to a remote area of the same playable space, like a camera? If so, then I'm afraid this trick is purely cosmetic and not far away from real life holograms or stereoscopic television.

printz said:

So, if you translate the segs, this will require the areas to be entirely separate? You cannot have a linedef point to a remote area of the same playable space, like a camera? If so, then I'm afraid this trick is purely cosmetic and not far away from real life holograms or stereoscopic television.

No, it cannot function like a camera. Everything is still rendered from the player's viewpoint, vanilla Doom doesn't have any way to change that.

Yeah, it's "purely cosmetic," sorry if you thought I somehow unlocked actual portal technology in the Doom engine.

Linguica said:

Well, if you're not doing the method where you move the segs into position, then yeah, I guess that could happen.

No, it also applies in the seg-translation case as well. The translated area needs to all be contained within a single BSP branch. It's not quite so bad, because you can theoretically just bomb out with an error and tell the user to spread the level out more. But it's nice to have a solution that can just work without the user needing to have to move things around.

One thing that helps is that to the best of my knowledge, the engine only ever traverses the BSP tree in relation to the player's position, so if you have areas that you can effectively guarantee are outside of where the player is supposed to traverse, you can just ignore those areas when starting to build the BSP tree, and only take them into account when building the tree for that particular linguortal. Which I guess is probably basically what you're suggesting.

Not really - I'm actually proposing the opposite. The linguortal areas need to be part of the normal BSP tree in their usual expected positions, otherwise things can't be spawned in them.

Linguica said:

On a related topic, one thing I don't understand is why every node builder (to my knowledge) always chooses linedefs as partition lines. As far as I can tell, there's no reason why this MUST be the case, and yet it's always been treated as a hard-and-fast rule.

Years ago I was doing that in GLBSP. Picking the initial partition lines takes up most of the time of building nodes on a complex map, something like 50% of the time is just picking the *first* one (due to O(N^2) tests). So I had a version of GLBSP which picked an abitrary horizontal or vertical line for dividing the map, and when we got down to some number of segs (200 or so, from memory) then normal building kicks in.

Then DaniJ said that Doomsday will break if the partition line does not belong to a real linedef (WTF), and I thought other source ports might have trouble too, so I implemented a compromise solution where we find a real horizontal or vertical linedef that is close to the ideal splitting line. Works quite well in practice since most maps are a majority of axis-aligned linedefs.

BTW thanks for the detailed explanation of this neat trick.

fraggle said:

Not really - I'm actually proposing the opposite. The linguortal areas need to be part of the normal BSP tree in their usual expected positions, otherwise things can't be spawned in them.

I guess that's true -- R_PointInSubsector() has to traverse the BSP tree in order to link a thing into the right subsector / sector. I was still thinking about what I hereby deem the "proper" linguortal and not the earlier two-bit imitation version.

Both are potentially useful to be honest, and both have benefits and drawbacks.

Linguica said:

Works in Crispy Doom: NO

This is because Lee Killough's P_RemoveSlimeTrails() function attempts to move vertices back to where they belong.

Edit: fixed in GIT

Now, I wonder if somewhere in the archive (or outside of it), some obscure 1994 map exists where its author had discovered this cool, neat, novel "camera wall" effect (either by trial & error, or by accident with an early node builder), but it went undetected all those years...

fabian said:

This is because Lee Killough's P_RemoveSlimeTrails() function attempts to move vertices back to where they belong.

Edit: fixed in GIT

My gut told me the slime trail correction might be part of the problem... deal is, I don't think anybody wants that removed from the engine for the sake of supporting a data hack.

Maes said:

Now, I wonder if somewhere in the archive (or outside of it), some obscure 1994 map exists where its author had discovered this cool, neat, novel "camera wall" effect (either by trial & error, or by accident with an early node builder), but it went undetected all those years...

I was wondering that myself :) Once upon a time, the self-referencing sector trick in UAC_DEAD was an editor-breaking hack...

Quasar said:

My gut told me the slime trail correction might be part of the problem... deal is, I don't think anybody wants that removed from the engine for the sake of supporting a data hack.

Fabian's fix tries to be a best-of-both-worlds situation and not a complete revert of Lee's heuristic.

Jon said:

I was wondering that myself :) Once upon a time, the self-referencing sector trick in UAC_DEAD was an editor-breaking hack...

Fabian's fix tries to be a best-of-both-worlds situation and not a complete revert of Lee's heuristic.

I was thinking of possible work-arounds and a distance based metric was the first thing that came to mind. I didn't bother checking his implementation though :V To be frank you could probably even go tighter than 8 units since the kind of error the slime trail correction is meant to fix is usually a single-unit drift caused by the chopping of vertices to integer precision during BSP building. But, 8 is a pretty good threshold too because, A., this kind of special effect would never be built that close to its destination and B., it's definitely larger than a slime trail fix move should ever be.

ZDoom's problem is a different one, but not that hard to fix: screenshot

Will most likely fix the issue soonish, got more important things to do right now (screen shot isn't of a conditional fix and causes problems elsewhere). To be clear though, what I said in my last post about it requiring users to turn off the textured automap manually still holds. Unless a similar hack can be done against precomputed GL nodes anyhow.

Damn I think these tricks are really sweet. Doesn't matter if they are unintended side-effects of hacking what the engine never did to begin with. The sheer potential of these types of tricks is enough to make me feel the need to learn everything about this when I get off work here in a few hours. This is reason enough for me to get more interested in mapping specifically for chocolate/vanilla, or even prboom for a couple of these. Though I bet I could recreate some in ZDoom through other means, without scripting. With scripting, it seems like these should be unnecessary to employ in this fashion, making any arguments about zDoom or more advanced ports breaking the behavior somewhat less pertinent.

Looking forward to more of these tricks, Ling!

Welp here's another visually not very impressive one



Was working some more with how to make linguortals that don't break when you walk through them and how to string them in a sequence to make the effect of changing geometry. I just changed textures in this WAD to save myself the trouble of dealing with more hacking, so it's less impressive looking, but you could make any and all of the architecture around the player instantly change as he walks over a line.

I also tested if you could make sprites show up through linguortals, and the answer is yes - sprites are drawn by sector, not by subsector, so if you merge sectors together you can have sprites be drawn across linguortal views.

As a byproduct, because I didn't do any vertices hacking, this one happens to work in PrBoom et al.

http://www.doomworld.com/linguica/hax/portal4.wad

I realllly need a tool to automate some of this stuff if I want to keep playing with it, because it legitimately wears out my brain trying to get this stuff working by hand.

Can you have basically 2 completely separate BSP trees? And, what about building a compound tree, from 2 maps.

In other words, you create 2 separate maps, and run an (almost) standard BSP build on them.

Then, a separate tool joins both BSP trees together, insuring that they use unique identifiers. This tool would also be responsible for hooking the two trees together, using the lingortal method.

This way, the BSP build is rather standard - guaranteed to not split across the portal.

(Note: I have no idea what I'm talking about for the most part - it's a conceptual idea only.)

Blzut3 said:

Let me be clear here: ZDoom uses a vastly enhanced version of the original Doom renderer. If you think it's something else, you're just misguided. There is some build code, but the drawing process is exactly like vanilla.

There's that word again: 'misguided' - where have I heard that before? So far, you are the first person to guide me through ZDoom's renderer, in this post no less. I'm not sure how it can be 'vastly different', and 'exactly like vanilla' at the same time...

My comment about ZDoom is based on the fact that doom maps have redundant info in SEGS, and that ZDoom stopped using one or the other at some point in time. In fact, ,if I'm not mistaken, for a while ZDBSP was not writing this info, which caused grief for non-ZDoom users.

Based on your post, however, maybe that doesn't cause issues with Lingortals.

Blzut3 said:

By the way, if you haven't seen yet ZDoom may be able to give EE a run for its money regarding portal support. Got to get around to reviewing the pull request for the visual side of that.

"Run for its money?" It's not the Olympics - is this a competition?

Linguica said:

I realllly need a tool to automate some of this stuff if I want to keep playing with it, because it legitimately wears out my brain trying to get this stuff working by hand.

What do you need?

kb1 said:

Out of curiosity, is English a second language for you? I dunno if you're just be intentionally overly literal or just lack the experience to not take idioms like standard phrases.

kb1 said:

Can you have basically 2 completely separate BSP trees? And, what about building a compound tree, from 2 maps.

In other words, you create 2 separate maps, and run an (almost) standard BSP build on them.

Then, a separate tool joins both BSP trees together, insuring that they use unique identifiers. This tool would also be responsible for hooking the two trees together, using the lingortal method.

Read my earlier comments. This is kind of similar to what I was suggesting.