is presently its sole maintainer,
You can support him:
A recap of previous stream.
New test assets for Handmade Hero project.
Introduction to loading BMP files.
Handle player moving up and down 'stairs' before the BMP loader.
Moving up an down implementation.
Difference between tile map system and tile map positioning system.
Fixing generation code.
Generation code fixed.
Implementation complete. Working tile map system.
Loading BMP files.
A talk on the game's screen resolution.
Crash course on how to read file formats.
Debugging a BMP file in memory.
Processing the BMP file header.
Packing a struct to avoid padding.
Processing the BMP pixels.
Perfect pitch would sell that!
I missed the part where you handled the endianness of the file, or are bitmaps always the same?
Do you prefer #pragma pack or gcc-like annotation?
What's your threshold for number of function parameters before putting them into a single structure?
Could you please describe how the sparse tilemap storage is done so far?
Why not use a function template to read raw bytes into any struct you cook up, one primitive at a time, instead of compiler annotations?
How will we handle memory when reading files? Would it be wasteful to read into our memory pool, then only use part of it?
Could you explain how to handle platform specific data?
Would it be easy to implement a generic sparse array to solve our tilemap problem (possibly overloading)?
So we have world chunks and -tiles, didn't we also have screens?
Why wouldn't you use a function template in the example mentioned before?
Will you write asset exporters/importers to get the assets into an efficient format or will you rely on the asset creators tools?