Writing a game engine in pure C: The Graphic Initialization

This looks like a lot of complexity up front with no foreseeable payoff.

Why are we implementing a whole dynamically allocated stack for states before doing anything domain specific?

How many states could you possibly be expecting to have in a full game? 3? 12? 100? The examples of states were like the menu, action screen, and pause screen. So it sounds like very few. Drop the realloc'ing and free'ing and just statically allocate N states and be done with it. Save this complexity for something that really needs it.

Plus are you going to free the stack any time other than when you quit the app? I doubt it. The OS will free everything for you when you quit so there's no reason to waste time on that either.

The code so far looks like mostly a waste of time.

>JavaScript today has the same problem: you can’t just start writing a web app because two lines into a tutorial you’ll be barraged with “So this is actually an ES2017b.71 feature that we’re enabling using babel-ts-flooginator, therefore you also need TypeScript and that means you need to...”

That's not a problem with javascript, it's a problem with the development culture, its schizoid relationship with the language and its obsessive need to be "cutting edge." You can, absolutely, just start writing a webapp because vanilla JS and even jQuery still work perfectly well. What you can't as easily do is find tutorials that don't assume Javascript has to be compiled from another language and pushed through a complex tech stack before you can even approach it.

What do you propose? Replacing the system stack with Ada?

Modern successors to C, such as Zig, and modern successors to C++, such as Rust, are still too young to be used for serious re-implementations of the lower layers.

Handmade Hero is not at all a demonstration of how one would actually approach making a game in C/C++, though. In real life, you would use existing libraries instead of reimplementing everything from scratch.

Right now I'm heavy into C++, especially C++17, but mostly due to the current project I'm working on (tools engineer @ gamedev)

20 years ago, my first project was being part of 4 people team porting Metal Gear Solid from PS1 (PSX) to PC. This is when I saw how good written "C" code could be done. Even if it had only japanese comments in the code (understandable).

The pure and simple structure, where most of the functions had TCL-like interface:

int ACT_Work( int argc, sometype* argv ) { // bit of argc/argv parsing Do_Work() }

then above was exposed to a TCL-like scripting language, used for setting up level objects... We are talking about 500-600kb of memory used by the main executable + 300-400kb of 'overlay' memory where "shared, e.g. dll/so-like" code gets replaced depending on what objects needs to be in the game (Mentioned "overlay" as this was very well established practice back in the DOS days).

Things really were plain and simple. API-s too. It was so easy to grasp what's going on.

Then again, since this was running on what looks like really limited machine, it had to do only such and such. No fancy animation controllers, advanced physics, collision, etc. etc.

at some point, especially if it's a content creation tool (think Maya, or any Autodesk product, Houdini, etc.) then you need to be able to handle tons of "nodes", "entities", meta-data, etc. - but when it comes to a game, even nowadays - pre-cooking gets you there, and quick deserializing - either piecewise, or whole sections, and then pointer fixup.

Point is, is your game, and engine meant to be content creation tool too?