[37:14][Make UpdateAndRenderWorld() reconstruct the debug :camera's dolly from the regular camera's position][:geometry]
[41:33][Using the inner product to isolate the position of a point on only one axis][:blackboard :geometry]
[42:49][Add CameraPan to game_mode_world for UpdateAndRenderWorld() to compute][:camera :geometry]
[45:16][Make UpdateAndRenderWorld() reconstruct the debug :camera's orbit and pitch using ATan2()][:geometry]
[47:20][atan2 assumes that our starting vector points along x][:blackboard :geometry]
[49:57][Change UpdateAndRenderWorld() to feed an x-pointing vector to atan2][:geometry]
[52:37][Crash in FindAlign() with an "Access violation" error][:run]
[53:44][Find that the debug :camera is wrong][:run]
[54:03][Scrutinise our debug :camera construction in UpdateAndRenderWorld()][:geometry :research]
[57:15][Make UpdateAndRenderWorld() compute separate debug :camera values to aid debugging]
[59:11][Step in to UpdateAndRenderWorld() and inspect our debug :camera values][:geometry :run]
[1:05:46][Fix the winding of the DebugCameraPitch computation in UpdateAndRenderWorld()][:camera :geometry]
[1:09:40][Step back in to UpdateAndRenderWorld() and inspect our DebugCameraPitch][:camera :geometry :run]
[1:10:20][Fix the DebugCamera0 computation to use an XRotation(), and negate the PlanarArm length in the DebugCameraPitch computation][:camera :geometry]
[1:11:08][Step back in to UpdateAndRenderWorld() and inspect our DebugCameraPitch][:camera :geometry :run]
[1:12:11][Refrain from negating the PlanarArm length in the DebugCameraPitch computation][:camera :geometry]
[1:12:23][Step back in to UpdateAndRenderWorld() and inspect our DebugCameraPitch][:camera :geometry :run]
[1:12:58][Find that our orbit is −90° off][:camera :geometry :run]
[1:13:14][Fix the DebugCameraOrbit computation][:camera :geometry]
[1:14:32][Find that our debug :camera is now correct][:camera :geometry :run]
[1:15:28][Invert the mouse's X-axis in UpdateAndRenderWorld()][:camera :"input handling"]
[1:15:47][Try out our perfect debug :camera][:geometry :run]
[1:16:28][Naively make UpdateAndRenderWorld() to handle debug :camera panning]
[1:17:46][Invert the panning axes in UpdateAndRenderWorld()][:camera]
[1:17:59][Try our newly panning debug :camera, noting that it breaks when the orbits of our debug and regular cameras are not aligned][:run]
[1:18:46][Enable UpdateAndRenderWorld() to pan the :camera in camera-space]
[1:20:45][Show our :camera panning in camera-space][:run]
[1:21:13][Find that we are inverting the mouse's Y axis][:"input handling" :research]
[1:22:17][Note the correctness of our panning][:camera :"input handling" :run]
[1:22:45][Make UpdateAndRenderWorld() invert our panning and scale its speed by the :camera's distance from the subject]
[1:23:40][Try out our distance-proportional panning :camera][:run]
[1:25:28][Take a close look at our sprites in preparation to try our Z occlusion solution][:"entity system" :run]
[1:27:59][Reacquaint ourselves with SpriteValuesForUpright()][:"entity system" :research]
[1:30:21][Remove ZBias from SpriteValuesForUpright()][:"entity system"]
[1:30:32][Find that we draw just fine without the ZBias][:"entity system" :run]
[1:30:44][Temporarily make SpriteValuesForUpright() displace the sprites in Y][:"entity system"]
[1:32:33][Check out our displaced entities and adjust the alignment points to find that we are displacing in the wrong direction][:"entity system" :run]
[1:33:17][Change SpriteValuesForUpright() to use the (not inverted) WorldDim.y in the sprite displacement][:"entity system"]
[1:33:44][Align the hero's body and head, and find that we now sort beautifully (i.e. no penetration with walls), except during hopping which we are erroneously performing in Y][:"asset system" :"entity system" :run]
[1:37:25][Make UpdateAndRenderEntities() hop the entities in Z][:"entity system"]
[1:39:07][Check out our Z-hopping entities, to find that our hero never penetrates walls][:"entity system" :run]
[1:40:26][Q&A][:speech]
[1:41:35][@Brian][Q: You uploaded the last episode as episode 520, instead of 519]
[1:42:17][@recyrillic][Q: Are we gonna switch to ~remedybg for [~hero Handmade Hero] soon?]
[1:43:41][@garryjohanson][Q: So one of the reasons I became briefly enthusiastic about WinDBG Preview is the ability to record a trace of a running program and then send that trace to someone else and they can look at the exact debug session you were looking at, rather than having to reproduce a bug spending possibly a long period of time. To me that sounds like a silver bullet way to reproduce a bug. Can you think of any reason why I would be wrong to conclude that the feature is a silver bullet for reproducing bugs?]
[1:46:27][@ingenero][Q: So far it seems all the :animation is done programatically, moving static sprites. Is there any plan to include pre-set or artist-created animations?]
[1:47:30][@pythno][Q: I studied the :rendering code for a bit and it seems that the vertices and indices for the cubes (and quads) are generated each frame on the CPU and put into a big VBO which is set to stream_draw. Is this correct and, if yes, what was the decision to do it that way and not even using VAOs? For big models with a lot of polygons would you go a different route?]
[1:49:31][@vapenir][Q: What's your take on profilers vs. DIY in-game :profiling? What are some decent profilers that you know of or have used?]
[1:51:05][@pkey1][Q: What you think about python?][:language]
[1:52:16][@lucid_frost][Q: Do you think there is any value in keeping the concept of registers in the higher level :language?]
[1:52:39][@friedhit][Q: How do you feel about dynamically-typed languages?][:language]
[1:53:08][@useless_pony][Q: I may have asked this before, but have you looked at ponylang? If so, what are your thoughts on it?][:language]
[1:53:46][@vapenir][Q: Does the game load levels from files, and do you plan to include a level editor with the final game?]
[1:55:20][Deep thoughts on modern languages like PLISK, StopLang and ZnO, and their cutting edge provision for :memory composting][:language :speech]
