[video member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Finishing Sort Acceleration via Gridding" vod_platform=youtube id=maQL_OmS-kM annotator=Miblo]
[0:09][Recap and set the stage for the day]
[1:43][win32_handmade.cpp: Toggle on GlobalShowSortGroups, run the game and view those graphs]
[3:59][handmade_render.cpp: Accelerate BuildSpriteGraph() by making it loop through everything in each grid cell when we do an insertion]
[8:45][Run the game and see how our ACCELERATED_SPRITE_SORT fares]
[10:08][handmade_render.h: Increase the resolution of the SORT_GRID, run the game and see how this affects the speed of BuildSpriteGraph()]
[12:00][build.bat: Temporarily switch to -O2, run the game and see that this drastically improves the speed of BuildSpriteGraph()]
[12:55][handmade_render.cpp: Pass NoClear() to the PushStruct() calls in BuildSpriteGraph()]
[15:14][Run the game and consider the possibility that we may be checking things multiple times]
[17:29][Blackboard: How the grid partitioning makes us check things multiple times]
[19:19][Blackboard: Our two options for avoiding this]
[20:34][Consider how to tag the sprites as having been touched]
[22:53][handmade_render.h: Move the existing flags in the sprite_flag enum into the high bits and add Sprite_IndexMask]
[25:11][handmade_render.cpp: Make BuildSpriteGraph() & the B->Flags with Sprite_IndexMask]
[27:04][Run the game and see that the cycles are much rarer]
[27:34][Explain what just happened]
[29:12][win32_handmade.cpp: Toggle GlobalShowSortGroups off, run the game and see how our changes have affected the speed of BuildSpriteGraph()]
[31:26][Blackboard: Manual Sort Override]
[37:28][Blackboard: Edges Added Manually]
[39:54][Blackboard: Specifying Sprites to be Drawn as a Group]
[42:40][handmade_render.h: Consider adding a Count to the sort_sprite_bound struct]
[44:32][handmade_render_group.h: Try adding a NextOffset to the render_group_entry_header struct]
[46:38][handmade_opengl.cpp: Make OpenGLRenderCommands() daisy-chain the render entries]
[49:57][Run the game, demo a sorting situation we need to resolve and consider how to resolve it]
[53:00][Blackboard: Why put the daisy-chaining into the actual sorting system]
[55:21][handmade_render_group.cpp: Provisionally make PushRenderElement_() only sort a NewElement, otherwise merge the Existing entry]
[1:01:23][Compile and run properly]
[1:01:34][Q&A]
[1:02:07][@Miblo][Thanks to the grid partitioning, do we now have a convenient way of doing the graph sort in SIMD, possibly processing four grid squares, or four sprites within a square, at once? Or is it not quite that simple?]
[1:05:38][@themikedx][With regards to the flags and the order checking, if you are &ing the flags with the id, to test if you have seen it before, what happens when another item does the same check and &s it with the same (changed) unit? Doesn't that make the result different to the check flags & mask = id for the new item? Did I miss something (or did you & the flags with the mask before you set the id to clear it (the old id) first?]
[1:06:59][Blackboard: How the Flags and the Sprite_IndexMask is working]
[1:09:37][handmade_render.cpp: Streamline BuildSpriteGraph() a touch]
[1:13:39][@goodpau6][Will we ever do any network programming on Handmade Hero (i.e. multiplayer)?]
[1:14:08][@bryanwwag][I love how you said "we don't want to solve this with hacks" for a particular sorting condition. Do you think the engine should cover most / all boundary conditions or is there room for "boundary hacks" in certain / extreme circumstances?]
[1:14:53][Blackboard: On not having the necessary information to do a correct sort in 2D]
[1:17:45][Close down]
[/video]