[rlgl] Add Software Rendering Support

[Bigfoot71]

This PR aims to work on the integration of software rendering support into rlgl, through an external header rlsw.h

I give to @raysan5 the privilege of choosing the name if rlsw doesn't suit him.

Additionally, the header is delivered with an MIT license in my name. I also leave the choice of the license to @raysan5. Consider this project as a donation to the community; I will not redistribute it on my side.

This header rlsw.h is intended to provide, for now, all the functionalities offered by rlgl.h for OpenGL 1.1.

Currently, rendering is performed to a framebuffer that supports multiple formats, selectable at compile time:

• Color Buffer:

  • RGB - 8-bit (3:3:2)
  • RGB - 16-bit (5:6:5)
  • RGB - 24-bit (8:8:8)

• Depth Buffer:

  • D - 8-bit (unorm)
  • D - 16-bit (unorm)
  • D - 24-bit (unorm)

For the rest, I'll leave you to check the checklist.

If you notice any features that should be implemented and are missing from the checklist, please mention them or edit the post if you can.

note: This PR currently only contains the header. I will work on the integration once the checklist is complete and a decision has been made on how to integrate it into raylib.

---

Feature Checklist

Clipping

• Point Clipping
• Line Clipping
• Triangle Clipping
• Quad Clipping

Rendering

• Point Rendering
• Line Rendering
• Triangle Rendering
• Quad Rendering
• Polygon Modes
• Point Width
• Line Width

Texture Support

• All Uncompressed Texture Formats Supported by Raylib
• Texture Minification / Magnification Checks
• Bilinear Filtering
• Texture Wrap Modes with Separate Check for S/T

Vertex Arrays

• Vertex Arrays Support
• Direct Primitive Drawing Mode
• Matrix Stack Support

Misc

• GL-like Getter Functions
• Framebuffer Resizing
• Perspective Correct
• Scissor Clipping
• Depth Testing
• Blend Modes
• Face Culling

[Bigfoot71]

Here is a quick video example of some of the current capabilities. Note that the texture is rendered with bilinear filtering, although I agree that it may not be noticeable as it is.

simplescreenrecorder-2025-03-12_01.34.46.mp4

[ColleagueRiley]

This repeats a lot of code that RLGL does for you.

RLGL already handles the OpenGL 1 like abstraction and the marxies, so I think it would make more sense to build from the modern opengl setup and render everything in rlDrawRenderBatch.

[Bigfoot71]

Additionally, I chose to implement triangle rasterization using the scanline method rather than barycentric interpolation method.

Barycentric interpolation can be much more efficient when implemented with SIMD optimizations and is also conceptually simpler (excluding SIMD considerations).

However, I assumed that the goal here is not to achieve maximum performance on a modern desktop CPU but rather to enable raylib to run on platforms that lack OpenGL support, including software rendering.

When properly implemented, the scanline method requires fewer computational resources and offers better cache locality, making it a more suitable choice for embedded systems and older hardware.

[Bigfoot71]

This repeats a lot of code that RLGL does for you.

RLGL already handles the OpenGL 1 like abstraction and the marxies, so I think it would make more sense to build from the modern opengl setup and render everything in rlDrawRenderBatch.

@ColleagueRiley Yes, I know, and it is a deliberate choice for several reasons.

The first is that we will be able to integrate its implementation directly into the parts currently dedicated only to OpenGL 1.1 only, we can therefore also be sure that it does not generate any duplication during the build.

The second reason is that if we ever want to implement lighting support, the current matrix stack system in rlgl for OpenGL 2+ could be problematic, especially when computing the normal matrix.

[ColleagueRiley]

@Bigfoot71 I'm also not sure if the dedicated legacy OpenGL backend makes sense, when it can easily be integrated.

[Bigfoot71]

@Bigfoot71 I'm also not sure if the dedicated legacy OpenGL backend makes sense, when it can easily be integrated.

@ColleagueRiley Do you also want to add shader support? Reinvent the Mesa driver for raylib? No one is going to do that.

Unless we use function pointers or something like that, but it's simply not compatible.

Anyway, the goal of this implementation is to enable raylib to run on machines that don't even have a software driver for OpenGL. We’re not going to implement what hasn’t been done for these machines ourselves, it would be absurd to think that.

[ColleagueRiley]

I meant it can be integrated into the modern API. I think it's more important RLGL is refactored to support additional backends. Not only to make this software rendering backend, but it would help users that want to add custom support for the native graphics API.

[Bigfoot71]

TL;DR: Adding support for modern APIs will require abandoning OpenGL, and in such a case, adding software rendering support for platforms that don't support OpenGL would then be strange.

---

Ah, excuse me, I see, but there would be several problems with that.

Relying on the batch system would just be a waste of memory in this specific case, unless we attempt very specific software rendering architectures, which wouldn't necessarily be relevant for the target devices (where memory is limited).

There is also the issue of the current management of matrices by rlgl, as I mentioned before.

Moreover, this could become increasingly confusing as to which features are implemented or not for each backend.

---

Also, I’ve reconsidered what you said about refactoring rlgl to allow the implementation of different backends.

If this is with the intention of implementing Vulkan, Metal, and D3D12, there will be many other problems that will arise, such as, for example, one of the most obvious that comes in my mind: VAOs.

Not to mention the specific implementations that will be needed to support OpenGL in order to align with the principles of immutable pipelines.

Implementing a modern API in the right way will require sacrifices for older APIs.

And here we are talking about a hypothesis that, if chosen, will take a very long time to materialize. I am ultimately quite skeptical.

Favoring modern APIs, neglecting OpenGL, but still adding support for software rendering seems like a somewhat obscure decision.

Anyway, this restructuring is a good idea in itself, but if it's done, then I find adding software rendering support quite strange.

In any case, I am just offering a potential solution to Raysan's long-standing request; it's up to him to decide.

[ColleagueRiley]

@Bigfoot71 It wouldn't require too many changes, it would be more of a reorganization effort. I don't think there's much benefit for direct support for DirectX or Vulkan, but it would be nice to be able to support native APIs.

This would not involve neglecting Legacy OpenGL, it could be implemented like any other custom backend.

As for memory usage, I'm unsure how much that would be a problem.

[Bigfoot71]

@ColleagueRiley There will inevitably be a choice to make regarding which APIs to prioritize.

For example, with Metal, if OpenGL is favored, it requires some consideration because if the Metal support is poorly suited to work with OpenGL, then wouldn’t ANGLE already do a better job?

Creating a low-level abstraction for multiple APIs, including both old and modern ones, will inevitably mean neglecting some, that's unavoidable...

So, my opinion is that:

• Either we prioritize modern APIs going forward, in which case software rendering support is irrelevant
• Or we decide to prioritize OpenGL, but I think projects like ANGLE will always do a better job than what we can achieve here

[ColleagueRiley]

The purpose of software rendering is to support certain platforms that do not support OpenGL, but many of those platforms would support GPU rendering via alternative APIs, for example, the Wii has its graphics API.

I don't think RLGL should be implementing these, but making it easier for users to implement their own would be nice.

[Bigfoot71]

Mhh I see, but creating a basic API that we can only judge as being adapted to the maximum number of possible APIs, including proprietary ones, seems like a bad idea to me.

[raysan5]

@Bigfoot71 thank you very much for this fantastic header! From my point of view, simplicity is key.

Being able to support some basic software rendering option for platforms with no OpenGL driver support with minimal changes in current raylib implementation seems a very valid reason to me. I specially have in mind the upcoming range of RISC-V micro-computers we will be probably seeing soon in the market (most of them with no GPU).

About the implementation into raylib, I see most rlsw functions map directly to OpenGL 1.1 counter-parts so it would be nice that the OpenGL1.1-mapping was done directly in the rlsw header, so in rlgl it can be simply implemented using:

#if defined(GRAPHICS_API_OPENGL_11_SOFTWARE)
    #define RLSW_IMPL
    #include <rlsw.h>          // OpenGL 1.1 software implementation

    #define GRAPHICS_API_OPENGL_11
#endif

Beside that, some platform layer (RGFW?) should support a raw color framebuffer initialization and screen blitting.

[Bigfoot71]

Okay, no problem, I'll continue writing right away.

Since some features of GL 1.1 related to certain function parameters are not used in RLGL, I will simply write a binding using macros and omit these parameters.

I will also create macros to generate functions based on rendering parameters and add line rasterization and blend modes.

This could go very fast!

[ColleagueRiley]

This doesn't make much sense to me. If you're going to add a software rendering backend, then it makes more sense to implement it as a custom backend rather than working around the legacy OpenGL framework, as it could be more performant and useful.

If you do not care about the performance, the legacy OpenGL backend can already easily do software rendering. Without any modifications to Raylib at all.

If you wanted to ensure it's rendering to a pixel buffer, you could use OSMesa. That wouldn't require any changes to RLGL.

[Bigfoot71]

as it could be more performant and useful.

@ColleagueRiley Explain why not implementing it through legacy OpenGL would be more efficient? Especially if you say "more useful", then what features would be missing? Knowing that any added feature will inevitably make it less efficient in some way.

you could use OSMesa

We have already talked about it: #3928 (comment)

And this may not be suitable for all scenarios considered by Ray.

[Bigfoot71]

No matter what, what we are doing here is not incompatible with your suggestion to refactor rlgl in the future.

And even if we implement the possibility of using different backends with rlgl, it does not solve the problem that each platform requires specific implementations for copying color buffers to the screen.

[raysan5]

@Bigfoot71 Just to clarify some points in case I missed something:

1. rlsw is a single-file header-only self-contained portable partial-OpenGL 1.1 implementation, that draws into an RGBA RAM memory buffer, right?
2. The required "OpenGL context" is actually sw_data_t, a global variable contained in rlsw implementation.
3. swFunctionName() are a direct mapping/implementation of the OpenGL glFunctionName()
4. The "only" requirements on raylib side for basic software rendering functionality would be:
   • InitWindow() - Provide a system (double)framebuffer to flip rlsw generated frames.
   • CloseWindow() - Free the provided (double)framebuffer and rlsw loaded "context resources"
   • SwapScreenBuffer() - Copy data and swap buffers, back to front
5. This implementation (plus some extra platform logic) would allow raylib running on no-GPU devices like RaspberryPi Pico 2 or similar RISC-V alternatives, is that correct?
6. In terms of performance, what is the performance hit in comparison to a GPU-accelerated implementation? Maybe 10% performance?
7. Is there any other single-file header-only portable alternative to accomplish the same?

Thanks for your answers! 😄

[Bigfoot71]

@raysan5

---

1. rlsw is a single-file header-only self-contained portable partial-OpenGL 1.1 implementation, that draws into an RGBA RAM memory buffer, right?

Yes

---

2. The required "OpenGL context" is actually sw_data_t, a global variable contained in rlsw implementation.

Yes

---

3. swFunctionName() are a direct mapping/implementation of the OpenGL glFunctionName()

Not exactly, I made a few simplifications compared to what rlgl does with GL 1.1, but I will add a binding corresponding to the OpenGL API that handles these small differences. It will be done through macros, and there will be no overhead.

---

4. The "only" requirements on raylib side for basic software rendering functionality would be:

* `InitWindow()` - Provide a system (double)framebuffer to flip `rlsw` generated frames.

* `CloseWindow()` - Free the provided (double)framebuffer and `rlsw` loaded "context resources"

* `SwapScreenBuffer()` - Copy data and swap buffers, back to front

That's exactly it, in the end, nothing more should be necessary.

---

5. This implementation (plus some extra platform logic) would allow raylib running on no-GPU devices like RaspberryPi Pico 2 or similar RISC-V alternatives, is that correct?

Exactly!

---

6. In terms of performance, what is the performance hit in comparison to a GPU-accelerated implementation? Maybe 10% performance?

It’s a bit early to say, the first video I presented wasn’t optimized yet.

I just added function generation based on the state (whether textures are being sampled or not, depth test on or off, etc.)

With this new addition, I now see the counter going above 2000 FPS for the same example, so I would say an improvement of around ~x1.5 roughly.

But it’s still early, other optimizations are still possible, and I will do thorough testing at the end.

---

7. Is there any other single-file header-only portable alternative to accomplish the same?

Contained in a single header with the same functionalities, no, at least not to my knowledge.

Edit: Aside from PortableGL, but it's different, as it aims to support more modern versions of OpenGL.
But, for example, shaders are managed via function pointers, which is problematic in our case.

[ColleagueRiley]

OpenGL 1.0 will already use software rendering by default if there is no GPU. I don't think this is fixing a clearly defined problem.

[Bigfoot71]

OpenGL 1.0 will already use software rendering by default if there is no GPU. I don't think this is fixing a clearly defined problem.

This depends on the platform and the driver

See for example:

• Raspberry Pi Pico (RP2040)
• Arduino Zero
• Arduino Nano 33 BLE

[raysan5]

@ColleagueRiley Actually it will allow this:

5. This implementation (plus some extra platform logic) would allow raylib running on no-GPU devices like RaspberryPi Pico 2 or similar RISC-V alternatives, is that correct?

For me this is the most notable achievement and step towards the future. Afaik, no other alternative allows that, at least in a simple way.

Note that this will expand raylib to low-level embedded devices and microcontrollers.

[ColleagueRiley]

Ok, I think I've said most of what I want to say on this.

I can help with the platform part.

[Bigfoot71]

@raysan5 SDL has been implemented!

I haven't pushed the CMake and Makefile changes yet, they still need cleanup and proper testing

I'm currently investigating some odd issues with certain examples that don’t appear when I attempt to reproduce them outside of raylib

However, integrating it to SDL was straightforward and required minimal adjustments.

Let me know if this setup works for you, here’s the commit: b9cfbeb

[raysan5]

@Bigfoot71 Those benchmarks look really promising! What CPU are you using?

Do you think it could be performant enough on a Raspberry Pi / RPI Pico? Definitely to be tested!

[Bigfoot71]

CPU are you using?

@raysan5 The same one I mentioned last time, a Ryzen 5 3600

Do you think it could be performant enough on a Raspberry Pi / RPI Pico? Definitely to be tested!

Given the improvements made since the test on my phone, which is quite low powered (a Redmi 9A), I think it's safe to say that it can definitely run on a Raspberry Pi

Comparing it with the specs of the Raspberry Pi Zero 2, a game running at 640x480 with around a hundred sprites on screen simultaneously at 60 FPS should be entirely possible

Of course, when using the software backend, we’ll need to be more careful with the pipeline states, for example, keeping a blend mode continuously enabled will significantly impact performance

As for the Pico 2, aside from rendering a few primitives, I don't think there's much interesting that can be done with it for now, I’ll get one anyway, I have a lot of ideas for potential improvements, but I need to have one in hand to determine which ideas are actually relevant

[Bigfoot71]

@raysan5 It's all good, the SDL platform is 100% functional now, here's an example!

So there's still a small issue with clipping in the video, I'll investigate that

And the FPS being at 59 seems to be a problem with the master branch, I’m seeing the same thing with OpenGL 3.3

output.mp4

[Bigfoot71]

The issue with nearby triangles has been resolved, it was actually caused by face culling, which occurs before clipping and division by W

The function contained an error related to negative homogeneous W values, everything has been documented

It's much better this way!

simplescreenrecorder-2025-05-18_18.13.54.mp4

Bonus, another example, I also see that there's a precision issue in the sampling that needs to be fixed, it's particularly noticeable with the text

simplescreenrecorder-2025-05-18_18.19.03.mp4

---

I'll resume work on the other platforms as soon as I have time
If anyone wants to help, there's already an example for SDL!