[2:52][Run the game to see that we are still running and can do looped live code editing]
[4:32][handmade_memory.h: Determine to provoke some deleterious effects]
[7:39][handmade_platform.h: Replace TransientStorage with a TransientState]
[10:13][handmade.cpp: Enable DEBUGGetMainGeneration() to initialise a TransientState]
[10:59][handmade_memory.h: Introduce BootstrapPushSize_() and BootstrapPushStruct() for all of the transient arena initialisation sites to use]
[20:21][Run the game and crash in EndTemporaryMemory()]
[22:32][Blackboard: Temporary Memory for Dynamic Arenas]
[25:11][handmade_memory.h: Introduce memory_block_footer struct and GetFooter() and make PushSize_() stick that footer onto the end of blocks]
[32:57][handmade_memory.h: Add Base to the temporary_memory struct to enable EndTemporaryMemory() to loop back over the blocks, and introduce FreeLastBlock()]
[36:18][Run the game to see that we're totally running as we were before]
[37:35][Consult perfmon to verify that we're not leaking memory]
[40:24][Switch over the entire codebase to run through dynamic allocation]
[51:21][Run the game successfully]
[54:12][handmade_memory.h: Enable Clear() to handle dynamically allocated blocks]
[58:45][handmade_world.h: Make all modes use the arena they're given rather than sub-allocating out of it]
[1:00:28][4coder feature: Stream mode]
[1:01:30][Run the game to see that our poor cutscene is gone]
[1:03:19][Reflect on our first part of the memory upgrade]
[1:05:58][@zilarrezko][Have you ever tried reserving a very large amount of memory, and then committing memory as needed, so the arena can grow without the base pointer changing?]
[1:07:08][@dudeinbasement1][Thoughts on placing the "footer", at the beginning of the memory area, so bad co-workers don't overwrite it (because it is at the end currently)]
[1:10:09][@m1el][You spend so much time on memory management. If programming games for windows / Linux would it be better to use malloc and then create custom allocation for hot parts?]
[1:11:03][@billdstrong][Casey, how strict are you on minimizing the amount of memory is used by the game?]
[1:12:21][@sssmcgrath][Your article didn't even touch on the horrors of ETW. I had to manually fill out several GUIDs that msft decided not to include in their headers for some reason by pulling them off three different, very obscure MSDN pages that were auto generated for C# markup. I had to reverse engineer several void * pointers by using partial data on MSDN and inspecting the memory and guessing sizes, offsets and types. There was a variable listed on MSDN as "object UserSID"... Yes, the type was "object", and guess what! It's not a SID, it's 2 unknown / undocumented pointers then a SID! What are those pointers? Who knows. They also intermixed ASCII and UTF16 strings, one after the other with no documentation... Yay!]
[1:13:28][@Miblo][When we're dynamically allocating, we could potentially end up allocating every last drop of memory available to us, right? Are there situations in which we'd want to make sure we allocate "some amount" less than the max and, if so, how would we best do that?]
[1:15:56][@longboolean][So currently you can only free memory in the last memory blocks? If you wanted to free stuff near the beginning of the arena and keep the stuff at the end, you would need to do things differently?]
[1:17:57][@zilarrezko][If you are planning on large worlds, are you planning then on compressing and decompressing from the mandala on the fly?]
[1:19:12][@m1el][Will Handmade Hero use texture compression in OpenGL?]
[1:20:19][@pseudonym73][The term "arena" refers to a region of memory from which multiple objects are allocated and which can be deallocated all at once. Some arenas support object freeing, some do not]
