Welcome, Guest.
Username: Password: Remember me

TOPIC: Advice needed for GlideN64 plugin compatibility

Advice needed for GlideN64 plugin compatibility 9 months 2 weeks ago #1

Gonetz, who works on the GlideN64 plugin, was looking into an option to make the depth buffer available so that effects like ambient occlusion could work through ReShade. He's run into a problem that requires some clarification about what ReShade needs and uses specifically to work:
I installed latest Reshade and tested it with Project64 2.3
To my surprise, depth based filters do work. I used DisplayDepth as test shader, here how it looks with Release 2.0

No problems, as well as with other depth buffer based shaders.

With current master it looks upside-down:

I tried to invert it, but without success.

The main question: why it ever works? I do not copy depth from FBO to main depth buffer. Release does not do it. Master does not do it too. My only guess was that Reshade takes data not from color and depth buffer but from FBO, because image in FBO is upside down. However, when I apply filters for color buffer such as 'cartoon', it applied correctly, not upside down. So, where Reshade takes depth buffer data?

Basically, the current 2.0 release of the plugin works with MXAO and other effects even though the depth buffer is never deliberately made available, though for some reason MXAO only works when framebuffer emulation is disabled in GlideN64's options. Once FB is turned off, the effect works perfectly, even though depth apparently isn't being copied to the main depth buffer as Gonetz said:


Can anyone clarify what is likely going on here in terms of why MXAO was working, what info it was accessing in order to work, and what Gonetz would specifically need to make available for this and other effects to run? I'd really like for him to be able to get this working, since it's no longer possible to get MXAO working in the newer versions of the plugin and disabling fb emulation in the 2.0 release is a huge downgrade.
Last Edit: 9 months 2 weeks ago by Nerrel.
The administrator has disabled public write access.

Advice needed for GlideN64 plugin compatibility 9 months 1 week ago #2

ReShade analyzes each framebuffer the app creates and checks if any depth target is bound to it. It does so by looking at any calls to "glFramebufferRenderbuffer", "glFramebufferRenderbufferEXT", "glFramebufferTexture", "glFramebufferTextureARB", "glFrameBufferTextureEXT", "glFramebufferTexture1D", "glFramebufferTexture1DEXT", "glFramebufferTexture2D", "glFramebufferTexture2DEXT", "glFramebufferTexture3D", "glFramebufferTexture3DEXT", "glFramebufferTextureLayer", "glFramebufferTextureLayerARB" and "glFramebufferTextureLayerEXT". If that's the case that framebuffer is added to a list of possible scene depth buffer candidates (relevant code: github.com/crosire/reshade/blob/6064e197...ngl_runtime.cpp#L513). Every 30 frames, ReShade goes through that list and searches one with a resolution that is at least 95% of the screen resolution and that was used in the most draw calls per frame (relevant code: github.com/crosire/reshade/blob/6064e197...ngl_runtime.cpp#L878). It then rememebers which texture or renderbuffer depth attachment is bound to that framebuffer, so starting with the next frame ReShade can copy the contents of that texture/renderbuffer to its own texture that is then bound to the post-processing shaders.

There isn't really anything you can do to influence that (apart from making sure you use one of the API calls above to set up your FBO, but since those are all there exist as far as I know, this should be guaranteed). ReShade will always automatically search for the FBO that has most likely scene depth data in it. If it doesn't find any, it falls back to the main depth buffer. So yes, it does copy from the FBO as suggested.
It being upside down is not an issue, there is a preprocessor define on the settings page that tells all post-processing shaders to flip the depth texture before using it.
Cheers, crosire =)
The administrator has disabled public write access.
The following user(s) said Thank You: Nerrel

Advice needed for GlideN64 plugin compatibility 9 months 1 week ago #3

If you're just after MXAO, why not port it?
The administrator has disabled public write access.

Advice needed for GlideN64 plugin compatibility 9 months 1 week ago #4

Thanks for the answer, crosire!
Marty McFly wrote:
If you're just after MXAO, why not port it?
Forgive me for being totally code illiterate, but you mean by adding it to the plugin itself as an enhancement option? There was a request to add a number of post processing effects (including AO) to the plugin before, but the consensus on github seemed to be that it would be better to let an external program like ReShade handle post processing effects. Adding an option to GlideN64 to allow depth buffer access so that ReShade has better compatibility seems to be the more popular solution.
Last Edit: 9 months 1 week ago by Nerrel.
The administrator has disabled public write access.

Advice needed for GlideN64 plugin compatibility 9 months 1 week ago #5

So MXAO is working- the shadows are applied upside down but setting the upside down preprocessor definition to "1" fixed that- but now the shading is still misaligned. The problem becomes worse when the game is in motion:


Gonetz says this is something that can be fixed by making Reshade use the depth buffer rather than FBO:
Yes, flipping FBO depth image will not be enough: FBO color image can be scaled or shifted somehow when rendered to screen. The same must be done for depth. The only way is to force Reshade to take main depth buffer as depth source. Maybe it is has some option for that? I can fill main depth buffer with correct data (hopefully).

As I understand it, right now GlideN64 doesn't copy depth buffer info to the main depth buffer, so the FBO is the only source ReShade can use. If he were to copy the depth buffer over, would ReShade automatically use that instead, or would it keep using FBO as a source?
The administrator has disabled public write access.

Advice needed for GlideN64 plugin compatibility 9 months 1 week ago #6

It would keep using the FBO, because more draw calls were made with it. You can do any necessary scaling in the MXAO shader though.
Cheers, crosire =)
The administrator has disabled public write access.

Advice needed for GlideN64 plugin compatibility 9 months 1 week ago #7

I asked Marty but he said there wasn't a solution to this within MXAO... both he and Gonetz have suggested that it's up to Reshade at this point, so it seems like forcing Reshade to use the depth buffer instead of FBO would be the only resolution... is there any possibility of this being an option? If it's possible to do, it would allow a lot of effects to work with P64/GlideN64 that otherwise won't.
The administrator has disabled public write access.

Advice needed for GlideN64 plugin compatibility 8 months 1 week ago #8

Sorry to bump this, but I wanted to get a clear answer one way or the other since Gonetz was very helpful and invested some of his time in trying to resolve this (thank you Crosire for your help as well). If the depth buffer were made available by GlideN64, would there be any way to specifically set Reshade to use it, or is Reshade just by nature totally unable to work without the current method of auto-selecting the depth source? I assume at the very least manually specifying the depth source would require a new version of Reshade with a number of changes, but even if it took a long while to be implemented I'd be happy to know it were possible.
The administrator has disabled public write access.

Advice needed for GlideN64 plugin compatibility 8 months 1 week ago #9

It's not going to happen in the immediate future. Sorry.
Cheers, crosire =)
Last Edit: 8 months 1 week ago by crosire.
The administrator has disabled public write access.

Advice needed for GlideN64 plugin compatibility 3 months 1 week ago #10

Thanks for the clarification, but I wanted to ask if this feature in the 3.2 update is basically the same thing as the depth buffer selection override were talking about:


And if so, could it be done on OpenGL eventually?
Last Edit: 3 months 1 week ago by Nerrel.
The administrator has disabled public write access.

Advice needed for GlideN64 plugin compatibility 1 month 3 weeks ago #11

Putting aside MXAO, Reshade itself now is incompatible with GlideN64 altogether due to a recent change with the plugin. In certain indoor areas, solid objects will appear transparent and many of the grayscale textures that are layered over objects no longer work correctly.


The textures on the back wall are completely wrong, losing all detail:


This happens whether any effects are enabled or not, and the only way to fix it is to remove reshade's opengl.dll from project64's root folder. Reshade worked just a few GlideN64 versions ago, so this is a GlideN64 problem, but the developers don't have much time to devote to it. Could anyone speculate about what could possibly cause an issue like this so that I can give them a head start on what to look at?
The administrator has disabled public write access.