is presently its sole maintainer,
You can support him:
Recap of the debug system
Ideas for today's work
Remembering how DEBUG_VALUE and DEBUG_BEGIN_DATA_BLOCK worked, considering unifying the unique IDs
Thoughts about using the string in BEGIN_DATA_BLOCK for debug UI layout
More thoughts on using EntityDebugID to differentiate entities without touching gameplay code
Recalling how debug data blocks work, and how they differ from the debug switches handled by the MarkDebugValue event type
Discussing the changes to debug data blocks that we want to implement, and how they'd help when debugging
Thinking about changing the allocation strategy of debug data blocks to match that of debug elements
An idea for unifying the debug data block + debug element code
Changes to the handling of the OpenDataBlock debug event type, to accommodate the new allocation idea
A quick look at how StoreEvent was working with debug elements
Clarification of how the debug system is currently working, and the planned changes
Changes to the handling of the CloseDataBlock debug event type
Updating the AllocateOpenDebugBlock function and open_debug_block struct to store a debug_element
Allowing debug data blocks to override which debug_element StoreEvent stores into
Actually using the right variable, running the game
Removing erroneous quotes from the debug display by no longer passing strings to the DEBUG_BEGIN_DATA_BLOCK macro
Running the game again, noticing a problem with a missing group, figuring out why
Start trying to fix the debug data blocks not displaying as a group
Adding a flag to GetGroupForHierarchicalName to optionally create an additional group
Backtracking on the flag idea, deciding to directly turn the element into a group instead
Verifying how the debug blocks work in the debugger
Explaining how the workings shown in the debugger differ from what was expected
Gaining an understanding of the behaviour, explanation about how only debug_variable_groups have names
Discussing potential solutions for getting the name passed in DEBUG_BEGIN_DATA_BLOCK to show up
Choosing to store the OpenDataBlock event as well as the events for its contents, since it will contain the name
Looking back at how the debug events are drawn, and adding a case for open debug data blocks (bitmap_id initially by mistake)
Questioning why the erroneous change seemingly made a difference in output, figuring out why
Back to thinking about why open data block names aren't showing up
Adding a temporary change to the CloseDataBlock handling, which causes the data block endings to show up
Adding some debug data block specific handling to DEBUGDrawMainMenu so the values inside the data block can be drawn
Creating the DEBUGDrawElement and DEBUGDrawEvent functions to help in the drawing of debug information
Talking about the complications of debug_events and debug_elements and how they both relate to the printing of debug info
Changing DEBUGDrawElement to use debug_stored_event instead of debug_event so that it can walk through the next pointers
Moving most code from DEBUGDrawElement into DEBUGDrawEvent
Changing DEBUGDrawElement to extract the oldest event from the element, and determine if it needs to be forwarded to DEBUGDrawEvent or perform other work
Fixing some compile errors by passing necessary variables to the new functions
Adding the debug_tree to the layout struct and setting it in DEBUGDrawMainMenu
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
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
Removing the debug_tree from the layout struct since the interaction changes make it unnecessary
Finishing off fixing the remaining compile errors
Removing the now unused GetEventFromLink function
Running the game
Starting to add code to the DebugDrawElement function to loop through debug data blocks, and call DebugDrawEvent for each value held inside
Changing DebugIDFromLink to DebugIDFromStoredEvent
Adding a debug_tree argument to DEBUGDrawElement so that it can be passed to DebugIDFromStoredEvent, and finishing off its data block handling code
Game running with the entity related data block now being added to the Simulation hierarchy
Noticing problems related to the debug_id changing every frame for data block values
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
Game running with the problem resolved
plain_flavored Q: What is the debug collator?
longboolean Q: https://hero.handmadedev.org/forum/code-discussion/902-day-211-gcc-clang-build-report
ChronalDragon Q: How do game devs you work with typically handle temporary / non-shipping sound effects?
plain_flavored Q: Will there be a pass to strip unused code from HMH?
elxenoaizd Q: 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...
nxsy Q: Can we get rid of the build error (something about introspection of structs) that doesn't seem to affect anything?
TheSizik Q: You missed Region->ColorIndex = (u16)OpeningEvent->BlockName;
insofaras Q: How many lines are we at now?
ChronalDragon Q: Sure. What's a quick way to _produce_ temporary sound effects to, for example, figure out where/when they should be played?
TheSizik Q: Not stripping unused code is how GTA Hot Coffee happened :P
elxenoaizd Q: 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?
actbinary Q: What do you think of dlc then? ;)
BrutalABK Q: Do you play MMOs, if so, how do you feel about the way they do their leveling?