RLSW shows black screen on Desktop (GLFW) with infinite FPS, but TakeScreenshot works correctly

[WILL-Moxyz]

Hi everyone,

I was experimenting with the RLSW software renderer (compiled with -DRLSW=ON) on Windows using the Desktop (GLFW) platform, but I’m running into a black screen issue.

The Problem:
When I run a basic drawing example, the application window remains completely black. Interestingly, the FPS runs extremely high (jumping from 1800 down to 160 over time).

However, the CPU rendering seems to be working perfectly, because calling TakeScreenshot() saves a correct image with all the drawn graphics (circles, text, etc.).

My Investigation:
I did a little digging into the source code and noticed a difference between platforms:

In rcore_web.c, the SwapScreenBuffer() function has a specific #if defined(GRAPHICS_API_OPENGL_SOFTWARE) block that copies the RLSW CPU framebuffer to the HTML5 canvas for display.
But in rcore_desktop_glfw.c, the SwapScreenBuffer() function only calls glfwSwapBuffers() and has no such RLSW handling.
Since RLSW intercepts OpenGL calls via macros, it seems glfwSwapBuffers() just swaps an empty native OpenGL buffer on desktop, leaving the RLSW framebuffer unblitted to the screen.

My Question:
Is RLSW currently only intended/supported for the Web platform? Or is this a missing implementation in the GLFW desktop backend that causes the black screen?

Any insights would be appreciated! Thanks for the amazing library.

[adamvalves]

Hi! I think your reading of the source is right.

From the raylib 6.0 release notes, the backends adapted for rlsw are SDL, RGFW and DRM, plus the new Win32, Emscripten and Memory platforms. GLFW isn't in that list, so it looks like RLSW just isn't wired up for the GLFW desktop backend yet. That fits what you found: with GLFW nothing takes the CPU framebuffer and puts it on the window, so glfwSwapBuffers() presents an empty GL backbuffer. TakeScreenshot() reads from rlsw directly, which is why it still looks correct.

Since you're on Windows, I'd try a supported backend instead. The new Win32 backend can create a GDI window, which is what the software renderer needs (the release notes call it experimental), or you can go with SDL or RGFW. I haven't checked the exact CMake option names, so have a look at the platform option in CMakeOptions.txt.

If you really want GLFW + rlsw, you'd have to add the blit yourself in SwapScreenBuffer(): upload the rlsw color buffer to a native GL texture and draw a fullscreen quad. Use raw GL calls for that, not DrawTexture(), since that would go back through rlsw. Might be worth asking @Bigfoot71 or raysan5 whether they'd want that in the GLFW backend at all, given the other backends already cover it.