Question about depth buffer emulation

[degasus]

Mr. 64 Wrote:I want to ask you a question about emulation of CPU based famebuffer effects. If the CPU reads from or writes to the framebuffer how does dolphin deal with this? You say you apply these changes to the framebuffer in VRAM, but how does dolphin do this? Does dolphin copy any data from RAM to VRAM or from VRAM to RAM to emulate this?

All of those kind is possible. The CPU can both read and write into the mapped buffer: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoBackends/D3D/Render.cpp#L348

The GPU however can copy parts of the framebuffer to the main ram, but this is not trigger-able by the CPU: https://github.com/dolphin-emu/dolphin/blob/master/Source/Core/VideoBackends/D3D/PSTextureEncoder.cpp#L90

[Mr. 64]

I’ll have a look at that.
I’ve discussed with Gonetz about depth buffer emulation and it looks like using ARB_fragment_shader_interlock as you suggested is the best option. You can read it here in if you are interested: https://github.com/gonetz/GLideN64/issues/677

[degasus]

gonetz Wrote:The question: will we get the help from emulator?

So, you just have to implement it

[Mr. 64]

It’s a problem that there’s no universal N64 emulator. Mupen64 is designed to be portable. Project64 runs just on windows but has much better compatibility. Mupen64 has support for tracing reads/writes to a particular area but this support is imperfect. The author said it’s hard to trace all reads/writes because they can happen from many places. Project64 currently can’t trace reads/writes and it’s necessary to make many changes to Project64’s memory manager to support this. And maybe then you end up with imperfect support like Mupen64.

[degasus]

You did ask for possible ways to make the emulator as good as possible. But of course, this is not an easy way :/
This sounds like years of work :/