Advice needed for GlideN64 plugin compatibility
- Nerrel
- Topic Author
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.
Please Log in or Create an account to join the conversation.
- crosire
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.
Please Log in or Create an account to join the conversation.
- Marty McFly
Please Log in or Create an account to join the conversation.
- Nerrel
- Topic Author
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.Marty McFly wrote: If you're just after MXAO, why not port it?
Please Log in or Create an account to join the conversation.
- Nerrel
- Topic Author
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?
Please Log in or Create an account to join the conversation.
- crosire
Please Log in or Create an account to join the conversation.
- Nerrel
- Topic Author
Please Log in or Create an account to join the conversation.
- Nerrel
- Topic Author
Please Log in or Create an account to join the conversation.
- crosire
Please Log in or Create an account to join the conversation.
- Nerrel
- Topic Author
Gonetz speculated about what's causing that alignment issue I posted above (where MXAO is misaligned with the environment and moves 1 frame faster than the actual game, seen here where Link's shading swings before his model).
Again, MXAO worked correctly in the 2.0 version of the plugin on Nvidia cards and started this incorrect behavior in 3.0:
_________________
"GlideN64 2.0 uses main frame and depth buffers when framebuffer emulation is off.
Since PR 3.0 frame is always rendered with FBO regardless of framebuffer emulation mode.
Thus, main depth buffer is not used at all, so ReShade can't take information from it.
Then, rendered frame usually does not copied to main color buffer immediately after rendering. N64 games allocate at least two color buffers for double-buffering. One buffer is being rendered, other is displayed. Zelda (U) runs at 20 fps, while NTSC updates screen 60 times per second. That is ready frame will wait for 3 Video Interrupts before it will appear on screen. I guess, ReShade tries to use most recently updated FBO for MXAO, which explains why MXAO shading is a few frames faster than the actual game.
I don't know how ReShade works. May be it can take depth buffer from FBO, but it can be tricky because there are always several FBOs.
As an alternative, the plugin can copy not only color but also depth from FBO to main depth buffer. I may try to implement it"
_________________
He's willing to change a few things in the plugin if it can get depth effects working again, but he doesn't know enough about how ReShade works to know what will work. I'm also not sure if a depth buffer mod for OpenGL would work by allowing a different one of the buffers he mentioned to be selected. In the interest of helping him use his time effectively, is there any advice I could pass along to him?
Please Log in or Create an account to join the conversation.