good thing this is not an SDL tutorial xD

i'll address that things when needed but the project has like 500 lines, don't think that momment is now, to be honest...

Anyways, thanks for your support, lovely fellow

When I was younger my programs would start to fall apart after a few thousand lines. It took a LOT of practice, both writing programs from scratch and working on large programs that were correctly designed.

One thing to remember is the act of coding is a bit different from architecting a program. If you are unsure of how it is going to work it is probably not going to work and as your program grows in size will become unmanageable as you continually have to rewrite it to take things into account that you didn't plan on. It helps to become familiar with design patterns and to pseudocode the overall structure. Expressing your desired architecture into code is a big enough challenge without trying to do it at the same time.

my first idea was to use glfw indeed, but i took SDL cause it's easier to set up and it gives me audio, image loading/parsing and input.

The project will not stick to SDL anyways, the idea is to use it as a high level API, not to build a game with SDL. I would like to use this engine for PSP also, and i'll have to take SDL out and put osLib in. problems for future me...

handmade hero is a piece of art, upvote

interesting, i'd suggest you to follow the blog, iv'e already implemented something like a dynamic array in the first post and will have to implement some other "modern" things in the near future, it's awesome what you can do in C89

Just want to explain how things works, i don't know if i'll ever finish this proyect, but if i don't i want the things i did explain crystal clear, i want every concept well presented so every single post in the serie can be a piece by its own and you can learn something. I'm now trying to write two articles a week but it's hard, coding C89 is not fast, there are a lot of cavities and undefined behaivours xD

C gives you all control over your machine, there are no obscure libraries, grabage collector or unexpected stuff, if something doesn't work as expected you know you have fcked it up. I'm using C here cause 1st, i like it a lot, and 2nd, i think it's the clearest language out there, you can follow the code execution from start to end and "almost" know what's happening, it doesn't have function overloading, obscure scopes, garbage collectors or automatic weird typing.

Perhaps, but C is unsafe both in terms of types and memory (Which has to be considered if choosing C for a project)

HN users tend to parrot the safety line a lot because most people are working on web applications that store somewhat important user data, so gaining access to a remote machine due to a buffer overrun issue is catastrophic, but in games, especially in single player games, safety is less of an issue or even a non-issue. With a multiplayer networked game, cheating, attacks on servers and attacks on other players clients are a concern, but in a game that is entirely or mostly single player the worst outcome of unsafe code is that it crashes to desktop.

Nobody's complaining about the barbaric OS and network stack written in C. The safety nazis' bleating means little if they can't produce a viable alternative. Where are the high performance OSs written in Ada or whatever next big thing is?

What? Operating systems are big projects and the tools to write them safely (and open source) haven't existed for very long, so it's a question of manpower and effort not technology. C has almost no performance benefits these days, either, due to advances in compiler optimization; if anything it can be less as other languages can provide more static guarantees to the compiler to use when optimising.

That network stack written in C gave us heartbleed for example. If C arrays were bounds checked by default (e.g. they carry around their size), this could've been easily avoided at no runtime cost.

How can you honestly complain about people wanting more safety in software? If it's speed ("high performance") then you're probably implementing yourself in C (e.g. Bounds checking) something that is built in either at runtime or even statically as can be done in some cases.

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.

Modern C++ would be a huge improvement to start with.

Rust is probably there, if under specified. D is definitely fine for writing operating systems (Question being whether to use druntime or not).

I know nothing about Zig, beyond having had a look and not being hugely impressed.

true, i'd never do a C89 game from scratch as a profesional project, but this is not a profesional project, it's more like a hobby-academic approach to the lower level of game engine design :D

Indirection, pointer casting, and the C standard library actually make things quite opaque in practice. Do you sbrk your own memory or use malloc? Malloc may not be as mysterious as GC, but it’s still a runtime-managed resource.

You can replace malloc with your own implementation. Just have a big static array to dole out bits of memory. The loader or startup code will prep it for you.

Well, the point is to learn how to build an engine with modern capabilities (those that you are supposed to use with C++ like namespaces, methods, ECS architecture, networking...), SDL is just a tool to not having to write the whole window/input/media/opengl logic from scratch. I could write a SDL tutorial and make a game in 3 hours; it's not as interesting i think, for me the objective is not to write a game but to explain how engines works and desmitify them a little :S

But you are right, it'll take a daaamn long time. I've the third and the forth parts almost ready, covering the engine architecture itself, the private scene scope and the image->texture->sprite stuff but i havn't started yet with ECS, fs, configurations, physics, networking... this field is really extense.

I totally agree with you, but as you know, a CPU is pretty complex and is not possible to explain it all in just one article. Before writing it i've been looking for something similar and have not found any other article that explains as much as i've covered, so, to me it can be considered far from being perfect but "good enough".

Also, i'm technical but don't want to spoon-feed anyone, the article says what a logic gate is, how are they built and which ones are the basic ones, after that, just some wikipedia and google will be enough to teach any reader how to build the other variations, same applies to flip-flops.

I'm not witting this as rude as it looks, indeed, i agree that i've been far from explaining exactly how everything works and fit together, but i tried my best to make it simple, not too techie and easy to read, and becoming a text-book was just out of my scope.