Dynamically Responding to Render Settings — Handmade Hero — Episode Guide

0:08Recap and set the stage for the day

1:11Run the game with the determination to enable dynamic responding to render settings

4:08A few words on our good fortune with GPU programming

5:12handmade_opengl.h: Introduce hardware_rendering_switches

8:09handmade_opengl.cpp: Remove the render_entry_blend_render_target case from OpenGLRenderCommands(), and PushBlendRenderTarget()

9:40handmade_platform.h: typedef b32x and u32x with a description of these types

11:37handmade_platform.h: Introduce game_render_setings

14:03handmade_opengl.cpp: Break OpenGLRenderCommands() out into OpenGLPrepareForSettings() which conditionally enables features based on the game_render_settings

30:43handmade_opengl.h: Add necessary data to the open_gl struct and begin to clean up compile errors

33:14handmade_platform.h: Introduce AreEqual()

35:22Rant on the approach of C++ to automating specific instances of programming routines, rather than providing flexible general tools

41:28handmade_opengl.cpp: Fix up compile errors in OpenGLRenderCommands()

44:20handmade_platform.h: Change the RenderCommandStruct() macro to DefaultRenderCommands()

51:11handmade_opengl.cpp: Enable OpenGLBindFramebuffer() to work without the GlobalFramebuffer variables

55:42Run the game and crash in CreateFramebuffer()

56:01handmade_opengl.cpp: Force multisampling to off, run the game, crash in CreateFramebuffer() and investigate why

1:00:04handmade_opengl.cpp: Make OpenGLRenderCommands() pass the new settings to OpenGLPrepareForSettings(), renamed to OpenGLChangeToSettings()

1:00:43Run the game and see a grey screen

1:01:06Re-emphasise that, if on more recent hardware, we would switch to a graphics debugger

1:04:00handmade_opengl.cpp: Hard set values in the OpenGL pipeline in order to diagnose the bug

1:13:48handmade_opengl.cpp: Enable OpenGLRenderCommands() to target our framebuffers

1:14:43Run the game to see that we're getting closer

1:14:54handmade_opengl.cpp: Change how OpenGLRenderCommands() renders to our depth peels

1:18:36Run the game to see that something else is messed up

1:19:03win32_handmade.cpp: Make DefaultRenderCommands() reset the RenderCommands

1:20:24Run the game to see that we're not quite depth peeling

1:20:54handmade_opengl.cpp: Make OpenGLRenderCommands() bind the framebuffer at the end of the depth peels

1:24:53Run the game to see that it looks correct

1:25:10handmade.cpp: Add some render settings to the debug system

1:26:21Run the game, try changing these render settings and determine to enable multisampling and clean-up

1:27:33Check the time

🗹

1:27:33Check the time

🗹

1:27:33Check the time

🗹

1:27:46insobot 87 minutes into the main stream. 33 until Q&A. (based on NOTE)

🗪

1:27:46insobot 87 minutes into the main stream. 33 until Q&A. (based on NOTE)

🗪

1:27:46insobot 87 minutes into the main stream. 33 until Q&A. (based on NOTE)

🗪

1:28:02handmade_opengl.cpp: Introduce FreeFramebuffer() and FreeProgram() for OpenGLChangeToSettings() to call¹^,2

1:36:35Advertise the Web

1:37:16win32_handmade.cpp: Pull in glDeleteProgram(), glDeleteShader() and glDeleteFrameBuffers() from glcorearb.h³

1:39:44Run the game and note that there isn't a good way to test our resource freeing code without GPU debugging tools

1:41:22handmade_opengl.cpp: Add a TODO in OpenGLChangeToSettings() to use a tool to test our freeing code

1:42:31handmade_opengl.cpp: Make OpenGLChangeToSettings() correctly free the depth peel buffer

1:43:02Run the game and try to gauge if we are correctly freeing

1:44:18Consult the documentation on glGet()⁴

1:45:27handmade_opengl.cpp: Add a TODO in OpenGLChangeToSettings() to fix the enabling of multisampling

1:48:06Q&A

🗩

1:48:06Q&A

🗩

1:48:06Q&A

🗩

1:49:04garryjohanson 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:04garryjohanson 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:04garryjohanson 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:37Rant on GPU programming

1:58:49nyeecola 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)?

🗪

1:58:49nyeecola 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)?

🗪

1:58:49nyeecola 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:31jessermeyer Why do you typedef some structs in the render layer, but not all of them?

🗪

2:00:31jessermeyer Why do you typedef some structs in the render layer, but not all of them?

🗪

2:00:31jessermeyer Why do you typedef some structs in the render layer, but not all of them?

🗪

2:01:34nyeecola Casey, do you remove asserts when shipping a game?

🗪

2:01:34nyeecola Casey, do you remove asserts when shipping a game?

🗪

2:01:34nyeecola Casey, do you remove asserts when shipping a game?

🗪

2:01:46desuused In a sense, Vulkan provides you an ISA with strict specification, but the initialization code is quite fat

🗪

2:01:46desuused In a sense, Vulkan provides you an ISA with strict specification, but the initialization code is quite fat

🗪

2:01:46desuused In a sense, Vulkan provides you an ISA with strict specification, but the initialization code is quite fat

🗪

2:04:01jezzi23 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?

🗪

2:04:01jezzi23 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?

🗪

2:04:01jezzi23 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?

🗪

2:08:31We're done

🗩

2:08:31We're done

🗩

2:08:31We're done

🗩

2:10:14Plug Lysa⁵

📖

2:10:14Plug Lysa⁵

📖

2:10:14Plug Lysa⁵

📖

Keyboard Navigation

Global Keys

Menu toggling

In-Menu and Index Controls

Quotes and References Menus and Index

Quotes, References and Credits Menus

Filter Menu

Filter and Link Menus

Credits Menu