SE40 ROR in Duke3D (DOS atomic only)

SE40 ROR in Duke3D (atomic only)
Thanks to NukeYKT for bringing this up to my attention few years back, now I finally got around to checking it and it's quite more capable and strangeer than I thought originally!

There are a total of 6 reserved SE Lotags for this but don't get too alarmed, you essentially have 3 roles and they're doubled up due to 2-way operation.

First of all, you have two cameras, SE40 and SE41.
These are sort of like your pairing points for other SE 44-45 which we'll get to in a moment.
If you're worked with Shadow Warrior or SE40 in source ports then you'll have some idea on how this works..
This is essentually a very basic implementation of that idea.

ROR in the simplest terms is like layers in photoshop:

Put the player 1:1 where the camera is
Take a screenshot
Go back where the player is
Take a screenshot but leave any "ROR surfaces" with 100% transparent cut-outs just like in image editing
Combine layers with the "camera" on lower priority.
DONE

This operation is done pretty much exactly like this, which is why it can be a performance hit.
And as you might've thought, any objects in the camera sector which are in the camera's line of sight will occlude as usual!
Essentially it works exactly like mirrors do in the game but doesn't attempt to simply point back to the same area you're in.

Let's go with the simplest construction example:
You want to see area B from area A
This means that area B must have a camera that can project what's there.
We'll make this B camera exist as SE41.
In this example:
A = Top floor
B = Bottom floor

Now how to see this projection?
Just like camera, you have two SEs (SE44 SE45., Think of these both as "Enable rendering of ROR camera if player is in this sector"
Essentially how the game works is that EACH sector where a camera should be seen, you should always have a pair of camera+render-ror.
Pairing is done with the usual Hitag of a SE sprite.
Few things to keep in mind:

Each sector that is able to see the ROR must have it's own pair
ROR Sector (in play area) must have picnum #13 or the ROR will not iniate.. Same sector as SE44 in this example
SE angle MUST point down (512) or the whole ROR code will be skipped (I don't know why!)
The effect does NOT take relative height of sprites into account. Construct areas A/B in a way that works with real in-editor height differences.
Camera will be blocked by anything that's in the way, This is where you have SE42/43 to work around this problem.
Any SE42/43 Raised ceiling/lowered floor will a hardcoded distance that is pretty far away from the sector's original position

For pairing, If looking from area A (Top) to Area B (Bottom).. Do these:
[A]

For each sector, SE44 with an unique Hitag
Any see-thru floor should have picnum 13

[B]

For each sector, SE41 with a matching Hitag
For each sector whose ceiling should be raised during drawing (only when seen through ROR), insert a SE43, where hitag=(SE44 hitag that should control it)

And you can use SE40/42/45 for the other way around.
Technically top/bottom doesn't matter but SE43/42 can ONLY work with either floor or ceiling, making it rather useless if using the wrong pairs.
You can't for example use SE43 to raise ceilings if ROR rendering was triggered with a SE45

TL;DR here is a video and see attached map

Attached File(s)

rortests.zip (4.39K)
Number of downloads: 11

Duke4.net Forums: SE40 ROR in Duke3D (DOS atomic only) - Duke4.net Forums

Choose a header image