cinera_handmade.network/cmuratori/hero/code/code186.hmml

[video member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Starting to Debug Event Recording" vod_platform=youtube id=BbfFZLUre3s annotator=debiatan annotator=Miblo]
[0:08][Recap and plan for today]
[1:19][We'll be debugging our event record visualization]
[2:25][Quick review of the code relevant to the task]
[3:29][Are we building the debug frames properly?]
[4:02][Checking that the frame count is correct]
[5:32][There are too few regions inside a frame]
[6:18][Stepping through the code looking for the cause of that error]
[14:15][There seems to be a problem with the BEGIN_ and END_BLOCK pairing]
[16:55][Stopping when we hit the END_BLOCK event of the GameUpdate counter]
[17:46][Implementing StringsAreEqual]
[21:52][The opening and closing GameUpdate events don't match at all]
[23:24][The hierarchy of nested events seems too deep]
[25:33][Is END_BLOCK_ not working properly?]
[27:08][Examining DrawRectangle]
[29:47][DrawRectangle is called from multiple threads]
[31:37][Could the code that deals with multiple threads be wrong?]
[32:03][Stepping through the code at DrawRectangle events]
[33:20][Drawing rectangles inside the debug code could be the cause of the bug]
[35:05][What does the global debug table look like when we're timing DrawRectangle?]
[40:45][Some more stepping through the code]
[42:40][Examining event writting inside TIMED_FUNCTION]
[43:18][There are too many end blocks for the same ThreadId]
[44:00][Is GetThreadId wrong?]
[45:29][Testing GetThreadId at thread creation time. It checks out]
[49:37][Substituting TIMED_FUNCTION with paired BEGIN_ and END_BLOCKs to avoid constructor/destructor pairs]
[53:06][We're out of hypotheses. Let's freeze some threads to run them in order]
[56:15][The problem seems to disappear when we run the threads in order. But why?]
[59:10][Verifying that GetThreadId returns a u16]
[1:00:00][Perplexing bug][quote 236]
[1:01:30][Checking that EventArrayIndex is aligned to 8-byte boundaries]
[1:06:15][Outsourcing the problem to the stream]
[1:06:53][We could debug the problem in isolation, on a simpler version of the code]
[1:07:37][Q&A][:speech]
[1:08:04][@TheSizik][Try running without timing DrawRectangle]
[1:10:44][@Bobo_the_bearded][The MSDN documentation for __readgsqword states "These intrinsics are only available in kernel mode, and the routines are only available as intrinsics". If this is the case, how were you able to use __readgsqword to read out the thread ID? (I'm not really sure what the difference between kernel mode and user mode is)]
[1:12:10][@qwoodmansee][You said that it seems to work normally for a little while, then stops working when it's under stress. Maybe let the threads run wild for a little while, then freeze them? Or is this not possible with the debugger?]
[1:16:08][@Culver_Fly][Is it possible that the ArrayIndex part somehow got swapped out during begin / end records?]
[1:16:24][@Connor_Rentz][Did you create your colors to be easy on the eyes? If not, how did they come to be?]
[1:16:41][@dafreaki][Didn't you remove the EndBlock call?]
[1:20:03][handmade_render_group.cpp: Make DoTiledRenderWork a TIMED_FUNCTION]
[1:21:10][handmade_render_group.cpp: Make IGNORED_TIMED_FUNCTION by a TIMED_FUNCTION again]
[1:22:50][@elxenoaizd][If the debug code is slower than the actual runtime of the game, how can we rely on the debug systems to give us accurate timing of how long things are taking in the game since they naturally take more time in debug mode?]
[1:25:19][handmade_debug.cpp: Render debug information for fewer frames]
[1:29:02][@SerialQwiller][If I remember correctly from the other day, you discard events if buffers are full. Are you sure all buffers are big enough?]
[1:29:50][build.bat: Switch to -O2]
[1:31:09][@TheSizik][Could it be threads running across a frame boundary?]
[1:33:01][Leave it in a state where it is broken][:speech][quote 237]
[/video]