I'm trying to get GlideN64 to render its output to a GL framebuffer.
Looking at the code, it seems that this is supported via ObjectHandle::defaultFramebuffer. I'm using the VidExt API to set this by returning my framebuffer's ID from VidExtFuncGLGetDefaultFramebuffer.
However, this causes GlideN64 to fill that framebuffer with black for a few (hundred?) frames, then stop rendering to it altogether.
Investigating, I found that GlideN64 sometimes creates a GraphicsDrawer::BlitOrCopyRectParams without initializing the drawBuffer field, letting it default to 0, which means "blit to the screen".
As far as I can tell, if GlideN64 has a nonzero default framebuffer, it shouldn't ever have a reason to render to the screen without using a framebuffer.
I'm trying to get GlideN64 to render its output to a GL framebuffer.
Looking at the code, it seems that this is supported via
ObjectHandle::defaultFramebuffer
. I'm using theVidExt
API to set this by returning my framebuffer's ID fromVidExtFuncGLGetDefaultFramebuffer
.However, this causes GlideN64 to fill that framebuffer with black for a few (hundred?) frames, then stop rendering to it altogether.
Investigating, I found that GlideN64 sometimes creates a
GraphicsDrawer::BlitOrCopyRectParams
without initializing thedrawBuffer
field, letting it default to 0, which means "blit to the screen".As far as I can tell, if GlideN64 has a nonzero default framebuffer, it shouldn't ever have a reason to render to the screen without using a framebuffer.
So, I tried making this change:
This works! GlideN64 now renders to its default framebuffer.
However, it only works as long as
config.frameBufferEmulation
is switched off.Otherwise, the code takes a more complex path that I don't understand yet and the framebuffer is once again not rendered to.
I tried covering all the cases by adding a default-initializer:
...but this didn't help. Perhaps there are more places where things are being zero-initialized instead of using
defaultFramebuffer
?