20k LoC single header file? NOPE.
-rw-r--r-- 1 fsaintjacques staff 666K Apr 19 09:30 nuklear.h
Could you elaborate for those of us less familiar with C? Why is that a dealbreaker?
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.
With respect to my colleague here, it’s not actually a dealbreaker.
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:
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.
Fair enough, fair enough. That said, for something like this, I’m more concerned about ease of integration than how clean the black box looks inside–hence, my preference for a single file.
The amount of interesting stuff that has come as a more or less direct outcome of Casey Muratori’s Handmade Hero is just heart-warmingly great.
Handmade Hero looks like a 2D sprite-based game. Which part did this come from, can you elaborate?
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.
Sorry, I have no knowledge about that.
(For reference, this is what was previously known as zahnrad)
I really like that there is support for pie/radial menus and it’s demonstrated in the README.