Gliden64: Having copy auxiliary buffers to RDRAM enabled causes some graphical issues in games

[fzurita]

With the option "Copy auxiliary buffers to RDRAM" enabled, Conker's shadow in CBFD is broken. What is this option useful for again?

[gonetz]

Some fb effects look/work more correct with it. For example shadows in JFG intro:

[fzurita]

Gotcha, why does it break some effects?

[gonetz]

It may require several hours to answer this question.

[ghost]

@fzurita Some games use the CPU basically for post processing. Like for instance JFG's softshadows. (a feature normally seen in modern PC games using pixel shaders on shadow buffer textures)

[fzurita]

Oh, gotcha, very informative.

[ghost]

Yeah, some N64 devs were extremely smart. On N64, because access to memory and pixels by CPU is so easy, they can do this and many other effects.

On PC its tons more complicated since there is no unified memory area (you got normal GPU memory, abstracted by OpenGL in this case) and normal PC emulated RDRAM. GLideN64 allocates texture buffers for framebuffers (done on N64 by a certain RDP color/depth image command I think) to a framebuffer object in OpenGL. All these framebuffer objects are rendered independantly from main emulator RDRAM and are managed entirely by OpenGL and stored on the GPU.

Modern PC games don't have this problem as everything is done on GPU anyway for graphics, and post processing and other blending operations are now done by pixel/compute shaders in them.

This option just copies these back to main RDRAM using OpenGL specific commands, but that can come with performance penalties on PC due to AGP/PCI-E bus speeds, that and other quirks in OGL and drivers themselves. And plus there can be bugs when it does because HWFBE itself is a hack,

Software rendering avoids all these problems since everything is done on CPU/main RAM and framebuffer access is much easier.

I could be wrong.

[gonetz]

@mudlord you are totally correct here, thanks!