[Smikes]

Every source I've read on the Internet agrees: Duke Nukem 3D does not support true room-over-room.

Even in Alien World Order, Levelord used the teleportation trick to create the illusion of room-over-room on Prima Arena. Presumably, he did this because the Build engine doesn't support true room-over-room.

But every once in a while, I'll play a user map that *really* looks like true room-over-room to me. Here's a screenshot I took from the very end of Durango Club (first map of the Anarchy Village episode in FM4X by Fernando Marquez). You can clearly see the Holoduke in the top room, and you can see the Pig Cops walking around in the bottom room.



Can anyone explain this to me? How is this not true room-over-room?

[stillTodd]

Sprite bridge?

[Aleks]

TROR is supported in Eduke for quite some years already, there are certain complex SOS tricks that can create a seamless illusion of TROR, but the most common solution (especially for more simple geometries) is a spritework, i.e. horizontal and vertical flat sprites that would create some kind of "bridge" (even the simple bridge at the end of original E1L1). Probably this is also the case on the screen you posted.

[duke3d.exe]

Noticing by the unmatching resolution compared to the wall's textures looks like classic spritework. I always thought it was a crazy idea to use sprites to create 3d platforms but somehow Ken made it work on build.

[Tekedon]

But Duke3D Atomic edition DOES support TROR. Not used in the game though. Hightreason has used it in one of his maps, can't remember what it was called.

[Hendricks266]

Tekedon, on 12 December 2020 - 11:49 AM, said:

But Duke3D Atomic edition DOES support TROR. Not used in the game though. Hightreason has used it in one of his maps, can't remember what it was called.

I believe that would be one of the complex SOS tricks Aleks is referring to.

TROR did not exist until Helixhorned invented it for EDuke32 in 2011.

[High Treason]

Quote

But Duke3D Atomic edition DOES support TROR. Not used in the game though. Hightreason has used it in one of his maps, can't remember what it was called.

Not me, the only map I have using any form of ROR was Riverside, which used EDuke's own convoluted TROR implementation. EDF (god that map was horible) did use SE40s at one time, but it never worked right and was removed before it ever saw a release. Beyond that, it's all either spritework or renderer abuse.


I think there was code for a ROR system, not unlike those in other Build games, in the Atomic source code, but whether it was commented out or complete, I don't remember.

[Hendricks266]

High Treason, on 12 December 2020 - 12:50 PM, said:

I think there was code for a ROR system, not unlike those in other Build games, in the Atomic source code, but whether it was commented out or complete, I don't remember.

Yes, there is technically vestigial support for ROR in the 1.5 exe using SE40. This was not understood until very recently, maybe the past year. To get it to work you have to do some hackery so the engine thinks a certain tilenum has been drawn in the viewable area, despite that tilenum being empty in Duke's ART. Even with that in place the effect is still a bit crap.

[Ninety-Six]

I wonder what it's doing in 1.5. Plutonium was already out with 1.4, so was it tinkered with for mod support?

[High Treason]

Thought the guy who wrote ColorlessDuke were aware of it already years ago? May be misremembering and he'd written his own instead. The tile thing makes sense at least, given how most other effects are rendered to a tile like that (mirrors, afterimages, viewscreens).
I don't know if it was ever confirmed, but there were certainly rumors of planned updates to the existing levels - possibly in a version beyond 1.5 - but it never happened. Like most things, I suppose it was just another idea left on the cutting room floor for one reason or another, not unlike the few voxels that were made too.

Short of someone coming and confirming the actual intentions for such features, I can't help but wonder if they were never really meant to be used and, instead, were wedged in as a test in an already established game for one of the other Apogee teams, either those on Blood or Shadow Warrior, to get a feel for it in their own project. If course, it could just be bored artists and programmers who had nothing left to do, but were still on the payroll.

[MetHy]

Hendricks266, on 12 December 2020 - 01:05 PM, said:

Yes, there is technically vestigial support for ROR in the 1.5 exe using SE40. This was not understood until very recently, maybe the past year. To get it to work you have to do some hackery so the engine thinks a certain tilenum has been drawn in the viewable area, despite that tilenum being empty in Duke's ART. Even with that in place the effect is still a bit crap.

I've been doing some testing and the main issue is that one has to rely on SE7 for transport of the player and projectiles.
And while SE7 transports projectiles and things like pipebombs with no issue from top area to bottom area, the contrary seems impossible to be handled (the projectiles either get stuck on a loop or explode); unless maybe if you set the above teleporter so far apart it looks absolutely ridiculous as you get a jump in Z distance of several page ups. With tests using two sets of one-way teleporters weren't fruitful either.
Come to think of it, I don't remember any instance in DN3D when projectiles would teleport from low to high areas in such a way, for instance one can throw pipebombs underwater, but I don't think throwing them overwater works, but I could remember that wrong.

On top of this issue, the angle of things rockets gets wrong once teleported. Instead of seeing the back of them, you see their side.

Other than that, in terms of architecture, in theory, SE40 should allow the exact same kind of advanced ROR you can pull with Shadow Warrior ( unless it's not possible to pile up rendering passes like one can in SW?), since the mapper has control on where/when to flatten the other floor's sectors and when not to do it, the system is pretty much identical. Here is the explanation for the SEs which Oasiz pulled from the source I think

Quote

// If standing in sector with SE42
// then draw viewing to SE41 and raise all =hi SE43 cielings.
// If standing in sector with SE43
// then draw viewing to SE40 and lower all =hi SE42 floors.
// If standing in sector with SE44
// then draw viewing to SE40.
// If standing in sector with SE45
// then draw viewing to SE41.

However, the whole thing is a lot more buggy and seems even more of a hassle to set up than SW's ROR.

Ninety-Six, on 12 December 2020 - 01:12 PM, said:

I wonder what it's doing in 1.5. Plutonium was already out with 1.4, so was it tinkered with for mod support?

maybe they removed it for 1.4 but forgot to do so for 1.5

High Treason, on 12 December 2020 - 02:12 PM, said:

Short of someone coming and confirming the actual intentions for such features, I can't help but wonder if they were never really meant to be used and, instead, were wedged in as a test in an already established game for one of the other Apogee teams, either those on Blood or Shadow Warrior, to get a feel for it in their own project. If course, it could just be bored artists and programmers who had nothing left to do, but were still on the payroll.

I remember an interview of a DN3D dev where he mentionned working with ROR for a Duke related project. I don't remember the specifics, all I remember is reading something like "one point we had ROR over ROR over ROR, as much as the CPU can handle".
IIRC this was stuff experimented on after Duke's release, whether it's after 1.3 or 1.5 I can't tell.

Edit: BTW - I'm pretty sure that RR and RR:RA's ROR (not the "3D object" thing, the SE150 one) is SE40; except that they fixed those issues regarding SE7 teleporting and on top of this added support for hitscan to go through the portal as well.
Nuke.YKT could confirm this; and if it's true, iirc Redneck Rampage is based on a version of Duke in between 1.3 and 1.4, meaning that SE40 would have indeed existed for 1.4 and was removed for the release.