[jasonwatkinspdx]

The way the underlying engine works is what's significant, not that it's a dynamic game design element. Descent levels are just a graph of cubes where a portal rendering algorithm runs per cube instance in a flood fill that spreads from the camera origin until there's no more unclipped portals visible on the screen. You could totally make a portal gun mechanic in that engine, they just didn't want to. Well beyond the hatches that open and close, which do case an end to the portal rendering cell walk when closed.

There's nothing particularly novel about Portal (the game) style portals in rendering. Racing simulators did the exact same thing for rear view mirrors for decades prior. It's just another transform in the scene graph clipped to a subscreen area.

[hypertele-Xii]

We are still not talking about rendering. Rendering portals is trivial, and as you say, is the basis of nearly all 3D engines as a means to figure out what to draw. But that info is compiled as the visibility graph into the game map data structure and cannot be modified in realtime.

Narbacular Drop is like, literally the first 3D game ever released that allowed dynamic creation of portals at runtime.

[jasonwatkinspdx]

I am aware of what you're saying. Please reread what I wrote a bit more carefully and charitably. Dynamic portals are not a precedent worth talking about.

[hypertele-Xii]

> Dynamic portals are not a precedent worth talking about.

Dynamic portals are literally the topic of this specific thread of comments. Here's the bit I originally replied to:

> [Prey] had portals before Portal.

Then you showed up conflating dynamic portals with compile-time map rendering, and now you're saying that dynamic portals, the very subject of this discussion, aren't worth talking about, because static portals, the preceding tech, existed earlier, even though dynamic portals clearly introduce fundamental design space as popularized by the critically-acclaimed game Portal.

The word "render" appears in your reply to my first comment six times, which is a lot in a discussion that is not at all about rendering.

Please correct any misunderstanding here on my part.

[jasonwatkinspdx]

> Then you showed up conflating dynamic portals with compile-time map rendering,

I did not. Reread.

"Dynamic Portals" as you term them are nothing more than the combination of a transformation matrix and a screen space clipping region in the context of a recursive approximate depth first renderer, a combination that was utilized by MANY MANY games before the one you're apparently cheerleadering. And this is exactly what I'm talking about, but you're failing to catch the specifics of what I'm actually saying out of apparent defensiveness over this one game.

[hypertele-Xii]

You still don't understand what a dynamic portal is, what it does, or why it's distinctly more useful than compile-time portals.

You are still stuck repeating "renderer", even though rendering is still not the topic of discussion here.

No amount of recursive matrix transformations will net you the gameplay design space of actual dynamic portals.

[jasonwatkinspdx]

edit: nevermind, it's just not worth trying