[0:09][Welcome. Details about the texture transfer saga.]
[1:26][nvidia didn't respond yet about _how_ to properly transfer textures overlapped.]
[1:54][Overlapping CPU work and GPU work are not the same thing. There are 2 required copies that have to happen in order for the textures to get to the GPU: one off of the disk into memory that GPU can _see_, and then from the memory that the GPU can see into the actual memory resident on the GPU.]
[2:51][Direct GPU Mapping process description]
[4:13][How do we tell the driver to start transferring textures using the asynchronous memory transfer capabilities that the card has]
[5:25][Decision to wait for nvidia's response about what they think the best way to transfer textures would be]
[5:52][Reminder that we don't fence the download on either side and doubt about whether that creates problems]
[6:39][Alternative approach - we could just continue to download textures on a single thread]
[8:38][Decide to fix the debug code]
[9:29][Reminder that on the AMD machine that Casey uses, the texture download problems don't seem to happen]
[9:54][glFlush() seems to force the download to happen on a separate thread]
[10:35][Reminder about the original debug code purposes]
[11:43][Focus on the debug interface]
[13:56][win32_handmade.cpp GlobalPause and GlobalUseSoftwareRendering would be nice to be included in the interface]
[17:05][win32_handmade.cpp - DEBUG_EDIT() as a means to include GlobalPause and GlobalUseSoftwareRendering]
[19:17][Doubts on the usage of handmade_config.h as a means to specify debug variables]
[21:54][win32_handmade.cpp - replacing DEBUG_EDIT() with DEBUG_VALUE() and checking if it works]
[24:35][Unhandled End Data Block]
[25:33][Debug interface is not visible in in-game mode]
[27:40][Check if debug components are drawn by not rendering the world]
[29:11][Add a clear before drawing]
[29:34][Confirmation that the debug interface doesn't show up in-game because of a sorting problem]
[31:07][handmade_render_group.cpp - Add a SortBias to PushBitmap -> Dim.Basis.SortKey]
[32:27][handmade_render_group.cpp - Investigate where and why is CAlign still used. \[just for debug drawing\]]
[35:28][handmade_debug.cpp - add a FLT_MAX sort bias to the PushBitmap call so that we get the debug interface closest to us (on Z)]
[36:35][handmade_debug.cpp - add a drop shadow to the text by duplicating the PushBitmap call, slightly displacing the position and changing the color]
[38:36][Getting back to what we were doing - check if if interactive selection works and confirming that End Data Block UNHANDLED is not a bug introduced by the addition of GlobalPause and GlobalUseSoftwareRendering]
[39:34][Checking the debug printout hierarchy]
[40:03][win32_handmade.cpp - Checking how "Platform" should work in DEBUG_BEGIN_DATA_BLOCK()]
[40:11][handmade_world_mode.cpp - Simulation_Entity | Confirm that printing block names is not yet implemented properly]
[41:41][handmade_debug_interface.h - Minimize complexity by removing DEBUG_IF and DEBUG_VARIABLE]
[42:52][Pulling out calls to DEBUG_VARIABLE and DEBUG_IF into globals ourselves]
[44:15][handmade_config.h - Change #defines to global_variable]
[45:42][handmade_render_group.cpp - Check we don't have code that writes to handmade_config.h]
[46:05][Checking where handmade_config.h is included \[in handmade_platform.h\] and moving the inclusion to handmade.h]
[47:03][Correcting types and initializers for globals in handmade_config.h and changing DEBUG_IF and DEBUG_VARIABLE calls in the rest of the code, removing compile errors one by one until...]
[49:45][...reaching Global_Renderer_ShowLightingSamples, which is moved directly to handmade_render.cpp]
[51:18][win32_handmade.cpp - Moving (and afterwards eliminating) Global_Renderer_UseSoftware from handmade_config.h and creating an enum with the rendering type, which allows to manage the Win32DisplayBufferInWindow cases better.]
[57:13][win32_handmade.cpp - The reason for ordering the enum components is for having the 0 value being the default]
[58:18][Plans for next day: hooking up debug printout for editing and maybe cleanup]
[1:00:30][@dino27_1988][Casey, at what point is it _bad_ to separate everything into multiple files, and when is it _good_?]
[1:07:36][@dino27_1988][Okay, so basically personal preference, compile time, and external impositions. Thank you very much for your answer \:)]
[1:07:46][@rohit_n][Does "texture download" on this stream mean "glTexImage2D"?]
[1:10:23][@dudeinbasement1][Have you ever used #pragma section(...) and grouped memory into sections, and read the map file, or have you always used this style of meta programming?]
[1:10:51][@Cubercaleb][Off-topic: If you wanted to extend the hot-code reloading to work with structure changes wouldn't you have to store meta data about each struct along with information about every allocation, so that you could walk the data, adjust the data, move things around and fix pointers?]
[1:12:14][@guitarm87][Do you specifically have to say inline for functions to be inlined or does the compiler do that automagically if it finds one/several to fit?]
[1:15:07][@Cubercaleb][Would you try to fix the memory in-place or would you copy it to a new memory arena?]
[1:15:47][@dudeinbasement1][Programming style - why do you have the function return on the preceeding line? Is it just so that the function name is in the first column?]
[1:17:02][@StrangeZak][Yeah I don't know what the deal was, when I asked about inlining last night it blew up everywhere.]
[1:18:53][@Garryjohanson][I was messing around with loop unrolling by hand and got massive speedups, any idea why would that be?]
