71 lines
6.6 KiB
Plaintext
71 lines
6.6 KiB
Plaintext
[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]
|
|
[0:05][Intro]
|
|
[1:05][Recap of the debug system]
|
|
[2:22][Ideas for today's work]
|
|
[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:05:42][Game running with the problem resolved]
|
|
[1:06:41][Q&A][:speech]
|
|
[1:07:06][@plain_flavored][What is the debug collator?]
|
|
[1:08:33][@longboolean][https://hero.handmadedev.org/forum/code-discussion/902-day-211-gcc-clang-build-report]
|
|
[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:18:31][@TheSizik][You missed Region->ColorIndex = (u16)OpeningEvent->BlockName;]
|
|
[1:19:09][@insofaras][How many lines are we at now?]
|
|
[1:20:01][@ChronalDragon][Sure. What's a quick way to _produce_ temporary sound effects to, for example, figure out where/when they should be played?]
|
|
[1:21:16][@TheSizik][Not stripping unused code is how GTA Hot Coffee happened]
|
|
[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?]
|
|
[1:26:52][Wind down][:speech]
|
|
[/video]
|