I hope you've all been doing well! I have some very exciting updates this month.
Handmade Seattle Tickets On Sale!
Handmade Seattle, the spiritual successor to the Handmade Con conference that we all enjoyed and hosted by one of the original Handmade Network founders Abner Coimbre, is going to be happening in the Seattle Center on November 16th, 2019. Tickets have recently gone on sale, so don't forget to get yours while you still can, before the conference is sold out! Click here to do so.
Handmade Seattle is going to feature a number of things, including speaking events by notable software engineering industry veterans Mike Acton, Tom Forsyth, and Chris Hargrove, as well as a number of projects.
It has been announced that a few of Handmade Network's projects will be showcased at Handmade Seattle, including:
4coder (by Allen Webster): The code editor used by several prominent members of the community, written from scratch and depending only on the operating system and the CRT, allowing you to customize it in C/C++. Fun Fact: I am even using 4coder to write this blog post!
The Melodist (by me!): A game in which the lines of physical reality and music are blurred. Written from scratch in C and C++, depending only on the operating system and the CRT.
Several other amazing projects, all coming from a different software engineering space with creators from a wide variety of backgrounds, will be showcased at Handmade Seattle as well, including the Zig programming language, LOVR (a VR game framework), and Principle (a user-interface and interaction design program). These are not the only projects, so I recommend you learn more at the official Handmade Seattle website (where you should also purchase your tickets).
Memory Allocation Articles
I was recently reminded of some very wonderful articles written by the community's very own Ginger Bill, creator of Handmade Network programming language project Odin, which cover the basics of memory allocation, how one should reason about approaching a memory allocation problem, and thinking about memory allocation and the requirements that your problem provides.
The set of articles begins with an overview on a quadrant based model of memory allocation, which models the problems in the following way:
In any given memory allocation problem, there are two attributes of your data that you care about: Variability of your data's lifetimes, and variability of your data's sizes. Both of these attributes can fall into two possible categories, for a given problem: They can either be predictable, or not predictable. Quick combinatorics pop quiz: How many permutations is that?
That's right, four permutations! There are two attributes, each of which can have two independent values, which forms four possible cases:
1. Your data has predictable sizes, and predictable lifetimes. This is a very comfortable case to be in, because your allocation requirements can be simplified to be identical for all individual pieces of your data. You only need to reserve enough memory for the maximum number of data pieces you care about (which is predictable), and for only the period of time that spans an identical lifetime for all pieces of data. This is a trivial allocation case, and can help simplify your program's allocation requirements.
2. Your data has unpredictable sizes, but predictable lifetimes. This is another simple case, but it becomes more difficult to predict the amount of memory you need, in which case you may have to resort to an initially arbitrarily defined upper-limit for your memory usage, but tweak it overtime as your program develops.
3. Your data has predictable sizes, but unpredictable lifetimes. This is more complicated than the first two cases. A common solution to this case is to make use of a "memory pool". In this solution, you partition your memory into chunks that fit the sizes you predict, and maintain a "free-list", which is a linked-list of free chunks. When an allocation is required, the head of the free-list is taken and returned as the block of memory. When the allocation is freed, it is added back to the free-list.
4. Your data has unpredictable sizes, and unpredictable lifetimes. This is the most complicated case in this model, which will require a system that can handle both (like a general purpose allocator).
If you are able to simplify your allocation needs to cases #1 and #2, many parts of your code can be simplified! For example, you don't need to free individual allocations when you can predict allocation lifetimes, because you can free those allocations in one big block when the predictable lifetime ends (like a frame-based stack allocator).
This is just my interpretation of the quadrant model used by Ginger Bill, but if you are interested in learning more about this topic and also diving into some implementation details, I highly recommend you take a look at the articles.
Community Showcase
Chen's Fantasy Console
Community member Chen, creator of Handmade Network project Monter, posted a talk about a low-level fantasy console, with an included proof of concept! It looks really promising and exciting; I recommend checking it out!
Dan Zaidan's Stream Series
Community member Dan Zaidan is streaming the creation of a game, from scratch, in C, very much along the lines of Handmade Hero (though at a smaller scale). It touches more upon gameplay code, and seems like it explores some pretty interesting ideas and shows some promising early result!
If you'd like to check out more of the community's showcase posts, or even post some of your own, come join the community Discord server, where we regularly discuss interesting programming projects and problems!
Conclusion
That's going to be all for now, folks. Don't forget to buy your Handmade Seattle tickets!
Until next time,
Ryan