[rlgl] Software renderer support?

[raysan5]

Just a tentative issue to study the possibility of supporting basic software rendering using the new library: https://github.com/Bigfoot71/PixelForge

[Bigfoot71]

I'm currently working on verifying that all the necessary features for rlgl are implemented and reviewing the API to facilitate its integration.

Firstly, we should therefore think about how to update the window framebuffer in a simple and efficient way.

The first idea that comes to mind would be, roughly, to add a #ifdef SOFTWARE_RENDERING case in the EndDrawing() function and proceed with the update here, but this goes beyond the "framework of rlgl."

And there are also other points that may require consideration, such as the fact that "textures" are not managed via identifiers by PixelForge but are full-fledged structures.

[MrScautHD]

is that replacing OpenGL?

[Bigfoot71]

is that replacing OpenGL?

For software rendering; Yes
Entirely: No

---

@raysan5 Otherwise, if the fact that textures are managed via structs and not by identifiers with PixelForge is an issue for its integration into raylib, there is TinyGL by Fabrice Bellard, and another repository that has taken it up: https://github.com/C-Chads/tinygl/tree/main

I don't plan to change the fact that textures are managed by structs to do like TinyGL, my library is intended to be inspired by the OpenGL 1 API but not entirely copied.

Perhaps TinyGL would be much simpler to integrate than PixelForge in this regard.
On the other hand, the fact that glOrtho is missing in TinyGL can also be problematic for raylib...

I have almost implemented everything necessary compared to TinyGL, and plan to implement the missing functions, some of which have already been done like glOrtho or glPointSize for example.

[Bigfoot71]

Also, one thing I've considered is that mesh uploading to the GPU happens automatically in most cases, which might need to be reviewed, perhaps with definition checks.

And UploadMesh should be removed, no ? (or rather that the function does nothing)

The Material structure would also need to be reconsidered in the case of software rendering support.

It's quite tight since raylib uses glfw by default, we'll have to deal with OpenGL directly.

With SDL, it's simpler because we can easily access a window's surface and update it directly, SDL handles everything in the background.

---

Edit: For the issue of textures not being managed by ID in PixelForge, we could perhaps do something like typedef pfTexture Texture2D; for its integration into raylib?

But this suggestion clearly falls outside the scope of RLGL.

After checking, I realize that if we intend to make this addition to raylib from rlgl, it would require modifying a certain number of function signatures, which is not feasible.

PixelForge therefore does not seem to be the most suitable choice unfortunately for doing it this way.

TinyGL would be much simpler to implement, but it would require a version that adds at least support for 'glOrtho'.

I would be happy to do it if it's for raylib!

[Bigfoot71]

One thing I'm thinking about all this...

The basic idea would be to enable software rendering via rlgl, but that would remove OpenGL support from rlgl (for software rendering), while it would still be needed with glfw in the context of raylib, so using OpenGL outside of rlgl seems odd to me.

If you say rlgl can, for example, handle texture updates via OpenGL itself while being compiled in "software" mode, I would find that even stranger.

The ideal solution would therefore be to allow the use of both rendering modes, via a switch between the two modes for example.

Well, it's easy to say, but much harder to do properly, it's just an idea.

[RobLoach]

Another promising implementation is PortableGL from @rswinkle.

[colesnicov]

Another promising implementation is PortableGL from @rswinkle.

I am look at like the pook. Impressive.

[Bigfoot71]

Another promising implementation is PortableGL from @rswinkle.

I am look at like the pook. Impressive.

Really yes, we really need to look into this further, it would be great at first glance for raylib

[bohonghuang]

It sounds promising. A software renderer may enable more use cases of Raylib, such as image rendering on servers without OpenGL context.