The Windows specific code is localized in the platform code and this could be swapped with something Linux or OS X specific at any time.
The HH code is just plain bad, dangerous, unnecessarily 'optimized' (read: taking ugly shortcuts or incomplete simplifications) in places where it doesn't matter, while super-inefficient in places where it does, it's untested, full of TODO's, does not use any modern language/compile features, it's basically just a lot of lines of code thrown together with minimal design (I do like his seperation between the platform layer and the game layer though). I've watched and enjoyed over 100 hours of HH, and the process the game is going through is very interesting, but in terms of code quality and suitability to 'learn game programming' I would not recommend it.
You made me curious, what do you consider a good programming style for game programming ?
Well, I would ;-). I think the quality of the code he writes for the game scores low on almost any objective measure of quality except pragmatism.
>> You made me curious, what do you consider a good programming style for game programming ?
I don't think there is a single 'good programming style' for games, it all depends on the game, the development environment (language, tools) the third-party components you use, the target platform, etc. I think there's a lot of best practices you could apply to any game though. Applying abstraction in those parts where it matters and doesn't negatively impact performance, for example. Defining the components of your game and keeping clear boundaries between them. Making good use of the language features at your disposal. Not obsessing over constant factor performance 'optimisations' before you know where the bottlenecks are. Thinking about and preferring efficient algorithms and data structures, over quick & dirty 'handmade' data structures, just because you feel STL or boost are 'not efficient' (it doesn't matter for 99% of your game code, especially not for something simple as HH). Not passing around naked pointers everywhere. I could go on for a while...
If you watch Casey work on HH, most of the time he's fiddling with and rewriting the same things over and over again, because he feels that he always needs to program everything 'in the simplest possible way' first, and then rewrite when necessary. I don't disagree with throwaway code at all, and not everything always needs to be 'designed upfront', but he's taking these things to the extreme, which results in an entangled mess of spaghetti code full of bugs (which you'll have seen he runs into in almost every episode of his stream). He basically disregards all the advances we've had in programming since the 90's, and keeps hammering in C-style code that happens to be compiled by a C++ compiler, but doesn't use any of the advantages C++ provides.
I still like to watch him do it though because there's definitely educational value to his videos, and he does solve some interesting problems along the way. And because I've been working on a simple game myself for a while. In my earlier comment I refrained from plugging my own little side-project but now you've asked you could take a look here [1] if you wanted to see how I like to program games. It's about an equal amount of hours in as HH but it already has some actual gameplay, is fully scriptable using Lua, Box2D physics, a sprite-based OpenGL rendering backend, persistency (freeze/unfreeze), action replays with live code updates (inspired by HH, but done 'the right way'), texture-mapped truetype font rendering, some interesting 'handmade' algorithms (complex polygon triangulation, sprite packing), motion controls, etc. I realise it's not the same thing as HH as I prefer not to re-invent the wheel for everything and use libraries and frameworks, but I still feel it's much closer to how you would program a 'real' game using modern technologies.
Using libraries, even the STL in C++, would be cheating.
In the bigger picture of things these abstractions have costs. They're not free despite the C++ propaganda machine telling us otherwise. It's important to know what those costs are in order to make effective decisions about whether to include them in your project.
And finally the golden rule: if it looks right it is right. We're not here to write pretty, elegant code. Your pretty abstractions don't matter to the hardware. The target platform your system runs on is likely a highly-optimized piece of circuitry with real, physical constraints. Casey is the first programmer I've seen teaching people to keep the Intel manual handy and how to implement data-structures for cache-efficiency instead of pretty abstractions and virtual machines and template meta-programming.
It may not be a style of programming that agrees with you but it's one that has a growing number of proponents from Casey to Mike Acton, Jonathan Blow, and others. It's not a new idea either... but it certainly distinguishes itself as a reaction to the normative notion of programming by abstraction. It's a philosophy that proscribes programming by mechanical sympathy; using machines to manipulate data to get the results you desire.
>> In the bigger picture of things these abstractions have costs. They're not free despite the C++ propaganda machine telling us otherwise. It's important to know what those costs are in order to make effective decisions about whether to include them in your project.
Based on years of writing all kinds of software I can only disagree with this. Even in games there's such a tiny amount of code that would really benefit from going all the way down to the bare metal to avoid some constant-factor overhead of higher-level abstractions, that it rarely makes any sense to even think about these things before you have working code you can run through a profiler. Almost always, spending your time and effort finding and using higher-level abstractions pays off much more than tinkering with your ghetto-hashmap implementation 'to make it faster'.
>> It may not be a style of programming that agrees with you but it's one that has a growing number of proponents from Casey to Mike Acton, Jonathan Blow, and others. It's not a new idea either... but it certainly distinguishes itself as a reaction to the normative notion of programming by abstraction. It's a philosophy that proscribes programming by mechanical sympathy; using machines to manipulate data to get the results you desire.
Philosophically, that's all nice and dandy. Practically speaking, it doesn't make much sense though, except for educational purposes (and even then, only up to the point of showing how things work, then moving on and settling on a proven, battle-tested version of the same thing that you don't need to maintain and debug yourself. At least that's my opinion...
False dichotomy.
If that were true, skill and knowledge wouldn't matter.