Wall portals

[Graf Zahl]

Please wait. I'm still working on the interface. It still needs a bit of extending.

The third parameter is actually quite simple: It specifies how the two sides of a portal align:

If it's 0, z coordinates are not changed when offsetting the coordinate. The map is responsible for doing it right.
If it's 1, the two sides of the portal will be aligned so that the floors match up,
and if it's 2 the two sides of the portal will be aligned so that the ceilings match up.

I also added a fourth parameter to define the portal type, but that part is not finalized yet.

I imagine 4 types of portal:

1. visual only, i.e. no gameplay interaction
2. visual plus pure teleporter. This will only trigger if some actor actively moves into the portal
3. interactive: Will be considered for most gameplay interactions but most likely not possible on polyobjects due to complexity explosion in the playsim code. How much of the AI can handle this remains to be seen, as this may incur some non-trivial calculations in code that cannot handle this.
4. static linked: Just like Eternity has, with all the same limitations and benefits derived from these limitations. In general that means that these are far cheaper on the playsim code and allow easy relative positioning of sound between two sides of a portal.

and for definition only an EE compatible way to define portals (because using Hexen format the Eternity way is far from ideal.

But be aware that this is still subject to change, if during development we notice that something different is needed. For now only type 0 is supported anyway, so if you document it, it should be stated that the fourth arg should not be set to any value other than 0!

[Gez]

Please wait. I'm still working on the interface. It still needs a bit of extending.

The third parameter is actually quite simple: It specifies how the two sides of a portal align:

If it's 0, z coordinates are not changed when offsetting the coordinate. The map is responsible for doing it right.
If it's 1, the two sides of the portal will be aligned so that the floors match up,
and if it's 2 the two sides of the portal will be aligned so that the ceilings match up.

So, 0 is used if the same floor and ceiling heights are found on both sides of the portal (e.g. floor 0, ceiling 128), but if there's a difference (e.g. f 0 c 128 on one side, f 128 c 256 on the other) then 1 or 2 must be used? And if the ceiling - floor height is the same on both sides, 1 and 2 are functionally equivalent?

[Eevee]

But if polyobjects are taken out of this equation we can generate a portal blockmap upon map start, and for each block only store the known portal lines, and if none are there, some distance values in each direction to the nearest portal. That'd allow very quick and efficient detection of the common case where no portal checks is needed. A constantly moving polyobject portal would put some enormous drag on these checks.

This seems like a shame to lose. Is it possible to take a hybrid approach, with the static blockmap you describe plus realtime checks for moving polyobjects? If portal lines have to be predeclared in the map, you'd know ahead of time whether there are any on a polyobject, and the cost of moving portals would then only be paid by maps that actually use them.

[Graf Zahl]

What would you prefer? A working implementation that handles the sane cases well or something so universal and 'flexible' that the maintenance of the inane special cases makes it impossible to work in a usable fashion?

The blockmap issue is the smallest thing here, but moving portals will definitely render any attempt of true interactivity pointless - for the simple reason that they MOVE! As I said: The best I consider feasible is to treat them as pure teleporters. That's one place in the entire code where it needs to be checked and that one's manageable because it needs to to a full blockmap check anyway.

But the far, far bigger problem here is that polyobjects tend to consist of one-sided linedefs. I can promise you outright that allowing one-sided linedefs with portals to be passable is also an open invitation to strange unresolvable issues. The Doom engine was not designed to allow that and I think it was for good reasons that Eternity mandates an empty sector behind the portal to handle collision detection problems. I already have done some checks with the test map, and it definitely runs into some bad situations, including one crash.

If you ask me, the feature should be reasonably usable, not ultimately gimmicky - and that necessitates some restraint in the implementation. I'm going at it piece by piece, the first thing is to define the data structures that are needed.

[Graf Zahl]

So, 0 is used if the same floor and ceiling heights are found on both sides of the portal (e.g. floor 0, ceiling 128), but if there's a difference (e.g. f 0 c 128 on one side, f 128 c 256 on the other) then 1 or 2 must be used? And if the ceiling - floor height is the same on both sides, 1 and 2 are functionally equivalent?

If both sides have the exact same floor and ceiling height the parameter does not matter
If both sides have the same distance between floor and ceiling, 1 and 2 are identical.

Not that it matters much at the moment because the implementation cannot draw upper and lower textures on portal lines. But on GZDoom this will work and the different settings will have some meaning.

[hfc2x]

By the way, does the addition of these new portals, along with the revised mirror code affect the stacked sectors rendering?

[edward850]

It does not appear to.

[Graf Zahl]

Both features share no common code in the renderer. The wall portals mostly piggyback on the old mirror implementation and improve it.

[Graf Zahl]

So, I think I got the first round of cleanup and restructuring done. Right now I'm not in the mood to edit the Wiki, so here a quick documentation of Line_SetPortal:

156: Line_SetPortal(otherid, myid, type, align)

otherid is the lineID this portal links to, if this is <=0 or no line ID present, the portal will be inactive.
myid assigns a line ID to the portal linedef, obviously this applies only to Hexen map format. In UDMF the proper ID property needs to be set.

type:
0: visual only
(the following types do not work yet, they are purely visual right now.)
1: visual plus simple teleporter - no advanced checks. (this will obviously the first type that's fully working because it only needs handling in one function.)
2: interactive portal - can be at any angle, this will be considered by any position offsetting but due to complexity will have some limitations with AI because some non-trivial checks are impractical (e.g. sight checking through such a portal would be such an issue)
3: statically linked portal à la Eternity: All the same limitations apply: No change in orientation, and coordinate offsetting will require that two paths between two map sections must result in the same displacement offset. Static means that the upcoming portal manipulation functions can not reassign targets for such a portal - what's defined in the map will remain.
4: Eternity compatibility definition (The Eternity types do not map to the regular definition so a special version is needed to XLAT them.) Not recommended for Hexen/UDMF-Format maps. To link two lines using this, the first needs to be defined with Line_SetPortal(0, id, 4), the second one with Line_SetPortal(1, id, 4)

align: as above:
If it's 0, z coordinates are not changed when offsetting the coordinate. The map is responsible for doing it right.
If it's 1, the two sides of the portal will be aligned so that the floors match up,
and if it's 2 the two sides of the portal will be aligned so that the ceilings match up.


And to be able to test linked portal stuff with the Vaporware demo map I also added the Extradata parser I wrote for GZDoom a few weeks ago. Just in case someone wonders. I don't really expect this to become a usable editing feature but it'll certainly come in handy if some Eternity maps need to be tested for compatibility issues.

[Major Cooke]

What github commit would you say would be appropriate for the wiki?

[Graf Zahl]

ed7b7fc

The last one where I fixed the Eternity compatibility type. Everything before was still 'in construction'.

[Major Cooke]

http://zdoom.org/wiki/Line_setportal

[Graf Zahl]

I took out the Eternity compatibility explanation from Usage. Of course this page still needs to be improved but it should do for now.

[hfc2x]

Lol, I had already made an article for the special: [wiki]Line_SetPortal[/wiki].

[Edward-san]

The latest changes made the compilation fail:

Code: Select all

CMakeFiles/zdoom.dir/g_doom/a_doommisc.o: In function `A_PainShootSkull(AActor*, unsigned int, PClassActor*, int, int)':
/home/edward-san/zdoom/trunk/src/g_doom/a_doommisc.cpp:(.text+0x4c4): undefined reference to `line_t::isLinePortal() const'
/home/edward-san/zdoom/trunk/src/g_doom/a_doommisc.cpp:(.text+0x684): undefined reference to `line_t::isLinePortal() const'

but can be fixed by including portal.h inside a_doommisc.cpp ..