It currently clocks it at 12.5K but that includes stuff that could easily be stripped out. I suspect, even if I had it "finished" with everything I would ever want in it, it wouldn't be more than 15-20k. PGL saves a lot by not bothering with GLSL at all.
Glad you found it fun to play with, that's what it's for. Hoping to have a new release in the next week or so, and there have been some serious/breaking changes since the last so hopefully it goes well.
And on the topic of this thread, PGL is overkill for raylib's software rendering backend since they don't need arbitrary shader support, but I would still love to try making PGL a raylib backend someday because it would be cool and running the entire set of Raylib examples would be a great stress test. Plus then I could use raylib to make a game with PGL, win-win.
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.
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.
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).
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
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/)
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.
Glad you found it fun to play with, that's what it's for. Hoping to have a new release in the next week or so, and there have been some serious/breaking changes since the last so hopefully it goes well.
And on the topic of this thread, PGL is overkill for raylib's software rendering backend since they don't need arbitrary shader support, but I would still love to try making PGL a raylib backend someday because it would be cool and running the entire set of Raylib examples would be a great stress test. Plus then I could use raylib to make a game with PGL, win-win.