cinera_handmade.network/cmuratori/hero/code/code452.hmml

73 lines
7.4 KiB
Plaintext
Raw Permalink Normal View History

[video output=day452 member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Improving Camera Placement and Room Alignment" vod_platform=youtube id=4EdDZlVH8bY annotator=Miblo]
2018-05-28 19:38:41 +00:00
[0:00][Recap and set the stage for the day][:speech]
[1:30][:Run the game with the determination to position and zoom the :camera to focus on a given rectangle, and retain the :simulation region until the camera transitions are complete]
[7:39][Make UpdateAndRenderWorld() merge the :camera bounds into the :simulation region]
[8:42][:Run the game to still see entities drop out of the :simulation region]
[9:05][Enlarge the SimBounds in UpdateAndRenderWorld()][:camera :simulation]
[10:00][:Run the game and no longer see entities drop out of the :simulation region]
[10:49][Note the risks to allowing the :simulation region to be determined by the :camera]
[16:13][:Run the game and set up to implement our dynamically zooming :camera]
[21:52][Determine to hand-code :camera zoom levels per room][:run]
[23:24][Work towards enabling UpdateCameraForEntityMovement() to set the TargetOffsetZ from the stored CameraOffset.z][:camera]
[26:21][:Run the game to see nothing][:camera]
[26:46][Make GenerateRoom() initialise the CameraOffset.z to 16][:camera]
[27:21][:Run the game to see our usual :camera view]
[27:37][Introduce GetCameraOffsetZForDim() to dynamically zoom the :camera]
[34:43][Make UpdateAndRenderWorld() write out the Camera.OffsetZ][:profiling]
[35:23][:Run the game and watch that Camera.OffsetZ change while traversing the orphanage][:camera]
[38:10][Determine to fix the :camera's room selection bug][:run]
[40:09][Make UpdateAndRenderEntities() draw the room boundaries][:"debug visualisation"]
[41:08][:Run the game to see those room boundaries][:"debug visualisation"]
[41:43][Fix GenerateRoom() to correctly align the collision volumes of both even- and odd-sized rooms, removing the world_room_camera struct and making ChunkPositionFromTilePosition() take a world_generator that contains the TileDim][:camera :geometry]
[55:03][:Run the game to see that the room alignment is off-by-one][:camera :geometry]
[55:31][Fix GenerateRoom() to correctly align the room collision volumes][:camera :geometry]
[55:46][:Run the game to see that the rooms are correctly aligned in X and Y, and consider how to align them in Z][:camera :geometry]
[57:12][Temporarily prevent ChunkPositionFromTilePosition() from offsetting the room collision volumes in Z][:geometry]
[58:01][:Run the game to see how this change aligns the rooms][:geometry]
[59:01][Make GenerateRoom() compute the RoomCenter along all axes][:geometry]
[1:01:51][Step in to GenerateRoom() to see that MakeSimpleGroundedCollision() may be busted][:geometry :run]
[1:03:28][Change GenerateRoom() to align the room collision volumes using MapIntoSimSpace() renamed from GetSimRelativePosition()][:geometry]
[1:07:57][:Run the game to see how our rooms are now aligned, and consider peeking into rooms][:geometry]
[1:12:20][Introduce AddLamp() for GenerateRoom() to call and add a lamp to every room][:lighting :rendering]
[1:16:04][:Run the game to see the bright lights][:lighting :rendering]
[1:16:43][Prevent UpdateAndRenderWorld() from adding a light at the hero's location][:lighting :rendering]
[1:17:01][:Run the game to see our unlit hero][:lighting :rendering]
[1:17:31][Reduce the lamp brightness in GenerateRoom()][:lighting :rendering]
[1:17:46][:Run the game to see our dimmer lights][:lighting :rendering]
[1:18:13][Make AddLamp() reposition the lamps, and GenerateRoom() generate them in the four corners of the rooms][:lighting :rendering]
[1:23:26][:Run the game to see our lights in the corners of rooms][:lighting :rendering]
[1:24:36][Enable GenerateRoom() to randomise the light colours][:lighting :rendering]
[1:26:34][:Run the game to see our differently coloured lights][:lighting :rendering]
[1:27:20][@insobot][4 minutes into the Q&A, 11 until end. (based on NOTE)]
[1:28:10][Make PushCube() take a v3 Radius to uniformly size cubes, and propagate this change][:geometry]
[1:36:10][:Run the game to find that the walls are suddenly taller][:geometry]
[1:37:34][Make GenerateRoom() align the rooms in Z as they were before][:geometry]
[1:38:57][:Run the game to see the room alignment][:geometry]
[1:40:34][Prevent GenerateRoom() from offsetting the HalfTileDim.z][:geometry]
[1:42:00][:Run the game to see the room alignment][:geometry]
[1:43:24][Consider our alignment scheme][:geometry :speech]
[1:45:30][Draw the chunk locations in UpdateAndRenderWorld()][:"debug visualisation"]
[1:48:30][:Run the game to see our chunk boundary][:"debug visualisation"]
[1:48:47][Prevent ChunkPositionFromTilePosition() from adjusting the Offset.z][:geometry]
[1:49:03][:Run the game to see that the chunk boundary lines up with the floor][:geometry]
[1:49:14][Disable most of the :"debug visualisation" and take a walk about the orphanage][:programming :run]
[1:50:34][Disable the room boundary :"debug visualisation"]
[1:50:59][:Run the game and consider our dynamic :camera]
[1:51:45][Q&A][:speech]
[1:52:02][@joshuadolman][Q: Is there a particular reason why the sim region and / or :lighting region are based on "world space" rather than connected rooms? I know that's how it was originally put together but are there any benefits / disadvantages either way? Also, if you place the lighting boundary right before a lamp and then move so it enters the light region, doesn't it kind of pop-in a little? (It's more of a fade but hopefully you know what I mean, entering the big square room does what I mean with the lamps at the top)][:rendering]
[1:54:41][@sahfortv][Q: I think there were two typos: 1. GetCameraOffsetZForDim() had XCount; typo 2. PushLight() PushCube() had x, x, z]
[1:55:15][Fix typo in GetCameraOffsetZForDim()][:camera]
[1:56:46][@lorymaster][Q: Haven't really followed much, but are those static lights simulated? If yes, would it be a good idea to make their :lighting pre-calculated to improve :performance?][:rendering]
[1:57:30][@pragmascrypt][Q: Will the up-facing sprite cards be affected by the :lighting in the future?][:rendering]
[1:58:05][@alexkelbo][Q: Will we do shadow maps?][:lighting :rendering]
[1:58:25][Consider how shadow maps could work with sprite cards, and making stairwells][:lighting :rendering :run]
[2:00:11][@ttbjm][Q: It looks like rooms below you can be outside of the :lighting volume][:rendering]
[2:02:23][@cvaucher][Q: I'm cleaning up the color handling to track down :rendering differences between my OpenGL and Metal backends. Is there a generally accepted way to pass / store colors in the pipeline, i.e. pre-convert everything in the asset packer to linear or widest color space? The world generation code is currently linearizing the sRGB color inputs so that they can then be reconverted to sRGB by OpenGL during blending. This seems inefficient?]
[2:05:39][@alexkelbo][Q: Should we change the color of the hero sprite depending on the surrounding light? He looks too bright in the darker areas][:lighting :rendering]
[2:07:22][@0lpbm][Q: Shouldn't lights behave as other entities in regards to the sim region?][:lighting :rendering :simulation]
[2:08:06][@0lpbm][Q: I thought they are visible when outside?][:lighting :rendering :simulation]
[2:08:16][Understanding the :simulation region in terms of the :lighting][:rendering :run]
[2:10:47][@jim0_o][Q: Will you be adding fire-flies and will you call them lighting-bugs?]
[2:10:55][That's all, folks][:speech]
[/video]