[video output=day220 member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Displaying Data Blocks in the Hierarchy" vod_platform=youtube id=k1h-0MEtcGg annotator=insofaras]
[4:11][Remembering how DEBUG_VALUE and DEBUG_BEGIN_DATA_BLOCK worked, considering unifying the unique IDs]
[5:04][Thoughts about using the string in BEGIN_DATA_BLOCK for debug UI layout]
[5:50][More thoughts on using EntityDebugID to differentiate entities without touching gameplay code]
[6:33][Recalling how debug data blocks work, and how they differ from the debug switches handled by the MarkDebugValue event type]
[8:58][Discussing the changes to debug data blocks that we want to implement, and how they'd help when debugging]
[10:56][Thinking about changing the allocation strategy of debug data blocks to match that of debug elements]
[12:40][An idea for unifying the debug data block + debug element code]
[14:09][Changes to the handling of the OpenDataBlock debug event type, to accommodate the new allocation idea]
[14:57][A quick look at how StoreEvent was working with debug elements]
[15:32][Clarification of how the debug system is currently working, and the planned changes]
[17:06][Changes to the handling of the CloseDataBlock debug event type]
[17:31][Updating the AllocateOpenDebugBlock function and open_debug_block struct to store a debug_element]
[18:47][Allowing debug data blocks to override which debug_element StoreEvent stores into]
[19:24][Actually using the right variable, running the game]
[19:35][Removing erroneous quotes from the debug display by no longer passing strings to the DEBUG_BEGIN_DATA_BLOCK macro]
[19:59][Running the game again, noticing a problem with a missing group, figuring out why]
[21:22][Start trying to fix the debug data blocks not displaying as a group]
[22:32][Adding a flag to GetGroupForHierarchicalName to optionally create an additional group]
[24:01][Backtracking on the flag idea, deciding to directly turn the element into a group instead]
[25:07][Verifying how the debug blocks work in the debugger]
[28:58][Explaining how the workings shown in the debugger differ from what was expected]
[29:35][Debugging GetGroupForHierarchicalName]
[32:51][Gaining an understanding of the behaviour, explanation about how only debug_variable_groups have names]
[33:55][Discussing potential solutions for getting the name passed in DEBUG_BEGIN_DATA_BLOCK to show up]
[34:31][Choosing to store the OpenDataBlock event as well as the events for its contents, since it will contain the name]
[35:19][Looking back at how the debug events are drawn, and adding a case for open debug data blocks (bitmap_id initially by mistake)]
[36:12][Questioning why the erroneous change seemingly made a difference in output, figuring out why]
[36:59][Back to thinking about why open data block names aren't showing up]
[37:31][Adding a temporary change to the CloseDataBlock handling, which causes the data block endings to show up]
[38:03][Adding some debug data block specific handling to DEBUGDrawMainMenu so the values inside the data block can be drawn]
[40:30][Creating the DEBUGDrawElement and DEBUGDrawEvent functions to help in the drawing of debug information]
[42:18][Talking about the complications of debug_events and debug_elements and how they both relate to the printing of debug info]
[43:00][Changing DEBUGDrawElement to use debug_stored_event instead of debug_event so that it can walk through the next pointers]
[44:02][Moving most code from DEBUGDrawElement into DEBUGDrawEvent]
[44:53][Changing DEBUGDrawElement to extract the oldest event from the element, and determine if it needs to be forwarded to DEBUGDrawEvent or perform other work]
[46:58][Fixing some compile errors by passing necessary variables to the new functions]
[47:24][Adding the debug_tree to the layout struct and setting it in DEBUGDrawMainMenu]
[48:56][Thinking about also adding the debug_variable_link to the layout struct, but choosing to re-factor the surrounding code to use debug_id instead]
[52:26][Updating the interaction code, changing the function VarLinkInteraction to EventInteraction and passing the debug_id and debug_event instead of the debug_tree and debug_variable_link]
[54:11][Removing the debug_tree from the layout struct since the interaction changes make it unnecessary]
[54:30][Finishing off fixing the remaining compile errors]
[57:04][Removing the now unused GetEventFromLink function]
[57:57][Running the game]
[58:09][Starting to add code to the DebugDrawElement function to loop through debug data blocks, and call DebugDrawEvent for each value held inside]
[58:50][Changing DebugIDFromLink to DebugIDFromStoredEvent]
[59:35][Adding a debug_tree argument to DEBUGDrawElement so that it can be passed to DebugIDFromStoredEvent, and finishing off its data block handling code]
[1:01:56][Game running with the entity related data block now being added to the Simulation hierarchy]
[1:02:10][Noticing problems related to the debug_id changing every frame for data block values]
[1:03:55][Solving the problem by using event GUIDs to get stable debug_ids for data block values instead of the associated debug_stored_event address which wasn't stable]
[1:14:10][@ChronalDragon][How do game devs you work with typically handle temporary / non-shipping sound effects?]
[1:14:54][@plain_flavored][Will there be a pass to strip unused code from HMH?]
[1:15:19][@elxenoaizd][What do you think about working in constraints and having limited resources? I think it makes programmers write less lousy code and force them to actually care and know what they're doing...]
[1:15:38][@nxsy][Can we get rid of the build error (something about introspection of structs) that doesn't seem to affect anything?]
[1:23:49][@elxenoaizd][If a programming job wasn't available to you, what type of work would you be interested in doing other than programming for a living?]
[1:24:10][@actbinary][What do you think of dlc then? ;)]
[1:26:41][@BrutalABK][Do you play MMOs, if so, how do you feel about the way they do their leveling?]
