From 36e13c60e8042d0b7c81418deeade55b991f90ed Mon Sep 17 00:00:00 2001 From: Matt Mascarenhas Date: Thu, 5 Dec 2019 21:46:13 +0000 Subject: [PATCH] Index hero/code571 hero/code498 and hero/code569: Fix typos --- cmuratori/hero/code/code498.hmml | 2 +- cmuratori/hero/code/code569.hmml | 6 +-- cmuratori/hero/code/code571.hmml | 65 ++++++++++++++++++++++++++++++++ 3 files changed, 69 insertions(+), 4 deletions(-) create mode 100644 cmuratori/hero/code/code571.hmml diff --git a/cmuratori/hero/code/code498.hmml b/cmuratori/hero/code/code498.hmml index b9106b4..33de246 100644 --- a/cmuratori/hero/code/code498.hmml +++ b/cmuratori/hero/code/code498.hmml @@ -45,7 +45,7 @@ url=https://handmade.network/blogs/p/1138-%5Btutorial%5D_handmade_network_irc]] [2:20:30][@b3zman41][Q: So MSVC just doesn't do all the inlining stuff by default? Sorry, I'm more of a web dev and don't get this low-level stuff] [2:21:03][Walk through ComputeLightPropagation() and its disassembly in a debug build][:asm :run] -[2:23:57][Compare the ComputeLightPropagtion() assembly in optimised build][:asm :run] +[2:23:57][Compare the ComputeLightPropagation() assembly in optimised build][:asm :run] [2:25:51][@blamebauer][Q: Newbie question: Wouldn't inlining every function call speed things up? Does the compiler do that when you turn optimizations on?[ref site=WikiChip page="Core i7-7700K - Intel" diff --git a/cmuratori/hero/code/code569.hmml b/cmuratori/hero/code/code569.hmml index 379a110..5600d01 100644 --- a/cmuratori/hero/code/code569.hmml +++ b/cmuratori/hero/code/code569.hmml @@ -70,14 +70,14 @@ [1:29:19][Increase tCloseEnough in RayCast()][:lighting] [1:29:42][Determine the tCloseEnough filtering to be garbage][:lighting :run] [1:30:33][@vaualbus][Q: Can we add for a test a second bounce or it require more work?][:lighting] -[1:31:18][Temporarily make TestCastFromProbe() bounce our rays once][:lighting] +[1:31:18][Temporarily make TestCastFromProbes() bounce our rays once][:lighting] [1:34:50][Check out our hacked secondary bouncing of the ray cast :lighting][:run] -[1:36:16][Delete the secondary bounce code from TestCastFromProbe()][:lighting] +[1:36:16][Delete the secondary bounce code from TestCastFromProbes()][:lighting] [1:36:43][Check we didn't screw anything up there][:lighting :run] [1:37:04][@stevenlr][Q: Do you plan on adding details on how sprites are lit? Right now they are full dark when the light is behind it. Maybe normal maps or some subsurface transport? Although I guess bounces will help with that anyway][:lighting] [1:37:45][@qiaoster][Q: It's my second year programming and it feels like there's endless stuff to catch up before I can be a competent games programmer. What might I do to help with that?] [1:39:12][@vaualbus][Q: It should be SecCast not Cast?][:lighting] -[1:39:21][Reintroduce and fix the secondary bounce code in TestCastFromProbe()][:lighting] +[1:39:21][Reintroduce and fix the secondary bounce code in TestCastFromProbes()][:lighting] [1:39:45][Check out our hacked secondary bouncing of the ray cast :lighting][:run] [1:41:01][Make SpamVoxel() take the LightP and LightC for secondary bounces to compute specially, dimming the light][:lighting] [1:43:42][Check out our dimmed secondary bouncing of the ray cast :lighting][:run] diff --git a/cmuratori/hero/code/code571.hmml b/cmuratori/hero/code/code571.hmml new file mode 100644 index 0000000..15cce74 --- /dev/null +++ b/cmuratori/hero/code/code571.hmml @@ -0,0 +1,65 @@ +[video member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Adding a Light Hierarchy" vod_platform=youtube id=r53FentCzXs annotator=Miblo] +[0:02][Recap and set the stage for the day][:speech] +[0:49][Acquaint us with the problem of targeting and gathering nearby light sources][:lighting :research] +[3:48][Consider making a :"data structure" for figuring out which directions to cast our rays][:lighting :research] +[5:36][Closest Light Query][:blackboard :"data structure" :lighting] +[5:54][Light Cuts][:blackboard :"data structure" :lighting] +[12:55][Introduce light_node][:"data structure" :lighting] +[15:43][Modify lighting_solution to remove LightBoxTargetP and add RootLightBoxIndex, and begin to make BuildSpatialPartitionForLighting() build trees of occluders and lights][:"data structure" :lighting] +[25:16][Walk through SplitBox()][:lighting :research] +[27:46][Fix compile errors in BuildSpatialPartitionForLighting()][:"data structure" :lighting] +[28:18][Consider using the root light box to cast against, and continue to walk through SplitBox()][:lighting :research] +[30:32][Make SplitBox() set an accumulated RefC][:lighting] +[33:22][Consider initialising the root occluder and light boxes' RefC][:lighting :research] +[35:42][Introduce CalculateRefC() for BuildSpatialPartitionForLighting() to initialise the root boxes' RefC][:lighting] +[38:57][Rename GetSpatialLeafForP() to GetLightLeafForP() and make it query for the (not guaranteed) closest light source][:geometry :lighting] +[44:57][Introduce GetDistanceToBoxSq() and GetClosestPointInBox()][:geometry :lighting] +[53:43][Make GetLightLeafForP() call GetDistanceToBoxSq() properly][:geometry :lighting] +[54:57][See that our light is kind of busted][:lighting :run] +[56:25][Step in to TestCastFromProbes() and inspect our Solution][:lighting :run] +[57:05][Step through GetLightLeafForP() and watch what it does][:lighting :run] +[57:33][Fix BuildSpatialPartitionForLighting() to pass ActualLightCount to the lights' SplitBox()][:lighting] +[58:31][Step back in to GetLightLeafForP() and still see a ChildCount of 2][:lighting :run] +[58:50][Step through BuildSpatialPartitionForLighting() with an ActualLightCount of 8, and on through GetLightLeafForP()][:lighting :run] +[1:02:54][Stop BuildSpatialPartitionForLighting() from setting RootBoxIndex from AddBoxReference(), and +1 to the Source in light boxes' SplitBox() call][:lighting] +[1:03:35][See that we're still busted][:lighting :run] +[1:03:50][Make GetLightLeafForP() draw its spatial hierarchy walk][:"debug visualisation" :geometry :lighting] +[1:06:42][See that our box spatial query is wrong][:"debug visualisation" :geometry :lighting :run] +[1:07:01][Consider our problem to be in GetClosestPointInBox()][:geometry :lighting :research] +[1:09:07][Getting the closest point in a box][:blackboard :geometry] +[1:11:19][Make GetLightLeafForP() call GetClosestPointInBox() directly, before itself then calling LengthSq()][:geometry :lighting] +[1:11:55][See that our box spatial query remains wrong][:"debug visualisation" :geometry :lighting :run] +[1:12:09][Make GetLightLeafForP() draw the closest positions][:"debug visualisation" :geometry :lighting] +[1:13:15][Check out our closest points, to see that it may actually be fine][:"debug visualisation" :geometry :lighting :run] +[1:14:20][Scrutinise BuildSpatialPartitionForLighting()][:geometry :lighting :research] +[1:15:51][Fix BuildSpatialPartitionForLighting() to loop over the ActualBoxCount][:geometry :lighting] +[1:16:46][See that our spatial hierarchy remains misplaced][:geometry :lighting :research] +[1:17:08][Continue to scrutinise BuildSpatialPartitionForLighting() and SplitBox()][:geometry :lighting :research] +[1:22:05][Augment lighting_solution with a ScratchC for BuildSpatialPartitionForLighting() to use][:"data structure" :geometry :lighting] +[1:22:53][See that our spatial hierarchy is now correctly placed and queried][:"debug visualisation" :geometry :lighting :run] +[1:23:37][Prevent CompileZBiasProgram() from disabling the :lighting] +[1:24:00][Admire our :lighting][:run] +[1:25:21][Work on reading our test sphere, removing CubeSideWeight from light_sampling_sphere and Weights from sphere_store, and related code][:"data structure" :lighting] +[1:27:45][Prepare to invoke hhsphere][:lighting :research] +[1:29:06][Invoke hhsphere][:admin :lighting] +[1:32:45][Invoke hhsphere in release mode][:admin :lighting] +[1:33:06][Admire our generated handmade_sampling_sphere.inl][:lighting :research] +[1:33:37][Determine to implement ComputeVoxelIrradianceAt() and make BuildSpatialPartitionForLighting() preserve voxel contents][:lighting] +[1:38:06][Set up ComputeLightPropagationWork() to read from our light sphere, picking one random point on a light source][:lighting] +[1:44:08][Determine to figure out how to update our voxel field][:lighting :speech] +[1:44:56][Q&A][:speech] +[1:47:02][@x13pixels][Q: What is the go to assembler for 64-bit code on Windows these days? Is MASM still maintained, people moving to NASM, something else?[ref + site=NASM + url=https://nasm.us][ref + site="The Yasm Modular Assembler Project" + url=https://yasm.tortall.net]][:asm] +[1:51:07][@leachleach][Q: If I buy ~RemedyBG now, will I also get access to upcoming versions of it or just the current and past ones?] +[1:51:16][@steamymcfly][Q: Do you think with all recent processor vulnerabilities being found that future processors will use a fundamentally different optimizing architecture?][:hardware] +[1:54:24][@letambourinroyal][Q: What's the go to thing for learning assembly][:asm] +[1:54:53][@lucid_frost][Q: If assemblers were better would you consider programming in x86 / ARM directly (which ever you are trying to target primarily) for everything? Maybe it would auto translate on the backend and you could rewrite critical sections for secondary platforms][:language] +[1:56:59][@vtlmks][@cmuratori Do you know of a write-up similar to 'How to avoid C/C++ runtime on Windows' by [@mmozeiko Mārtiņš Možeiko] on the Handmade Hero forum,[ref + site="Handmade Hero Forums" + page="Guide - How to avoid C/C++ runtime on Windows" + url=https://hero.handmade.network/forums/code-discussion/t/94-guide_-_how_to_avoid_c_c++_runtime_on_windows/] but for Linux?] +[1:57:32][Wrap things up][:speech] +[/video]