-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[rlgl] Software renderer support? #3928
Comments
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 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. |
is that replacing OpenGL? |
For software rendering; Yes @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. I have almost implemented everything necessary compared to TinyGL, and plan to implement the missing functions, some of which have already been done like |
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 The 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 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! |
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. |
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 |
It sounds promising. A software renderer may enable more use cases of Raylib, such as image rendering on servers without OpenGL context. |
Just a tentative issue to study the possibility of supporting basic software rendering using the new library: https://github.com/Bigfoot71/PixelForge
The text was updated successfully, but these errors were encountered: