PortableGL VS incbin

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/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

PortableGL: An implementation of OpenGL 3.x-ish in clean C\ (23 comments)

Not entirely related to the subject of OpenGL, but I really like how the author has decided to lay out this project. It's pretty hard to beat the convenience of a single header (or single header/single source) distribution for C libraries, but library development gets progressively harder as the project gets bigger as more code is added to the (usually hard to navigate) header file. Here, the author does their development with multiple files as one normally would, but when a new version is released they run the generate_gl_h[1] script that concatenates everything into a .h file for distribution. Simple yet flexible! This is also how SQLite[2] distributes its builds. It's a pattern that I'm using myself in some unreleased projects.

[1] https://github.com/rswinkle/PortableGL/blob/master/src/gener...

OK, yes, that does work. You can totally put application specific stuff in the elf and reflect on it at runtime. Much easier is to embed it directly and point a symbol value at the start of the data.

See https://github.com/graphitemaster/incbin for a pretty wrapper around that.

Aside from there being a drastically simpler answer to this problem available in sketchily documented fashion (the asm guys know .incbin is a thing, but higher level languages overcomplicate it), it's a good post. Idea is sound and goal was achieved.

Thanks for the link. We also make static websites by direct inclusion their HTML code in the C++ binary of ClickHouse.

I've tried to use this library but found a bug: https://github.com/graphitemaster/incbin/issues/61

won't work, since the preprocessor won't interpret directives inside string literals of course.

In many assemblers, there is a directive called "incbin" which pastes in unstructured binary data at the point of usage. I just found a very clever C and C++ wrapper [1] for that, which gives you an INCBIN() macro. Nice!

[1]: https://github.com/graphitemaster/incbin

There's always this: https://github.com/graphitemaster/incbin

Haven't the people making the standards other things to do, like, integrating useful features instead of duplicating incbin.h [0] years after that feature worked?

https://github.com/graphitemaster/incbin/blob/main/incbin.h

There is a project "https://github.com/graphitemaster/incbin" that can take a file and put that file content into the sketch ROM segment as constant / resource. It is an even nicer alternative to "xxd -i" or using string literals like: const char bla[] PROGMEM = R"CERT( ... )CERT";