Im curious why the game needs to have the memory passed in every update. Im working ahead abit and am trying to figure out how to keep the game stateless for loading the game dll dynamically while still keeping tabs on the layout of the memory chuck (what is where). I mean, if the game has pointers to the game objects, won't those be reset everytime the game dll is recompiled?

The DLL is just the code, it doesn't contain data. So as long as the data in the memory block is laid out the same way that the game wants it to be, the code can be reloaded while keeping the memory block intact, allowing the hot-load to happen. So the platform layer "owns" the memory block, and passes it to the game each frame, so that in between frames, the platform layer can unload the game code and load new game while still passing the same memory block in the next time 'round.

- Casey

So, let's say for example, in the memory the game always stores the player's data (world position, etc.) at X offset in the block of memory, the world tilemap at Y offset? Or am I missing something?

Im asking now because I'm following the stream abit differently, where I'm building a different game and doing it as if I know nothing of the game's arcitecture (which I don't) but I'm also including the platfor layer. This way I feel like its not just a copy and paste from the stream, but doing so I skip parts until I need them in the platform layer (like sound and input). Im thinking that if I build a part of my game now, how to use the memory will fall into place.

The idea is very much the same as a file format. Offset 0 in the memory block is the "header" (which is our game_state struct), and it contains pointers to all the other things.

So the game just always looks at location 0, looks at the game_state structure there, and that tells it where to find everything else.

- Casey