Welcome to the ZDoom Forums!

Well, in GZDoom with OpenGL it runs at full 85 fps for me...

For the record, that room in particular hasn't exactly given me wonderful performance at any point, and considering the room's nature, it was probably a mistake to do it that way. If push comes to shove, I'll gladly fix the map and make a quick re-release if performance remains too terrible after all the portal changes.

[quote="Graf Zahl"]
I was planning to add merging code for GZDoom tomorrow to make maintenance easier. I'll backport that to ZDoom and see if it helps. I noticed these problems myself, in particular in Zendyn MAP04. Inside the church ZDoom degenerates to a slideshow.[/quote]


Sadly that did not help much. It provided a mild speedup in Zendyn but it's far from solving the performance problem. However, since it does seem to help a little I'll leave the code in.

Great! I hope the [wiki=Sector_SetPortal]wiki article[/wiki] is clear and correct.

Ah, good to know. I didn't see that in the Wiki. That's 'Sector_SetPortal(0, 1, ceiling, portaltag)' now. You can also do multi-sector transfers with 'Sector_SetPortal(sectortag, 1, ceiling, portaltag)'.

In Eternity, line type 385 transfers the tagged portal to the sector that the line's front side faces, so you can put lifts and such beneath portals without needing to set up another tag for it.

Please don't ask me about performance in the software renderer. However, it wouldn't surprise me that the problems come from the fact that the old method with its countless stack things just creates way too much overhead because effectively each single sector is a separate portal. No idea how that affects performance.

I was planning to add merging code for GZDoom tomorrow to make maintenance easier. I'll backport that to ZDoom and see if it helps. I noticed these problems myself, in particular in Zendyn MAP04. Inside the church ZDoom degenerates to a slideshow.

I also realized that this feature requires one more option: Transfer an already set up portal to a sector with a different tag. Eternity's system is certainly better than ZDoom's but it still allows no active sectors below a portal unless there's multiple portals.

I used rf_kerkr.wad to test this, btw. No need to say that in ZDoom this is HOM central. But in GZDoom I think I can make that level work with a few days work.

Oh, nice. Having to set up tons and tons of upper/lower sector things was a huge pain; this method is generally preferable.

I realize it's not directly related, but do you have any idea if there's anything that can be optimized in ZDoom's software rendering of portals? I'm not asking about the HOM stuff, but the speed issues...for some reason, portals in some circumstances can cause massive framerate drops in ZDoom, even sometimes if they're not all that complex. TSoZD has had some problems with this.

298 = 0,		Sector_SetPortal(tag, 0, 1, 0, 0)
299 = 0,		Sector_SetPortal(tag, 0, 0, 0, 0)
295 = 0,		Sector_SetPortal(tag, 0, 1, 1, 0)
296 = 0,		Sector_SetPortal(tag, 0, 0, 1, 0)

Done, sort of. But I decided to do it in a manner that's compatible with Eternity so this does not use stack points in the map anymore but links two sidedefs together. It also allows one-way portals unlike the stackpoint method which is always two-way.

Here's how it works:

There's one new line special (57: Sector_SetPortal(tag, type, ceiling, link, alpha)

tag: sets a sector tag for all sectors in which the portal is to be set.
type: reserved for later use. Must be 0 or nothing will happen
ceiling: 1 for ceiling, 0 for floor
link: For each portal two lines must be linked. The first 3 parameters need to be identical for these 2 lines. This one must be 0 for the place where the portal is anchored to and 1 where it is defined.
alpha: Translucency of portal plane

Obviously this uses the existing implementation so all the limitations concerning visibility clipping still apply here as well.

And for those who are interested, Eternity's line types translate as follows:

[code]
298 = 0, Sector_SetPortal(tag, 0, 1, 0, 0)
299 = 0, Sector_SetPortal(tag, 0, 0, 0, 0)
295 = 0, Sector_SetPortal(tag, 0, 1, 1, 0)
296 = 0, Sector_SetPortal(tag, 0, 0, 1, 0)
[/code]

Yepp, this must be added! Definitely!

I can imagine that being tough to implement, but very cool, too. I'd have to say that I could use something like this, and I'm usually behind on features.

There is a [wiki=Sector_SetLink]feature to link together sectors so that they move as one[/wiki]. I'd like the same thing to link them so that they're a single portal for [wiki]stacked sectors[/wiki] purposes. Rather than using dozens and dozens of [wiki=Classes:StackPoint]stack points[/wiki] in the upper and lower areas, there would be just one for each, and all the sectors would be linked together by having the same tag. As far as portals are concerned, they would be just one sector. There could be a restriction that the concerned surface (floor or ceiling) should be at the same height in all concerned sectors.

This would permit to avoid many HoMs in maps with complex 3D architecture.