[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.

[raysan5]

@bohonghuang Actually that use case is already possible with provided Image*() functions, latest commit 4c9282b also allows Font loading with no need of an OpenGL context / GPU.

[raysan5]

@Bigfoot71 What is the state of PixelForge? I've seen you keep working on it and you also have some raylib examples!

[Bigfoot71]

@raysan5 Yes, indeed, I'm still working on it, although I'm struggling to find time for it.

Currently, I'm focusing on SSE(x)/AVX2 optional support before moving on to other optimization ideas for its architecture.

But as I mentioned, I'm currently severely lacking time...

You can find the current progress on SIMD support here: Bigfoot71/PixelForge#3

These advancements include SIMD-compatible bilinear sampling and some other nice little things.

[dineth-lochana]

I don't know anything about the implementation of graphics APIs, but I can share some of my own experiences with OpenGL and Software Rendering. There are some edge case devices like my HP Probook 4430s, which has broken OpenGL support on Windows. It still runs OpenGL, but it is very much slow, and I have seen that in games like Doom, Software Rendering is much more faster on my PC than OpenGL (old or modern) ever is.

Even though I'm certain Raylib would benefit from Software Rendering, if Raysan and the other contributors deem it unwanted, it's fine as well. Most people do fine with OpenGL, and it doesn't seem to be going away anytime soon. Vulkan support seems to have stagnated, and most people target DirectX (90% of games on Steam in 2023)

[wwderw]

I would love to see a software renderer here. I have some projects that just don't need all of what acceleration provides and it would be nice not having to depend on whatever the popular flavor of graphics API that there is.

I was wondering (and I know just enough to cause damage) would it be possible with the SDL backend to use their software rendering? I don't know if that would make things easier or if it would make it harder with getting it into Raylib or is it better if it is going to be done that it's Raylib's own implementation (or a small header library implementation).

[Bigfoot71]

@wwderw raylib already has everything needed under the hood to do simple rendering of 2D shapes or images within other images. Here, the question of software rendering would be to be able to use all of raylib's rendering functions, including those like DrawCube, DrawMesh, DrawModel, etc., to perform direct rendering to the screen in a software manner. Therefore including the steps of clipping, rasterization, color blending, etc...

Edit: What you would do with SDL, that is, create a surface, draw your pixels, and update the window surface or your renderer, is equivalent in raylib to creating an image, drawing in it, and then updating a texture that you subsequently render to the screen

[wwderw]

@Bigfoot71 already has everything needed under the hood to do simple rendering of 2D shapes or images within other images. Here, the question of software rendering would be to be able to use all of raylib's rendering functions, including those like DrawCube, DrawMesh, DrawModel, etc., to perform direct rendering to the screen in a software manner. Therefore including the steps of clipping, rasterization, color blending, etc...

Edit: What you would do with SDL, that is, create a surface, draw your pixels, and update the window surface or your renderer, is equivalent in raylib to creating an image, drawing in it, and then updating a texture that you subsequently render to the screen

Yep, just know enough to cause damage. Fact that I didn't think that it already had some capability shows it right there.