[14:03][handmade_opengl.cpp: Break OpenGLRenderCommands() out into OpenGLPrepareForSettings() which conditionally enables features based on the game_render_settings]
[30:43][handmade_opengl.h: Add necessary data to the open_gl struct and begin to clean up compile errors]
[1:49:04][@garryjohanson][So one of my left-field questions: Do you think there is a case to be made for a GL implementation to be written in OpenCL, OpenCL having the capacity to natively run on the CPU and is compatible with visual studio, so you could CPU debug your OpenGL code in visual studio. Would that capacity solve the OpenGL debug problem, or is the problem typically somewhere else, like actual problems with opaque GPU functionality, if that all made sense?]
[1:49:37][Rant on GPU programming]
[1:58:49][@nyeecola][Casey, I've started to program more like the way you teach and I'm liking it so far, but there's one thing that makes me feel strange: When using structs to set up some data that will be used by a function later, how can I make sure that I won't forget to set some member of that struct before calling that function? Is there a way to make sure I always initialize every member of the structure to a value (other than zero)?]
[2:00:31][@jessermeyer][Why do you typedef some structs in the render layer, but not all of them?]
[2:01:34][@nyeecola][Casey, do you remove asserts when shipping a game?]
[2:01:46][@desuused][In a sense, Vulkan provides you an ISA with strict specification, but the initialization code is quite fat]
[2:04:01][@jezzi23][I didn't quite understand how OpenGL and multithreading can cooperate. I believe you once said in an episode that an OpenGL context is specific to the thread that created it. So if I create the context on a main thread, can I not have other worker threads call into OpenGL without somehow setting the context for each thread?]
