4 ms·

Nice! PortableGL is also great, OpenGL api that is defined in entirely in C and writes the “framebuffer” into an SDL window https://github.com/rswinkle/Portab

Nice! PortableGL is also great, OpenGL api that is defined in entirely in C and writes the “framebuffer” into an SDL window https://github.com/rswinkle/PortableGL https://github.com/rswinkle/PortableGL

rswinkle 4y ago
Minor correction/clarification, the library doesn't depend on SDL, it just writes into a 32 bit color frame buffer, but all the demos/examples use SDL for getting it to the screen since that's the best option. The test suite just writes frames to disk as png images to compare against expected for example.
jstimpfle 4y ago
It's an implementation, not an API.
- sylware 4y ago
  ... and it is opengl-ish, namely seriously castrated (shaders). Borrowing maths from Mr. Bellard's tinygl.
  - rswinkle 4y ago
    Depends on how you define castrated. It's not like using C or C++ is really limiting and using a C++ math library (like my own rsw_math or more complete glm) lets you basically write it in GLSL. It's not like there's anything you can't do. And the only math from Bellard's TinyGL that I use is his clipping code, maybe 80 lines of code give or take. Not to diminish Bellard at all, if anything I'm saying any problems with PortableGL are mine not his.
    - sylware 4y ago
      My bad, I used "castrated", it is not what I really wanted to say. I should have said a subset of opengl features. Namely, it is not a software GL implementation you can run an opengl4 3D game on (only those horrible c++ diarehas which are llvm with things like llvmpipe or the other one from intel are supposed to be able to do so).
      - rswinkle 4y ago
        Yeah PortableGL will never be completely fully featured, not even for OpenGL 3.3 since I'll definitely never do the geometry shader and probably not the transform feedback. But specifically it'll never have the earlier immediate mode stuff, or some of the big 4.0 stuff like the tessellation shaders. I have been meaning to add the DSA functions where they make sense. They'd be really simple to implement. Actually a few days ago someone sent me a pull request adding an interesting project to my README https://github.com/rswinkle/PortableGL/commit/e0652b4dff266d7ea521ac54500ef28828797310 https://github.com/rswinkle/PortableGL/commit/e0652b4dff266d... So now if I were to try to sum up all the OpenGL software implementations I can think of, TinyGL (and modern improved forks) = OpenGL 1.1-1.3 ish osmesa = OpenGL 2.1 using Mesa 7.0.4's swrast PortableGL = OpenGL 3.x-ish Mesa = 2 software renderers still included, gallium based softpipe and llvmpipe and I think one or both support the latest OpenGL 4.6 but I could be wrong. swrast and Intel's gallium/llvm based OpenSWR have both been removed from mainline Mesa, and the latter only supports 3.3 core-ish (https://www.openswr.org/ https://www.openswr.org/) I'm sure there are others out there. I've actually never tried to use "Stand alone" Mesa. I really should to see how it performs if nothing else, but I still say nothing beats the single header library for ease of use.

rswinkle 4y ago

Minor correction/clarification, the library doesn't depend on SDL, it just writes into a 32 bit color frame buffer, but all the demos/examples use SDL for getting it to the screen since that's the best option. The test suite just writes frames to disk as png images to compare against expected for example.

jstimpfle 4y ago

It's an implementation, not an API.

sylware 4y ago
... and it is opengl-ish, namely seriously castrated (shaders). Borrowing maths from Mr. Bellard's tinygl.
- rswinkle 4y ago
  Depends on how you define castrated. It's not like using C or C++ is really limiting and using a C++ math library (like my own rsw_math or more complete glm) lets you basically write it in GLSL. It's not like there's anything you can't do. And the only math from Bellard's TinyGL that I use is his clipping code, maybe 80 lines of code give or take. Not to diminish Bellard at all, if anything I'm saying any problems with PortableGL are mine not his.
  - sylware 4y ago
    My bad, I used "castrated", it is not what I really wanted to say. I should have said a subset of opengl features. Namely, it is not a software GL implementation you can run an opengl4 3D game on (only those horrible c++ diarehas which are llvm with things like llvmpipe or the other one from intel are supposed to be able to do so).
    - rswinkle 4y ago
      Yeah PortableGL will never be completely fully featured, not even for OpenGL 3.3 since I'll definitely never do the geometry shader and probably not the transform feedback. But specifically it'll never have the earlier immediate mode stuff, or some of the big 4.0 stuff like the tessellation shaders. I have been meaning to add the DSA functions where they make sense. They'd be really simple to implement. Actually a few days ago someone sent me a pull request adding an interesting project to my README https://github.com/rswinkle/PortableGL/commit/e0652b4dff266d7ea521ac54500ef28828797310 https://github.com/rswinkle/PortableGL/commit/e0652b4dff266d... So now if I were to try to sum up all the OpenGL software implementations I can think of, TinyGL (and modern improved forks) = OpenGL 1.1-1.3 ish osmesa = OpenGL 2.1 using Mesa 7.0.4's swrast PortableGL = OpenGL 3.x-ish Mesa = 2 software renderers still included, gallium based softpipe and llvmpipe and I think one or both support the latest OpenGL 4.6 but I could be wrong. swrast and Intel's gallium/llvm based OpenSWR have both been removed from mainline Mesa, and the latter only supports 3.3 core-ish (https://www.openswr.org/ https://www.openswr.org/) I'm sure there are others out there. I've actually never tried to use "Stand alone" Mesa. I really should to see how it performs if nothing else, but I still say nothing beats the single header library for ease of use.