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!

[rlgl] Software renderer support? #3928

Description

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions