Hacker News new | ask | show | jobs
by ColinDabritz 763 days ago
There was an example of this in the classic 'Duke Nukem 3d'. It had a level by Richard "Levelord" Gray, 'Lunatic Fringe'.

https://dukenukem.fandom.com/wiki/Lunatic_Fringe

This level had a circular hallway ring around the outside that had two full rotations around without intersecting, using the 'build' engine's ability to separate areas by their room connections that also drove the 'room over room' technology which was groundbreaking at the time.

It made for fun multiplayer, and the illusion held well there. The central chamber has 4 entrances/exits if I recall, and you would only encounter two of them in each loop around the outside.

I recall building a toy level while experimenting with the engine that "solves" the "3 houses with 3 utilities without crossing" puzzle using this trick as well.

10 comments

In what sense is the Duke Nukem thing "an example of this"? The duke thing is an internally consistent programmed behaviour, this is... just random errors caused by a random change in the source code. Duke is maybe non-euclidean geometry, or something. This doom pi thing is... nothing to do with geometry. More an example of "garbage in, garbage out" maybe.
It's an example of "non-euclidean" space, and yes, it is a bit different than the article.
The DN example would be an instance of non-Euclidean topology whereas the other one is presumably non-Euclidean geometry.
> the 'room over room' technology which was groundbreaking at the time.

Bungie's Marathon from 1994 could also do this and demonstrated it in the deathmatch map 5-D Space[1]. It was really only Doom that bugged out on overlapping sectors.

[1] https://www.lhowon.org/level/marathon/30

I wrote a little engine with this capability a long time ago. I didn't know about the Build engine at the time. I divided the world into convex sectors and allowed arbitrary links (portals) instead of following a BSP tree. Rendering is front-to-back and clips at the portal boundary.

If you can rasterize the inside of a convex shape, you can rasterize a sector-portal-world by marking certain faces as portals, and when rendering one, setting the clipping region (or stencil buffer) to where the face would be, then rendering the sector behind it with an appropriate transformation (which is part of the portal's data, alongside the ID of the other sector).

Collisions through portals are much harder than rendering through portals.

Room over room (as done in later build games) usually does not require the sectors to overlap in this manner as it is a different thing (it is extension of how swimable water works, where the engine renders the other sector instead of floor/ceiling).

While Lunatic Fringe is pretty in-your-face example of impossible geometry in build, the duke3d maps contain many more cases of intersecting geometry. Obviously such things are impossible in Doom because there is no way to build BSP tree out of that and because doom only tracks X/Y coordinates of player(s)/monsters.

Sure you can do this in doom, or at least it can be done in modern source ports.

https://www.youtube.com/watch?v=Iq1-TZXz9xo (myhouse.wad)

There is nothing about the data structures ID choose to use in doom that prevent portal shenanigans. ID(John Carmack) just did not implement them.

Modern source ports are a totally different thing. If any, try to do what the former comment states with a Boom compatible engine as Crispy Doom or Chocolate Doom.
You're confusing things a bit here, Boom is already an enhanced port and it got the kind of line-to-line teleport that allows you to do this.

Crispy and Chocolate Doom are what the community calls "vanilla" Doom, with no enhancements at all.

That said, if you are willing to hex-edit the map data, you can have non-euclidean geometry in vanilla Doom: https://doomwiki.org/wiki/Linguortal

Crispy Doom will play most Boom compatible levels just fine. I tried it with some Megawads, and I had no issues, even with FreeDoom as the IWAD.

No, I'm not confused. To me, Boom it's pretty close to vanilla. Zdoom and the rest are pretty much another league, closer to Quake/HL than Doom.

No mention of the real Prey (2006) in a discussion of weird geometry in games?
I was truly amazed by this game! You don’t see anything like that elsewhere
The portals in prey were cool but, definitely the games Portal and Portal 2 are places you could see it elsewhere. Also in portal you can actually choose where the portals are, whereas Prey's portals were fixed in place
Is there no way of building a BSP out of it? I don't see why it has to be Euclidean to be partitioned, and loops are also possible (e.g. Deimos Lab). (The coordinates are definitely a blocker, so this question is academic.)
The “sectors” in the resulting level data have to be convex for the doom engine. The “asset pipeline” handles that by breaking up non-convex geometry into smaller convex sectors. So, there are no loops or holes in the actual level data, also from the cursory glance both of the large loops in Deimos Lab are actually not complete loops, but they have a place where the loop is broken. But that does not matter that much, as almost any level contains geometry that is either concave or has a hole (courtyard in E1M1, both large rooms in MAP01…)
The Doom design starts with X,Y,Z and then finds your BSP node. You can't warp to a different X,Y,Z without some type of warp portal which doesn't exist in Doom. Modern Doom forks have this feature and also have graphics portals so you can implement this (as MyHouse.pk3 does).
> only tracks X/Y coordinates of player(s)/monsters.

It does, otherwise Lost Souls and Cacodemons wouldn't able to fly.

I meant that as in contrast to build tracking the sector the thing is in. Due to that you can have two sectors that intersect not only in 2D, but even in 3D and the engine still does the right thing (ignoring the fact that the renderer gets slightly confused when there are overlapping sectors in the view)
Portals allow weird stuff (non linear geometry) in a BSP level. I thought Doom had petals.
The primary thing that BSP does is that it maps coordinates onto a BSP node/sector. Thus you cannot have overlapping geometry, as this mapping would not be unique. Quake has some idea of portals (I'm not sure about Doom), but it is used only as an additional layer of optimization, the engine is not fundamentally portal-based.
There is a very interesting Doom level named “myhouse.wad” that does a lot of clever things to seemingly allow room-over-room.
I don't think that mod works on a normal Doom engine.
There is an interesting VR game called "Tea For God" that puts you in your play area, and cleverly creates new corridors and rooms as you make it around the corner or lift so there is an illusion that you are in a very vast place, despite never leaving the same room, all without using the joystick or teleporting.
I remember a Descent PVP level that was a big room with a corridor that came off of one end and went to the other by looping back through the main room but was not visible inside of the main room. Was a bit of a mindbender in a game that already stretched the players spatial awareness.
This video does a good job explaining it, yes it really is quite mind-bending.

https://www.youtube.com/watch?v=UitzmhJe578

> the "3 houses with 3 utilities without crossing" puzzle

In graph theory's terminology, this is "K3,3", one of two irreducible nonplanar graphs. The other one is K5.

You can also make all the connections without crossing any edges if you embed the graph in a torus, which is equivalent to building a bridge over some set of edges that other edges are allowed to take.

I spent so much time back in the day working with build. In many ways it was super easy (and fun!) to use.

Thanks for the throwback!

> also drove the 'room over room' technology which was groundbreaking at the time.

Descent did this in 1994.

Descent was a polygonal game though, Duke3D was a raycasting engine. It was the first four a raycasting engine, and quite impressive.
Duke3D isn't a raycaster; it's a portal-based quad rasterizer. Wall quads are forced vertical, and floor quads are rasterized using a neat trick. The renderer computes successive lines of constant distance along slooped floor surfaces, then draws textures using affine scaling, which is correct along those lines. The portal walls clip the draw of successive sectors, which solves the hidden surface problem.

https://fabiensanglard.net/duke3d/build_engine_internals.php