Still going strong on day 14 and really enjoying having someone of his experience level detail his thought process for the way he structures his code. For example, he has rather unique ideas about how to structure the code so that everything ends up in one monolithic compilation unit that we compile every time as distinct from using a build system that manages only rebuilding touched source files. He claims that for any project he's ever worked on up to hundreds of thousands of lines of code that it's faster than any moderately complex build system can manage even with parallelized compilation. It certainly reduces a lot of complexity out of a project that is only going to be handled by a few people, the current build file we're using is just a .bat with a single line call to the compiler that looks like
Code:
cl -FC -Zi ..\handmade\code\win32_handmade.cpp user32.lib gdi32.lib
and from there the main platform dependent file includes all of the other relevant source files.
A lot of his other practices tend to follow that principle of coding in a style relevant to your purpose. Instead of spending a lot of time up front designing APIs and defining his abstraction layers, which are more relevant in huge organizational projects that require many people to be working on different parts of the same code base at once, he just codes whatever he thinks he needs and routinely goes back and "compresses" the code, a term he uses in place of refactoring though I'm not sure I understand what difference he sees in the two. Early on he had all of his DirectSound, XInput and graphics buffer code stuffed in to the game loop in WinMain() just to get all of the pieces up and running, and over the last few days he's been pulling it out in to seperate functions that pass their values in to the abstracted platform independent game layer. Instead of designing that abstract layer first and trying to shoehorn the way we handle the windows specific operations required in to that pattern, it's been very easy to figure out all of the general things the game will need and construct the game layer in tandem with the platform specific stuff. Basically the opposite of how I'm used to programming having been fed a steady diet of UML diagramming and object orientated class design that tends to frustrate me when I actually dive down in to designing my program.
I will say that he has crashed and burned in one respect, that he spent so much time in the beginning and in the Q&A parts of each stream trying to bring beginning programmers up to speed. Even with years of programming experience I'm seeing lots of new things and having to work hard to keep up by looking things up on my own. I don't really see any way someone unfamiliar with C, bit operations, pointers and the like would not give up in frustration after the first week or two, and it's just akward seeing him devote time to explaining what a #define is or what a for() loop is before diving in to code that casts pointers of differing sizes to the same memory chunk and performing bit operations on them, or some other similarly complex operation.