Index hero/code549
This commit is contained in:
parent
84b1f38447
commit
483091684e
|
@ -0,0 +1,54 @@
|
|||
[video member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Removing Old Lighting Lookups" vod_platform=youtube id=e1W8dHWeLy8 annotator=Miblo]
|
||||
[0:01][Recap our ongoing switch to light probes and set the stage for the day][:lighting :speech]
|
||||
[8:17][Demo the currently unlit game][:lighting :run]
|
||||
[9:06][Disable ComputeLightPropagation()][:lighting]
|
||||
[10:05][Consult the profiler, to see that RenderGroundCover is our expensive routine][:performance :run]
|
||||
[11:34][Gauge the expense of DrawGroundCover(), and note the potential for :caching it][:performance :rendering :research]
|
||||
[14:43][Note that we are not quite hitting 60FPS][:performance :run]
|
||||
[15:27][Add a VSync toggle][:ui]
|
||||
[16:37][Find that VSync toggling seems not to affect the frame rate][:performance :run]
|
||||
[17:23][Consult our VSync toggling code][:research]
|
||||
[17:56][Break in to PlatformOpenGLSetVSync(), toggle VSync, but conclude that we always get VSync][:performance :run]
|
||||
[21:02][Consult the documentation on OpenGL's Swap Interval[ref
|
||||
site="Khronos Wiki"
|
||||
page="Swap Interval"
|
||||
url=https://www.khronos.org/opengl/wiki/Swap_Interval]][:research]
|
||||
[22:09][Create issue "Are we actually able to turn off VSync?"[ref
|
||||
site=GitHub
|
||||
page="Are we actually able to turn off VSync?"
|
||||
url=https://github.com/HandmadeHero/cpp/issues/108]][:admin]
|
||||
[23:13][Determine to feed our new light probes through to the renderer][:lighting :speech]
|
||||
[26:21][Remove lighting_point_state from the entity struct, and TextureIndex from textured_vertex][:lighting]
|
||||
[39:16][Remove LightIndex and FragLightIndex from CompileZBiasProgram()][:hardware :lighting]
|
||||
[41:02][See that our textures are absent][:rendering :run]
|
||||
[41:50][Reinstate TextureIndex in textured_vertex][:lighting]
|
||||
[45:22][See that our textures are still absent][:rendering :run]
|
||||
[45:46][Remove VertLightIndex from CompileZBiasProgram()][:hardware]
|
||||
[46:24][See that our textures are still absent][:rendering :run]
|
||||
[46:26][Remove VertLightIndex from opengl_program_common][:hardware :lighting]
|
||||
[47:25][See that our textures are still absent][:rendering :run]
|
||||
[47:42][Scan through the :hardware renderer for texture index][:rendering :research]
|
||||
[49:00][Let WriteQuad() and PushQuad() set the TextureIndex again][:rendering]
|
||||
[52:00][See that our textures are back][:rendering :run]
|
||||
[54:04][Plan to push light probes through to the renderer][:lighting :rendering :speech]
|
||||
[58:08][Remove LightIndex and Transparency from lighting_box][:lighting]
|
||||
[1:07:05][Find that the game runs fine][:lighting :run]
|
||||
[1:08:07][Enable PushCube() to push a lighting_box onto the :lighting system, augmenting that structure with a TextureIndex]
|
||||
[1:14:39][Consider building into the ray tracing process the idea that every ray has a set destination to write to][:lighting :speech]
|
||||
[1:16:46][Consider blending the colours of each face of the lighting_box into one colour][:lighting :speech]
|
||||
[1:19:41][Toggle off all the surface colour computation in RayCast()][:lighting]
|
||||
[1:23:57][Consider the necessity of breaking out early of the surface colour computation in RayCast()][:lighting :research]
|
||||
[1:30:43][Toggle off the early-out code in RayCast()][:lighting]
|
||||
[1:33:51][Set up to accelerate RayCast(), replacing BoxIndex and BoxSurfaceIndex with Normal in raycast_result][:lighting]
|
||||
[1:54:18][Q&A][:speech]
|
||||
[1:55:10][@mikka3][Q: Do you have any tips for how someone would go about moving an existing codebase from OOP, assuming you're in control of it? By the way, thank you very much for the series. I'm learning so much, that $15 doesn't even begin to compare with the value you're providing. The fact the series is free is even more awesome][:language]
|
||||
[1:58:59][@s0llygaming][Q: I'm only on episode 81 so excuse the noobiness: I've created different "modules" in my code that store different data for my entities (physics, render, AI, etc). Would it be silly to create an "anonymous" module type that union's these different modules into one generic struct? Meaning I can put them all into one array to pass around etc.][:"data structure"]
|
||||
[2:02:21][@zrizi][Q: It seems that tracing rays to collect light is a heavy operation. If ray tracing supported GPU :hardware was common these days, would it be fair to say that you would prefer to move the :lighting computation to the GPU entirely?]
|
||||
[2:03:12][@zrizi][Q: (Off-topic) Talking to graphics folks, it seems that shader permutation management is a real pain point. On the other hand, you have titles like Doom that use a significant small number of permutations and pipeline states. In a more complex 3D title, what’s your take on GPU complexity management? How will you design a solution that scales?][:hardware]
|
||||
[2:06:37][@zrizi][Q: (Off-topic) Real production related question. In [~hero Handmade Hero], we have a general idea of how the game should look and feel like (mechanics, art direction, etc.). We’re tackling engine problems because they are interesting, and I’m very grateful for you doing it. How will the process of tackling things and “exploring” the engine design look like in a real production environment based on your experience? Say, maybe, based on your experience working on The Witness with [@naysayer88 Jon Blow]?]
|
||||
[2:08:20][@bulmanator][Q: Tips on reading academic papers about graphics and stuff? I always seem to get lost in their technical jargon and don’t really get anything out of them. A good example is your video about GJK[ref
|
||||
site=YouTube
|
||||
page="Implementing GJK"
|
||||
url=https://www.youtube.com/watch?v=Qupqu1xe7Io] vs the actual paper]
|
||||
[2:09:17][Wrap it up][:speech]
|
||||
[/video]
|
Loading…
Reference in New Issue