Supporting Temporary Memory in Dynamic Arenas
?
?

Keyboard Navigation

Global Keys

[, < / ], > Jump to previous / next episode
W, K, P / S, J, N Jump to previous / next marker
t / T Toggle theatre / SUPERtheatre mode
V Revert filter to original state Y Select link (requires manual Ctrl-c)

Menu toggling

q Quotes r References f Filter y Link c Credits

In-Menu Movement

a
w
s
d
h j k l


Quotes and References Menus

Enter Jump to timecode

Quotes, References and Credits Menus

o Open URL (in new tab)

Filter Menu

x, Space Toggle category and focus next
X, ShiftSpace Toggle category and focus previous
v Invert topics / media as per focus

Filter and Link Menus

z Toggle filter / linking mode

Credits Menu

Enter Open URL (in new tab)
0:02Recap and set the stage for the day
0:02Recap and set the stage for the day
0:02Recap and set the stage for the day
2:52Run the game to see that we are still running and can do looped live code editing
2:52Run the game to see that we are still running and can do looped live code editing
2:52Run the game to see that we are still running and can do looped live code editing
4:32handmade_memory.h: Determine to provoke some deleterious effects
4:32handmade_memory.h: Determine to provoke some deleterious effects
4:32handmade_memory.h: Determine to provoke some deleterious effects
7:39handmade_platform.h: Replace TransientStorage with a TransientState
7:39handmade_platform.h: Replace TransientStorage with a TransientState
7:39handmade_platform.h: Replace TransientStorage with a TransientState
10:13handmade.cpp: Enable DEBUGGetMainGeneration() to initialise a TransientState
10:13handmade.cpp: Enable DEBUGGetMainGeneration() to initialise a TransientState
10:13handmade.cpp: Enable DEBUGGetMainGeneration() to initialise a TransientState
10:59handmade_memory.h: Introduce BootstrapPushSize_() and BootstrapPushStruct() for all of the transient arena initialisation sites to use
10:59handmade_memory.h: Introduce BootstrapPushSize_() and BootstrapPushStruct() for all of the transient arena initialisation sites to use
10:59handmade_memory.h: Introduce BootstrapPushSize_() and BootstrapPushStruct() for all of the transient arena initialisation sites to use
20:21Run the game and crash in EndTemporaryMemory()
20:21Run the game and crash in EndTemporaryMemory()
20:21Run the game and crash in EndTemporaryMemory()
22:32Blackboard: Temporary Memory for Dynamic Arenas
22:32Blackboard: Temporary Memory for Dynamic Arenas
22:32Blackboard: Temporary Memory for Dynamic Arenas
25:11handmade_memory.h: Introduce memory_block_footer struct and GetFooter() and make PushSize_() stick that footer onto the end of blocks
25:11handmade_memory.h: Introduce memory_block_footer struct and GetFooter() and make PushSize_() stick that footer onto the end of blocks
25:11handmade_memory.h: Introduce memory_block_footer struct and GetFooter() and make PushSize_() stick that footer onto the end of blocks
32:57handmade_memory.h: Add Base to the temporary_memory struct to enable EndTemporaryMemory() to loop back over the blocks, and introduce FreeLastBlock()
32:57handmade_memory.h: Add Base to the temporary_memory struct to enable EndTemporaryMemory() to loop back over the blocks, and introduce FreeLastBlock()
32:57handmade_memory.h: Add Base to the temporary_memory struct to enable EndTemporaryMemory() to loop back over the blocks, and introduce FreeLastBlock()
36:18Run the game to see that we're totally running as we were before
36:18Run the game to see that we're totally running as we were before
36:18Run the game to see that we're totally running as we were before
37:35Consult perfmon to verify that we're not leaking memory
37:35Consult perfmon to verify that we're not leaking memory
37:35Consult perfmon to verify that we're not leaking memory
40:24Switch over the entire codebase to run through dynamic allocation
40:24Switch over the entire codebase to run through dynamic allocation
40:24Switch over the entire codebase to run through dynamic allocation
51:21Run the game successfully
51:21Run the game successfully
51:21Run the game successfully
54:12handmade_memory.h: Enable Clear() to handle dynamically allocated blocks
54:12handmade_memory.h: Enable Clear() to handle dynamically allocated blocks
54:12handmade_memory.h: Enable Clear() to handle dynamically allocated blocks
58:45handmade_world.h: Make all modes use the arena they're given rather than sub-allocating out of it
58:45handmade_world.h: Make all modes use the arena they're given rather than sub-allocating out of it
58:45handmade_world.h: Make all modes use the arena they're given rather than sub-allocating out of it
1:00:284coder feature: Stream mode
1:00:284coder feature: Stream mode
1:00:284coder feature: Stream mode
1:01:30Run the game to see that our poor cutscene is gone
1:01:30Run the game to see that our poor cutscene is gone
1:01:30Run the game to see that our poor cutscene is gone
1:03:19Reflect on our first part of the memory upgrade
1:03:19Reflect on our first part of the memory upgrade
1:03:19Reflect on our first part of the memory upgrade
1:04:07todo.txt: Update the TODO list
1:04:07todo.txt: Update the TODO list
1:04:07todo.txt: Update the TODO list
1:04:48Q&A
🗩
1:04:48Q&A
🗩
1:04:48Q&A
🗩
1:05:58zilarrezko 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:05:58zilarrezko 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:05:58zilarrezko 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:08dudeinbasement1 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:07:08dudeinbasement1 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:07:08dudeinbasement1 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:09m1el 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:10:09m1el 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:10:09m1el 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:03billdstrong Casey, how strict are you on minimizing the amount of memory is used by the game?
🗪
1:11:03billdstrong Casey, how strict are you on minimizing the amount of memory is used by the game?
🗪
1:11:03billdstrong Casey, how strict are you on minimizing the amount of memory is used by the game?
🗪
1:12:21sssmcgrath 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:12:21sssmcgrath 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:12:21sssmcgrath 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:28Miblo 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:13:28Miblo 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:13:28Miblo 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:56longboolean 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:15:56longboolean 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:15:56longboolean 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:57zilarrezko If you are planning on large worlds, are you planning then on compressing and decompressing from the mandala on the fly?
🗪
1:17:57zilarrezko If you are planning on large worlds, are you planning then on compressing and decompressing from the mandala on the fly?
🗪
1:17:57zilarrezko If you are planning on large worlds, are you planning then on compressing and decompressing from the mandala on the fly?
🗪
1:19:12m1el Will Handmade Hero use texture compression in OpenGL?
🗪
1:19:12m1el Will Handmade Hero use texture compression in OpenGL?
🗪
1:19:12m1el Will Handmade Hero use texture compression in OpenGL?
🗪
1:20:19pseudonym73 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
🗪
1:20:19pseudonym73 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
🗪
1:20:19pseudonym73 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
🗪
1:21:03Close up
🗩
1:21:03Close up
🗩
1:21:03Close up
🗩