Request- option to copy depth buffer to main frame buffer

[Nerrel]

Certain shaders and effects require depth buffer access to work. It's possible to make the depth buffer available for enhancement programs like Reshade to use in GlideN64's current 2.0 release by disabling framebuffer emulation, but this is a major downgrade to the emulation quality. Worse still, Gonetz stated (in issue #1496) that the depth buffer will no longer be available in future versions even if fb emulation is disabled due to recent changes to the plugin.

In that same issue Gonetz said it would be possible to fix with a dedicated option, so I wanted to make this its own issue to see if anyone can take it up:

"Currently, color buffer from FBO is copied to main frame buffer and displayed on screen. FBO has depth buffer as well, but it is not copied to main depth buffer, it would be waste of GPU resources. If you need depth buffer for external shaders library, it also can be copied. As I said, it is relatively simple, but I loaded with other tasks and can't take this one atm. May be somebody else will do it. Necessary steps:

add config option to enable depth buffer copy
add support for this option for mupen64plus and zilmar specs.
modify FrameBufferList::renderBuffer() that it will render not only color buffer but depth buffer too."

I'm working on a texture pack and had been intending to include ambient occlusion via Reshade as part of the mod; people have shown a lot of interest in using the effect, so I'd appreciate it if someone could add this option so that it would remain possible to use this enhancement in future GlideN64 versions. It would also be really great to be able to use this effect without having to disable fb emulation. Thanks

[gonetz]

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?

[Nerrel]

I asked Crosire about this on the ReShade forum and this was his response:

"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. "

https://reshade.me/forum/general-discussion/3688-advice-needed-for-gliden64-plugin-compatibility#24507

[gonetz]

Quite informative, thanks! Have you tried to use current WIP builds with ReShade ? Looks like that " option to copy depth buffer to main frame buffer" is not necessary.

[Nerrel]

I did try it, but unfortunately the shading is actually applied upside down and isn't flipped as it should be: https://c1.staticflickr.com/5/4460/24250232338_c1ba506ce3_c.jpg

I'll ask about that the Reshade forum. It does seem to work otherwise, but one big drawback is that it still requires framebuffer emulation to be disabled, as the 2.0 release did. Trying to use the effect with fb emulation on in either the 2.0 or WIP version of GlideN64 results in broken shadows flashing on the screen every few seconds; the shading for the MXAO effect doesn't change to reflect the environment or camera position, it's just stuck. It's only when the fb emulation is disabled in both versions that it works correctly... do you know why that is, and whether it would be possible to get these effects to work with fb emulation on (setting aside the upside down problem)? Turning fb emulation off lowers the emulation quality a lot...

That's part of the reason I was hoping for a depth access option, so that the depth information needed could be made available with fb emulation active; I assumed depth information was made available with fb turned off, but based on what you've said that isn't true and depth wasn't ever available either way. Turning fb off must just give access to the FBO that isn't available otherwise, then?

[gonetz]

1. To use ReShade with Release 2.0 and fb emulation enabled, set "Frame buffer swap on" to "VI origin change".

2. I tried to copy depth information from FBO to main depth buffer with current version. Currently color buffer from FBO is rendered to main color buffer as textured rectangle. Copy shader is simple: it just reads texel from input texture, which is texture color buffer from FBO. Depth was not copied. I modified copy shader to write gl_FragDepth too, but it had no impact on result: color image is correct, depth image is upside down. That is information, which copy shader writes to depth buffer is ignored by ReShade for some reason.

[oddMLan]

What about using the preprocessor define that was mentioned earlier to tell ReShade to flip the depth buffer?

[gonetz]

If you found what that preprocessor define is, let me know.

[oddMLan]

https://reshade.me/forum/troubleshooting/3293-common-issues-and-their-solutions

1c. If Display Depth shows an upside-down image, set RESHADE_DEPTH_INPUT_IS_UPSIDE_DOWN to 1.

To open the settings pane press Shift+F2 and go to the second tab where the preprocessor definitions are.

[Nerrel]

I set fb swap to "VI origin change" and it did allow MXAO to be applied with fb emulation on in the WIP build (though it didn't work in the 2.0 release when I tried it there). I also entered the definition oddMLan just posted and while it did flip the image, the shading is still not placed correctly in the game: https://c1.staticflickr.com/5/4452/37406996584_af07dff505_c.jpg

It seems to be offset by enough to break the effect, and it becomes even more misaligned when the game is in motion. I'm not sure if this is a problem has to be corrected on the Reshade side or the plugin side; MXAO was always perfectly aligned when using the 2.0 release with fb emulation off.

(Thanks for helping with this by the way, I know it's not a high priority issue)

[gonetz]

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. May be it is has some option for that? I can fill main depth buffer with correct data (hopefully).

[Nerrel]

Crosire on the Reshade forum said that even with the depth buffer data made available, Reshade would still use FBO as the source because that's where the most draw calls are made; I don't think there's a way to force it to use depth buffer as a source instead. For now it looks like it may not be possible to get these kinds of effects working in anything beyond the 2.0 GlideN64 release... The author of MXAO did mention that porting the shader was possible and maybe it could be made to work then, but I'm not sure if anyone would be in favor of taking the time to add effects to the plugin itself.

[oddMLan]

If you disable FBO depth buffer and use the main buffer for the depth data, would that cause problems? Then ReShade would have no option but to use that.

[gonetz]

If you disable FBO depth buffer and use the main buffer for the depth data, would that cause problems?

Yes. You can't attach the main depth buffer to FBO. Thus, you can't use depth compare with FBO in that case.

[gonetz]

Reshade would still use FBO as the source because that's where the most draw calls are made

An example of too smart application, which user can't make work properly. Could they add an option to disable application's brains and force it to use data sources provided by user exactly?

[oddMLan]

Could they add an option to disable application's brains and force it to use data sources provided by user exactly?

Hm... would this be what we need? https://reshade.me/forum/general-discussion/4083-depth-buffer-detection-modification

[Nerrel]

That was my first thought when seeing that mod. Unfortunately, it's only available for D3D, not OpenGL. I don't know if the author plans to do an OpenGL version, or if it's possible to do the same mod in the same way within that backend.

By default, ReShade looks for the most draw calls and sets the depth source that way. The author of this mod described how their alternate method works this way: _"What i did is retrieve the depth buffer texture at different stages, other than the rendering one. I retrieve the depth buffer texture at Output Merger state, or just before the game clears the buffer, at the clearDepthstencilView stage, I make a copy of this texture, then pass it to the draw_call_tracker instance, and retrieve it at the select_depthstencilreplacement stage."

Gonetz, does any of that sound like it would be applicable for finding the depth buffer in GlideN64?

[scarletcafe]

Is there any advance on a native method to display the depth buffer in the latest release or development versions of GlideN64? Depth buffer information is very useful for reverse engineering, so it would be nice to be able to do this in-plugin with the newer graphics improvements.

[gonetz]

I don't have time for this task atm. I may help if somebody else will take that task.

[Nerrel]

I tried experimenting with the newest ReShade and GlideN64 builds and noticed a few things about how MXAO is running. Gonetz, you said before that these issues are probably caused by ReShade using the FBO as a source instead of the depth buffer... I'm not sure if this sheds any new light on anything, but I wanted to add it to the issue.

The MXAO shading is a few frames faster than the actual game. You can clearly see it here where AO shaded Link is swinging before his actual model begins to:

The MXAO alignment and scaling also change dramatically depending on the internal resolution option. Using "same as output resolution" has a slight misalignment, but the scale seems right (the AO intensity was set very high to make it easier to see):

Setting to a multiple of N64 resolution (in my case 7x) scales the AO to be larger and even more misaligned:

Choosing the original N64 resolution results in the AO being limited to a small box in the upper left corner:

Just to reiterate, MXAO worked well in GlideN64 2.0 without any misalignment or timing problems as long as framebuffer emulation was off. ReShade should be selecting same depth source in that version of GlideN64, so if it is using FBO then the changes to it made around the GlideN64 3.0 release caused this new behavior.

A member of my Discord speculated it might be due to the way the Y inversion was changed: "The reason AO is upside down when AO isn't reversed might be that ReShade and (at least GLideN emulation of) the N64's display buffer are upside-down compared to each other, and ReShade might be doing all of it's calculations from the bottom of the image instead of the top (or vice versa), causing the alignment. "

The problem with that is that it wouldn't account for why MXAO is a few frames ahead.

In the current 4.0 GlideN64 build MXAO works with both framebuffer emulation set to off and to VI origin change, but the alignment seems slightly better when set to "off." It's still very misaligned, though (see the gap under the hanging straw):

I know no one has time to look into it, but I still hope this can be made to work again eventually.

[gonetz]

Yes, I don't have time to look into it, but I have some thoughts.

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.

[Nerrel]

Thanks for the reply. When you say the "main depth buffer is not used at all," does that mean an external program like ReShade wouldn't be able to access that information no matter what? There are mods for D3D backends that allow ReShade to select a depth source, I had been hoping that if that mod were made compatible with OpenGL that it might be possible to feed ReShade the right depth information instead of the FBO it's currently selecting.

Incidentally, there's now a shader that goes beyond ambient occlusion and allows for ray tracing to be injected into old games. I'd really like to try it but it would suffer the same alignment problems.

[gonetz]

When you say the "main depth buffer is not used at all," does that mean an external program like ReShade wouldn't be able to access that information no matter what?

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, but I suggest to finish with HD textures issues first.

[Nerrel]

Apparently it's only possible to get depth effects working correctly with Nvidia cards. I had previously been getting MXAO to work in GlideN64 2.0 with fb emulation off using an Nvidia GTX 970. On an AMD card now, MXAO only applies in 2.0 with fb set to vertical interrupt or VI origin change (off just dims the screen evenly) and it's misaligned and out of sync just as it is in the new versions of the plugin. So for AMD, 2.0 is basically no different than the newest WIP build when it comes to this effect.

A member of my discord with a GTX 970 confirmed that MXAO worked correctly for him in 2.0 with fb emulation off, so it does seem consistent that Nvidia users can get it to work in that build with fb off. I'm not sure why that would be.

[gonetz]

I tested current version of ReShade with current PR 4.0 I managed to get the same level of depth effects support as with PR 2.0 - that is depth effects work correct with frame buffer emulation disabled. The solution is quite clumsy:

1. As I understand, ReShade reads depth information from the latest used Frame Buffer Object (FBO). GLideN64 uses FBO with and without frame buffer emulation. You may still use fb emulation. Just change frame buffer swap mode from default "Vertical interrupt" to "VI origin change" and ReShade will get depth information. However, it does not work properly because FBO, which is the source of color information is not the latest one when fb emulation enabled. That is, when fb enabled, you will have one-two frame delay between color and depth data and this is very noticeable. I don't know how to make ReShade read depth information from the main depth buffer, not from FBO. I tried to copy both color and depth from FBO to main buffers, but it did not help.

2. Ok, we can get depth data from FBO, and if we will set fb emulation off, depth data will be synced with the color one. Good. However, FBO is rendered upside down. Image flipped when it is copied from FBO to the main buffer. Depth data in FBO is still upside down: I can't fix it on plugin's side, but ReShade shaders can flip texture coordinate and get correct image. DisplayDepth shader has special option for it. Alas, MXAO has no such option. So, if we want to use MXAO, we need to modify it a little. It is possible to add the option, but I just changed GetLinearDepth function. Open reshade-shaders/Shaders/MXAO.fx in text editor, find GetLinearDepth and edit it as:

   
   float GetLinearDepth(in float2 coords)
   {
       float2 coords2 = coords;
       coords2.y = 1.0 - coords2.y;
   return ReShade::GetLinearizedDepth(coords2);
   }

Save the file and re-run emulator.

3. Now, when MXAO uses flipped depth data, it looks almost correct:
![MXAO-1](https://user-images.githubusercontent.com/8983092/59977789-d5f03880-95ff-11e9-9dcb-58dfa23592ce.png)
Almost, but still wrong. Why? Project64 requires from graphics plugin to shift image down by height of toolbar. So, image on window is shifted, but FBO was rendered with no shift, so color and depth data became shifted each against other. There is no toolbar in full-screen mode, but I failed to get depth data for ReShade in full-screen. It just does not work at all.

4. There is modern emulator, which does not require to shift image down in windowed mode. It is mupen64plus. I use mupen64plus-gui. I copied ReShade files to mupen64plus-gui folder and disabled frame buffer emulation. Finally MXAO works as with PR 2.0:
![MXAO-2](https://user-images.githubusercontent.com/8983092/59978085-caead780-9602-11e9-902e-6eda97e2728a.png)
but only in window. There is no depth data in full-screen mode with mupen64plus either.
Result is the same for GeForce and Radeon.

I don't know how ReShade selects source of depth information and why it don't want to read it from the main depth buffer. I hope that somebody will help me to find it. Until then I hardly can do anything in that direction.

[oddMLan]

cc @crosire ? I think @gonetz explained the situation eloquently. Would you be able to give us some insight?

[crosire]

ReShade selects a depth buffer based on how many draw calls and vertices were rendered into it. That can be a FBO, it can also be the window depth buffer. Doesn't matter to ReShade. Copying the data around won't affect that algorithm. The way to get ReShade to select the right buffer is to render the current frame into it, which is how games generally operate. Normally the OpenGL driver handles rendering frames ahead behind the scenes, so things are in sync from ReShade's point of view (which sits before the driver). GlideN64 does this manually, so the selected buffer will have data from a different frame (the most recent renderered one) than the one that is displayed (which can be older). I don't have the slightest idea how emulators operate, so I'm assuming this is intentional. But it makes ReShade's selection algorithm useless. If GlideN64 copies the correct depth buffer to the window framebuffer, than a way around this is to add an option to ReShade which allows users to manually select the window framebuffer (aka FBO id 0) as source. Similar to what is possible in the DX implementations already. Will try and find some time to add that.

[Nerrel]

Thank you for looking into it Crosire and Gonetz. Also Gonetz, I don't know how familiar you are with ReShade but you can flip the depth by changing the preprocessor definition "depth input is upside down" from 0 to 1 in the small bar below the effects list. In those images it looks like the depth input may have also reversed, which is also in the preprocessor definitions.

[gonetz]

@crosire Thanks for the explanation! Yes, the delay between moments when a frame rendering is completed and when that frame appears on screen is intentional. The emulator core controls which frame must be displayed at the moment, and usually it is not the latest rendered frame. It also causes input lags (#1822), but graphics plugin must obey emu core for sake of emulation accuracy.

If GlideN64 copies the correct depth buffer to the window framebuffer, than a way around this is to add an option to ReShade which allows users to manually select the window framebuffer (aka FBO id 0) as source.

It should help. Thanks in advance :) GLideN64 currently copies only color from FBO to window buffer, depth is not copied. If option to manually select the window framebuffer will be implemented, I'll modify GLideN64 code accordingly.

[gonetz]

@Nerrel if "depth input is upside down" preprocessor definition affects all depth-based ReShade shaders, the problem with flipped depth image is solved. Thanks :)

[Boulotaur2024]

I tried to copy both color and depth from FBO to main buffers, but it did not help.

Hi @gonetz, Could you make that binary available somewhere ?

Just upload it on (mega.nz or sendspace). Preferably the mupen64plus version (zilmar specs ? - I forgot). Mupen64plus is much more stable for me. (Project64 is buggy as hell with Reshade due to conflicting debug libraries)

I might have some free time next friday to debug things out. I believe that kind of delay issue is related to frame bufffer emulation which is something that is only relevant in emulation. See here : https://reshade.me/forum/general-discussion/5442-release-misc-emulators-with-depth-buffer-access#34710

If I understand things right, the simple fact of copying depth buffer to main depth buffer (aka "fbo 0") would magically sync both backbuffer and depth buffer (well the one that Reshade now grabs from latest FBO) because OpenGL driver knows how to handle and sync things thrown out of the "main depth buffer" ?

Well, let's see !

[weinerschnitzel]

Afaik, that's true to get them talking to eachother, but it requires a force FBO0 option in ReShade and GLideN64 to comply with that option.

This collaboration is really exciting to read!

[gonetz]

@Boulotaur2024 Hi!

If I understand things right, the simple fact of copying depth buffer to main depth buffer (aka "fbo 0") would magically sync both backbuffer and depth buffer (well the one that Reshade now grabs from latest FBO) because OpenGL driver knows how to handle and sync things thrown out of the "main depth buffer" ?

No magic here. Color and depth attachments in FBO are synced. Plugin blits both color and depth from a FBO to "fbo 0" and swaps buffers. So, if ReShade will use depth from main depth buffer, it will be (or at least should be) synced with displayed color buffer.

I pushed my quick hack with depth copy to depth_copy branch: https://github.com/gonetz/GLideN64/tree/depth_copy

If you have Visual Studio, you may easily build the plugin for mupen64plus from sources. Just select necessary configuration and build solution. In case you have problems with it, here my build for mupen64plus 32bit: https://drive.google.com/file/d/1TWRMAsO6BqkIvMDVS-rrbYYzida_rTFR/view?usp=sharing

Usage:

• enable frame buffer emulation
• disable overscan.
• it is better to have MSAA disabled too.

[Boulotaur2024]

@gonetz Thanks a lot ! Now everyone can have a go at it.

Right now I'm exhausted but I'll look into it as soon as I can. We are having a big heatwave right now in Europe and also in France, I'm scared my GPU could be melting :p

[Boulotaur2024]

And the verdict is : No it's not enough, it's still delayed :

I only played with mupen64plus with the following commandline (default settings for glideN64 - I don't even know where they are stored) : --resolution 1024x768 --windowed --gfx mupen64plus-video-GLideN64 "G:\Jeux Install\Emulation\n64\Mario64.n64"

Here is the modified code in Reshade right before present (SwapBuffers) so that only FBO 0 is picked as the source of depthbuffer :

//detect_depth_source();   <-- commented out, no need to search for the depth buffer

Yep, that's it, I only commented that. Now we know that depth buffer is in main framebuffer (fbo 0). So there is no need to loop through all the "non-zero FBOs" (in reference to what Crosire said that in this particular case "ReShade's selection algorithm [is] useless"). Rest of the code is unmodified vanilla Reshade. With a few of my own comments :

// Copy back buffer to RBO
glDisable(GL_SCISSOR_TEST);
glDisable(GL_FRAMEBUFFER_SRGB);
glBindFramebuffer(GL_READ_FRAMEBUFFER, 0);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, _fbo[FBO_BACK]);
glReadBuffer(GL_BACK);
glDrawBuffer(GL_COLOR_ATTACHMENT0);
glBlitFramebuffer(0, 0, _width, _height, 0, 0, _width, _height, GL_COLOR_BUFFER_BIT, GL_NEAREST);

// Copy depth from FBO to depth texture 
// (notice we read from FBO 0 now because we commented out "detect_depth_source" 
// and _depth_source *is* == 0 now)
glBindFramebuffer(GL_READ_FRAMEBUFFER, _depth_source != 0 ? _fbo[FBO_DEPTH] : 0);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, _fbo[FBO_BLIT]);
glBlitFramebuffer(0, 0, _width, _height, 0, 0, _width, _height, GL_DEPTH_BUFFER_BIT, GL_NEAREST);

// Render effects (SSAO, FXAA, etc...)  
update_and_render_effects();

// Copy results from RBO to back buffer
glDisable(GL_SCISSOR_TEST);
glDisable(GL_FRAMEBUFFER_SRGB);
glBindFramebuffer(GL_READ_FRAMEBUFFER, _fbo[FBO_BACK]);
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0);
glReadBuffer(GL_COLOR_ATTACHMENT0);
glDrawBuffer(GL_BACK);
glBlitFramebuffer(0, 0, _width, _height, 0, 0, _width, _height, GL_COLOR_BUFFER_BIT, GL_NEAREST);

// Flip to screen
SwapBuffers();

Here is the modified Reshade dll file I used, implementing the above code : https://mega.nz/#!WZ1yHYoC!Wsu_-Z5xh23HzGh3TRAUOe8z1E7Ah7tQyXNDS4aS-TA

[gonetz]

No it's not enough, it's still delayed :

Yes, it's not enough. My fault. I missed one obvious moment: N64 uses several color buffers but usually only one depth buffer. Depth buffer is not displayed, no needs to allocate more than one. GLideN64 emulates it as straight as possible: only one depth texture allocated and used as depth attachment for every FBOs. It is important for emulation accuracy. As the result, copy of FBO depth attachment to main depth buffer has the same result as reading depth from the most recently drawn FBO.

It can be fixed. I need to keep copy of depth attachments per FBO. Hopefully I'll be able to do it this weekend. Great, that Reshade is already modified, so I can test my work. Boulotaur2024, thanks!

[gonetz]

I made another hack for depth buffer copy. Source: e091134e7 Binary for mupen64plus 32bit: https://drive.google.com/file/d/1qPiZc22kCwMyYd9pAdJGyiA_lo-QIcvp/view?usp=sharing Use it with modified Reshade dll by Boulotaur2024 : https://mega.nz/#!WZ1yHYoC!Wsu_-Z5xh23HzGh3TRAUOe8z1E7Ah7tQyXNDS4aS-TA

It will not work with all games, proper implementation will be done later. I tested with Zeldas and SM64, works fine. No modifications in shaders code or ReShade defaults are necessary. Feedback is welcome.

[Boulotaur2024]

Oh yeah you did it ! You're a king !

Can confirm it's working super fine now 👍

Nerrel is going to be a happy man :] If you need further help for PJ64 and "toolbar shift" I can probably help with that. Just that I'm not here tomorrow. But next week ok

[Nerrel]

I also tested it and it seemed to work without any timing or alignment issues in windowed mode, which is great. Is the main thing needed for Pj64 just compensating for the toolbar then, and if so does that need to be done on the Pj64 side?

In fullscreen the depth effects ended up being cut off on the right edge for some reason. It also occured when maximizing the game in window mode:

In GlideN64 2.0 depth effects worked perfectly in full screen, I captured most of my texture videos that way. Hopefully the fullscreen issues can be worked out, but if not is there a way to get 16:9 in windowed mode? Edit: Nevermind, editing the window res in the config file seemed to work

[gonetz]

Is the main thing needed for Pj64 just compensating for the toolbar then, and if so does that need to be done on the Pj64 side?

Modified ReShade should work fine with modified GLideN64 for Project64. Unfortunately, it does not work at all. I have no working depth effect with frame buffer emulation enabled and crash on game start when fb emulation disabled. I have no Idea, why.

[Boulotaur2024]

@Gonetz, I'm on mobile right now so I'll be quick. Could you share modified GlideN64 binary for Pj64? I'll look into it tonight back at home. Sounds weird that it "doesn't work at all" indeed

EDIT : ok thanks Gonetz, I'm at work right now. I'll be at home around 8pm (France time) That said, I have no idea either why it's not working...

[gonetz]

Could you share modified GlideN64 binary for Pj64?

Yes, here: https://drive.google.com/file/d/1kiVs7yqFTzjSrF6PFsbRJkqJyO1gaakw/view?usp=sharing

[Boulotaur2024]

@gonetz : a good news (yeah !) and a (small) bad news : I got it working fine in Pj64 ! I don't get the shift caused by toolbar positioning but then again I sticked to GlideN64 default settings. Fullscreen is ok for me.

Now a little bit of explanation : It used to crash on that line (glBlitFrameBuffer : GL_INVALID_OPERATION) : https://github.com/crosire/reshade/blob/4ed66b04eb526eab724ba6d06c442cb4cc2565e4/source/opengl/runtime_opengl.cpp#L211

Probably, so I thought, because it tried to read from a texture of a different format than the one it writes to. So I had a look at your code here : https://github.com/gonetz/GLideN64/blob/f209304d0b052dd53fcaadfa9f21055ab9f489d5/src/Graphics/OpenGLContext/opengl_BufferManipulationObjectFactory.cpp#L344 As opposed to Reshade who used GL_DEPTH24_STENCIL8. So I changed the format from GL_DEPTH24_STENCIL8 to GL_DEPTH_COMPONENT24 here : https://github.com/crosire/reshade/blob/4ed66b04eb526eab724ba6d06c442cb4cc2565e4/source/opengl/runtime_opengl.cpp#L140

And it does the trick !

Now for the bad news, I have no idea why but... The Reshade debug build seems to consistently work while the Reshade release build has MXAO never working... only DisplayDepth works fine...

I have no idea why, I'll look into it... Maybe a driver thing (I'm on Radeon). So here are the 2 builds that you can test on your rig :

Reshade debug build (the one working consistently) : https://mega.nz/#!qB9hBAQL!wXcu7Lu4luRvzn7l3AgfJvx_lgBYECT4wcWuvfdm1ds Reshade release build (white depth and "black" bacbuffer when MXAO is on) : https://mega.nz/#!WU9VjaKZ!OICncQFh3i0exXKm4_FlTKDnfGSRD1tTFCdclyLBmXU

EDIT : debug build is very unstable due to conflicting debug libraries with Pj64... but it's only temporary EDIT : it's very weird, only MXAO causes issues with the release build, MartyMcFly's RT shader looks fine, and SSR too... the latter use more or less the same shaders bases... I seem to remember MXAO uses several render targets in one pass. It does things differently...

[Nerrel]

I tried the debug build and couldn't get it working with pj64 at all. The plugin failed to initialize and I couldn't open the graphics settings or run any game...

The second "release build" link worked with everything, including MXAO. The only problems I noticed were that the effect maybe wasn't quite as stable in motion as it was in GlideN64 2.0 with fb off, I can't say for sure, but it definitely works (this is on an AMD Vega 56). The other is that the right edge of the screen is very dark in fullscreen mode, which seems similar to the problem I had when testing the Mupen64 version:

It seems to work really well in windowed mode, at least. Let me know if I can test anything in regards to that black bar issue

[Boulotaur2024]

The other is that the right edge of the screen is very dark in fullscreen mode, which seems similar to the problem I had when testing the Mupen64 version:

I don't get the same issue... Then again I don't know your settings, I tried to set 'stretch' and '16:9' aspect ratio. I increased internal res to x8... Still not the the same issue.

Could you try to open Reshade.ini and set : [EMULATORS] EMUName=gliden64

[Nerrel]

That seems to have fixed it, for some reason it listed PCSX2 instead of GlideN64?

I tried a few other games and MXAO/RT seem to work in all of them but the RT shader was very inconsistent. MXAO always seems to work but sometimes the RT causes the screen to either go black or to freeze in place while the global illumination is still visible and in motion... Other times it loads without any issues in the very same game. I was able to get around it by disabling all effects and only activating them after the game was loaded. I'm not sure what's going on or whether it can be resolved.

This is again with the release build you linked and these are the settings I'm using:

Other than that, I think it's working very well now

[Boulotaur2024]

I saw your post on Reshade forum. This build should fix the issue (not 100% sure but I think) : https://mega.nz/#!SB1BiCRK!UR5P__zaL6AUAKEVN0nXloQ37BNFjtq3u5anGGUeKWU

I'll commit the changes to my Github so people can see how much I changed from "vanilla" reshade code (spoiler, the answer is "not much" and I pretty much listed all the changes already on this page)

EDIT : if I go back to "same as output resolution" the issue comes back again. If I increase the internal resolution to a multiplier, it goes away...

I'd wait for a "proper implementation" (as he said he'd do) from Gonetz if I were you ;)

[Boulotaur2024]

Disregard the last post, I'm struggling to find some free time...
As it turns out I had left some stupid hardcoded stuff somewhere else. I think it's working fine now

Try this build : https://mega.nz/#!qUE2VArb!NI3gc2PlUYiTLQPu2GU93PiKaOg6VNoZRNUk2HhmKNQ

I committed the changes HERE

[Nerrel]

That one seems to work for me, no problems so far in either windowed or fullscreen mode that I can see. It's amazing to see this finally working, thank you for all of the time spent on this!

[Boulotaur2024]

Little update on this : no particular changes but I keep updating my fork and prettyfying the UI. Let's hope this goes into upstream after my holidays.

https://reshade.me/forum/general-discussion/5442-release-misc-emulators-with-depth-buffer-access

Tick the 'Force default depth buffer' checkbox in the new OpenGL tab. (Credits go to Crosire -he did the job)

Thanks a lot Gonetz and Nerrel for putting in the work ! I talked briefly with other emu writers and they did not seem as motivated as you to cooperate with third party shaders injectors such as Reshade. But it's a matter of priorities...

[gonetz]

@Boulotaur2024 thank you! We would not move further in that direction without support from Reshade devs.

Btw, which Reshade effects need depth buffer data, and which of them are useful for N64 games?