Hi!
first I want to point out that there's an earlier use of
GameMemory/GameState at the beginning of week 5. Thanks to the
forum guides (bless the authors!), I can point you to the
exact moment where these memory abstractions are put to good use.
Since you've already studied everything up to day 14, I believe you don't need to watch week 4 to understand the use of the platform-independent memory structs (although, of course, you'll need to watch them eventually in order to understand some stuff later on). But anyways, I'll just give you a barebones explanation that you should in no way mistake for Casey's in-depth explanation.
The platform layer defines a
GameMemory struct and points it to a block of memory that will be handed to the
game_update_and_render function each time it is called. The platform layer only knows the size of that chunk of memory, but remains completely ignorant of how the
GUAR function uses it.
The
GUAR function takes that block of memory and casts it as a
GameState struct and uses that struct to keep all the game-related information it needs to keep between calls.
So, for instance, if you wanted your character to start with 5 health points and to lose one point per frame, your GameState and GUAR would look something like this (I'm avoiding Casey's GUAR macros to make the signature of the function more accessible to beginners):
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16 | struct GameState{
int health_points;
};
void game_update_and_render(GameMemory *game_memory, GameInput *game_input){
GameState *game_state = (GameState) game_memory;
if(!game_memory->is_initialized){
game_state->health_points = 5;
}
--game_state->health_points;
if(game_state->health_points <= 0){
// YOU'RE DEAD !!!
}
}
|
The management of the memory in the platform layer might seem strange from the low vantage point of day 14 and the importance of allocating that block of memory at a known address (2TB, IIRC) may not be apparent yet (I seem to remember Casey justifying it by mumbling something about being able to see if a variable belonged to the GameState by looking at its address in the debugger to see if it was higher that 2TB; I guess he wanted to avoid spoiling the big surprise). Week 5, which is a thing of beauty, discusses how this memory management scheme makes possible hot code reloading and loop code editing, among other things. I hope you enjoy it as much as I did!!
The
push_struct is related to managing dynamic chunks of memory. I would advise against jumping straight into it if it means skipping week 6. You don't want to skip week 6. Oh, I love week 6! If only I could forget week 6 to be able to experience it again for the first time!