How do I replicate "Hall of Mirrors Effect" in GZDoom OpenGL?

[asd1994]

I know it's a weird question since it's the kind of thing level designers try to avoid, but its honestly really cool looking! I wanted to use this effect in a non-euclidean styled map using portals and stuff, but it only works in the software render. I was wondering if it would be possible to replicate this effect in GZDoom using the OpenGL render, or at least have something similar. Any suggestions?

Edited April 9, 2019 by Skully Boots

[asd1994]

Nobody? :(

[Gez]

Nope, not possible, because the buffer is always cleared now.

[Kappes Buur]

Just as Gez mentioned, HOMs are no longer displayed in recent versions of GZDOOM.

From the WIKI

 

Quote

r_clearbuffer (integer)

Default: 0

Clears the framebuffer between each frame. Several values are possible:

0: By default, do not clear the buffer. This allows the hall of mirrors effect to happen in certain conditions. Since the variable is not archived, it is reset to this value whenever ZDoom is run.

1: Fill with black. This prevents HOMs and will generally make the affected area less noticeable.

2: Fill with white. As with black, though the areas will generally be more noticeable.

3: Fill in alternation with black and white, making the areas flash and helping them be more noticeable. This is roughly similar to Boom's TNTHOM "cheat".

4: Fill with each color of the palette in sequence, creating a pulsing effect.

5: Fill with a random color. Seizure warning!

 

Mind though, in my tests even the default of 0 results in a black wall,

 

If you absolutely have to use GZDOOM, then you have to turn back the clock and use an ancient version of GZDOOM, or resort to using one of the other ports which proclaim to render in the original DOOM style.

Edited April 11, 2019 by Kappes Buur

[Dark Pulse]

The only thing I can think of would be possibly doing it as some kind of shader effect, but past that I really have no idea.

[Edward850]

1 hour ago, Kappes Buur said:

If you absolutely have to use GZDOOM, then you have to turn back the clock and use an ancient version of GZDOOM, or resort to using one of the other ports which proclaim to render in the original DOOM style.

Even fully vanilla compat ports don't all conform to the same buffer behaviour with HOMs. Vanilla Doom had 3 buffers it swapped between, most ports only stick with 1 making the effect more static. It's frankly not a good rendering "effect" to rely on.

Edited April 11, 2019 by Edward850

[Bauul]

11 minutes ago, Dark Pulse said:

The only thing I can think of would be possibly doing it as some kind of shader effect, but past that I really have no idea.

 

That's what I was thinking, you might be able to write an OpenGL shader that mimics the same effect. You'd need to find someone who knew how to write such things though. 

[Jon]

13 hours ago, Edward850 said:

Even fully vanilla compat ports don't all conform to the same buffer behaviour with HOMs. Vanilla Doom had 3 buffers it swapped between, most ports only stick with 1 making the effect more static. It's frankly not a good rendering "effect" to rely on.

We are approaching the third anniversary of nukeykt's HOM emulation PR for chocolate. I'm hoping we can get it in before that.

[Gez]

13 hours ago, Dark Pulse said:

The only thing I can think of would be possibly doing it as some kind of shader effect, but past that I really have no idea.

I don't see how it could be implemented, technically speaking, knowing that the main issue with this kind of things is that your shader needs to access not just the current rendered data, but also and more importantly the previous frame's rendered data. Then you'd need a way to mark areas that need to show the HOM effect, but this can be done with chromakey techniques in a post-processing shader. The obstacle is accessing data (the previous frame) that is dead and purged and overwritten by the time your shader runs.