[21:04][... we should get rid of the code related to translation unit indices anyways; it introduces too much complexity and opens the door to subtle bugs]
[22:42][We won't remove the translation unit indexing yet]
[24:18][Back to visualization. Let's avoid producing regions that would be invisible in our debug plots]
[26:14][Introducing options to compile away the profiling code]
[29:25][According to the debug display, we should be running at a higher framerate]
[31:32][Validating rdtsc measurements against wall clock time]
[33:30][Recording the wall clock during FRAME_MARKER invocations]
[40:19][Our display does not agree with the framerate because we are not taking into consideration the time it takes to collate debug records]
[41:23][Selectively setting SecondsElapsed instead of ThreadId and core index]
[47:21][HAL: "I'm sorry, Dave, I can't... I can't save the file"][quote 238]
[48:20][Testing today's additions. It's odd that the time we spend inside FrameWait and FrameDisplay went up]
[50:00][Adding DebugCollation counters]
[50:30][DebugCollation takes a lot time]
[51:09][Using the wall clock times to print the time it takes to draw a frame]
[54:00][We're at 250 ms/frame]
[54:34][Without drawing the debug rectangles, it goes down to 91 ms/frame]
[55:45][Disabling debug event recording, we get back to our original performance]
[59:14][Our collation of the debug records is very expensive]
[1:01:05][@quartertron][What's your favourite bug of all time?]
[1:01:48][@serge_rgb][Often when I'm debugging, I have to stop myself from changing stuff at random because of mental laziness, hoping for "an even number of sign errors". Do you ever have that urge? If so, has it diminished as you have become more experienced?[ref
[1:05:19][@CaptainKraft][Doesn't it go against your philosophy of "write the code as you need it" to make a debugger like this before the game needs much debugging?]
[1:07:21][@Arconyx][Is there any way to keep familiar with old code or is working with it frequently the only way?]
[1:10:49][@aameen95][@Mok actually found the bug and @AndreasK actually figured why it is causing what was happening by looking at the assembly. The compiler decided to not inline the call in the constructor and inline it in the destructor so the start marker is wrong and the end marker is right]
[1:12:21][@Stephenlast][It looked like that FRAME_MARKER was going past this TODO: "// TODO(casey): Move this to a global variable so that there can be timers below this one?"]
[1:13:14][win32_handmade.cpp: Move that TODO down and check if GlobalDebugTable exists]
[1:14:07][@quartertron][Do you really care about compilation units or just threads? Hash the thread IDs]
[1:14:46][@SedihGlow][Do you write code for this project off stream, for fun or speed?]
[1:15:24][@slash1221][If I don't have a credit card, is there another way to buy it?]
[1:16:09][@CaptainKraft][You brought up your devlog: do you think that writing a devlog is good for the writer, the readers, or both?]
[1:16:25][@CaptainKraft][It sounds like the debugger is not only a tool to find out what is going wrong, but to detect when things are going to go wrong. Is that a fair assumption? I never thought of a debugger as something that keeps me "situationally aware". That sounds like a great idea]
