This is a personal and debatable opinion unrelated to C, but I find giant files to be unreadable from a diving-in-a-new-codebase standpoint. I consider it a good engineering practice to separate logical units in distinct files. The author has another project which does this: https://github.com/vurtun/mmx .

I think there’s a balance between micro and humongous source files. An analogy with writing, think about having paragraphs of one line versus one giant paragraph, you want neither.

In fact, with the lack of a standardized package manager and build system, for C and C++ projects it is often preferable to simply have a source file or two for a neat feature. Other options are generally:

Rely on the system headers and libraries to exist/be the correct version (via aptitude or whatever)

Bundle the full source files in a lib/vendor directory and tweak the build system to build them too if needed (for say dynamic libs)

Carefully package up the library headers and static libs, and hope you’re building with the correct versions (architecture, debug settings, linkage, etc.)

And then there is the joy of trying to actually step-through that garbage when debugging.

Or, you can just add a big honking header file like this, and move along–though I think it would’ve made more sense for it to be header+single source file. In this case, builds look normal, debugging is the same as for your own code, and everything can be simpler.

I don’t care that the distribution mechanism is a single header file. I care that the original code is a single header file. I’d also like to point that having a single header file does not relieve you from your duty of carefully setting the architecture, DEFINES and compiler flags when including this dependency in your projects.

The credit section refers to handmade hero as the inspiration. Generally it’s not only a 2D game but also an online live-streamed every day development of the game. Casey does it from scratch and encourages people to not being afraid of jumping into the nitty gritty details and doing things themselves without heavyweight libraries doing all the work.

Casey explains and writes every line of code on stream (archived on YouTube) and the discussion sometimes (d|e)volves into how shitty current tools are for his needs. He’s inspired people to write new debuggers and all sorts of other things.

I wonder if writing features for, say, OpenBSD on video stream could attract a similar audience. Like garbage.fm but with code and even more attitude.

Are you familiar with his writings on immediate mode graphics? Can you recognize if/how caching works in this lib? It seems like one of the downsides of immediate mode for a GUI is pinning a CPU to redraw every control even though they won’t change on 99% of frames. I took a look at the API and it looks very imperative; I can’t see where you could render to a buffer and blit that until something actually changes.