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

[video output=day251 member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Finishing the Debug Hierarchy" vod_platform=youtube id=LTTaqnFBtwk annotator=Miblo]
[0:45][Run the game and see where we're at in terms of the debug hierarchy]
[2:45][handmade_debug.cpp: Look through how the hierarchy is currently being built]
[6:52][handmade.cpp: Note that the DEBUG_VALUE should have appeared in the debug view]
[7:55][handmade_debug_interface.h: Confirm that DEBUG_VALUE should be being set correctly]
[8:36][handmade_debug.cpp: Investigate why DEBUG_VALUE is not appearing as expected]
[10:25][Debugger: Step into a DEBUGDrawEvent call and inspect the Event]
[10:44]["Somebody is doing something dumb"][quote 408]
[11:17][Debugger: Try to step into a StoreEvent call and realise that the Event is already being parsed previously]
[13:23][handmade_debug.cpp: Delete the GetElementFromEvent call from CollateDebugRecords and call it on demand where it's needed]
[15:39][Propose putting everything into the hierarchy, to avoid the constant problem of needing to decide whether Elements should go into DataBlocks or not]
[16:54][handmade_debug.cpp: Make the GUID get set correctly]
[18:02][handmade_debug.cpp: Comment out the GUID setting in StoreEvent]
[20:02][handmade_debug.cpp: Rework how the debug groups get set]
[24:01][Run the game and see that it isn't working at all]
[24:39][handmade_debug.cpp: Initialise Element to 0 when making an OpenDebugBlock]
[28:53][handmade_debug.cpp: Introduce debug_parsed_name and DebugParseName]
[30:16][handmade_debug.cpp: Call DebugParseName and continue reworking]
[34:30][Debugger: Compile and hit a first-chance exception]
[35:29][handmade_debug.cpp: Remove StoreEvent call for CloseDataBlock]
[35:38][Debugger: Compile and run and see that we're almost there, with possibly only a data bug]
[36:08][handmade.cpp and win32_handmade.cpp: Correct the names of our DEBUG_DATA_BLOCK]
[37:01][Run the game and admire our debug information]
[38:13][handmade_debug.cpp: Modify the logic in GetGroupForHierarchicalName to enable correct expansion of the hierarchy]
[45:40][Run the game and see that we seem to be good, besides the fact that debug values are not editable]
[46:44][Lodge a complaint against Mr Five minute warning][quote 409]
[46:52][handmade_debug.cpp: Delete everything related to OpenDataBlock]
[47:20][handmade_debug.cpp: Investigate why we cannot edit the debug values]
[49:05]["C++ is awesome and always does everything wrong"][quote 410]
[49:10][handmade_debug_interface.h: #define DEBUG_B32 to manually specifiy that it is a boolean]
[49:51][handmade.cpp: Call DEBUG_B32]
[50:36][Debugger: Run the game, see that the debug values are still not editable and start to investigate why]
[52:14][handmade_debug_interface.h: Provisionally introduce the notion of needing to DEBUGHandleValueEdit in DEBUG_B32 and DEBUG_VALUE]
[55:37][Q&A][:speech]
[56:12][@dino27_1988][Wednesday, you talked about Microsoft's Xbox process to detect which vertex was closest to another to form quads / tris / faces. Do you have the math behind that or maybe a link about it? I tried looking for it since then without any success]
[56:46][Blackboard: Triface meshes and "locality"]
[1:06:13]["It's just a full tristrip and it touches itself maximally"][quote 411]
[1:06:25][Blackboard: A perfect patch for maximum throughput, without needing to restart the tristrip]
[1:08:27][Blackboard: Primitive Assembly Cache and Vertex Transform Cache]
[1:12:40][@dino27_1988][Well yes, what you are now figuring out, that was my question. How does it "know" to use which vertex point to make triangles when you add them? Like, in your first grid example, how does it know not to draw a triangle from your center vertex to the upper left vertex (or any opposing vertex, for that matter)?]
[1:14:06][Blackboard: Primitive Assembly: Triangles, Tristrips and Trifans]
[1:14:54][Blackboard: Triangles]
[1:15:46][Blackboard: Tristrips]
[1:17:09][Blackboard: Trifans]
[1:19:33][@robrobby][You mentioned shortly to make Handmade Hero startup quicker which is slow now because of what OpenGL has to do. How? Would think we need to load the textures first before showing Handmade Hero?]
[1:20:37][@ffsjs][For people who do 3D meshes, it seems there's a rule (at least for Blender, as far as I know) that using anything else than quads for topology produces rendering artifacts, so it has to be avoided. Is this because when rendering in-game everything gets split again into triangles? Ignore the Q: if what I'm asking doesn't make sense]
[1:23:02][@ginger_bill][With OpenGL context creation, which bit is the slow bit? Is it SetPixelFormat, as it may be VS2013 that is the problem? In VS2015 this is not as slow]
[1:23:49][shell.bat: set _NO_DEBUG_HEAP=1 in order to disable the debug heap]
[1:25:47][Debugger: Run the game and note that the startup is now probably a little faster]
[1:27:52][Explain the debug heap]
[1:28:46][Close down][:speech]
[1:29:34][Promote Handmade After Dark[ref
    site="Handmade After Dark"
    url="http://handmadedev.org/handmade-after-dark/"]][:research]
[/video]
Cinera 0.7.0 Update Add output parameter to all of hero/code, hero/intro-to-c and hero/misc, preserving the current URLs while allowing different .hmml filenames, notably for hero/misc which now gets sorted chronologically. Update the cinera__*.css files 2020-05-09 20:59:36 +00:00			`[video output=day251 member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Finishing the Debug Hierarchy" vod_platform=youtube id=LTTaqnFBtwk annotator=Miblo]`
Relocate riscy and add newly converted hero The idea here is to reduce the amount of superfluous stuff downloaded to each server running cinera 2017-12-06 22:26:13 +00:00			`[0:45][Run the game and see where we're at in terms of the debug hierarchy]`
			`[2:45][handmade_debug.cpp: Look through how the hierarchy is currently being built]`
			`[6:52][handmade.cpp: Note that the DEBUG_VALUE should have appeared in the debug view]`
			`[7:55][handmade_debug_interface.h: Confirm that DEBUG_VALUE should be being set correctly]`
			`[8:36][handmade_debug.cpp: Investigate why DEBUG_VALUE is not appearing as expected]`
			`[10:25][Debugger: Step into a DEBUGDrawEvent call and inspect the Event]`
			`[10:44]["Somebody is doing something dumb"][quote 408]`
			`[11:17][Debugger: Try to step into a StoreEvent call and realise that the Event is already being parsed previously]`
			`[13:23][handmade_debug.cpp: Delete the GetElementFromEvent call from CollateDebugRecords and call it on demand where it's needed]`
			`[15:39][Propose putting everything into the hierarchy, to avoid the constant problem of needing to decide whether Elements should go into DataBlocks or not]`
			`[16:54][handmade_debug.cpp: Make the GUID get set correctly]`
			`[18:02][handmade_debug.cpp: Comment out the GUID setting in StoreEvent]`
			`[20:02][handmade_debug.cpp: Rework how the debug groups get set]`
			`[24:01][Run the game and see that it isn't working at all]`
			`[24:39][handmade_debug.cpp: Initialise Element to 0 when making an OpenDebugBlock]`
			`[28:53][handmade_debug.cpp: Introduce debug_parsed_name and DebugParseName]`
			`[30:16][handmade_debug.cpp: Call DebugParseName and continue reworking]`
			`[34:30][Debugger: Compile and hit a first-chance exception]`
			`[35:29][handmade_debug.cpp: Remove StoreEvent call for CloseDataBlock]`
			`[35:38][Debugger: Compile and run and see that we're almost there, with possibly only a data bug]`
			`[36:08][handmade.cpp and win32_handmade.cpp: Correct the names of our DEBUG_DATA_BLOCK]`
			`[37:01][Run the game and admire our debug information]`
			`[38:13][handmade_debug.cpp: Modify the logic in GetGroupForHierarchicalName to enable correct expansion of the hierarchy]`
			`[45:40][Run the game and see that we seem to be good, besides the fact that debug values are not editable]`
			`[46:44][Lodge a complaint against Mr Five minute warning][quote 409]`
			`[46:52][handmade_debug.cpp: Delete everything related to OpenDataBlock]`
			`[47:20][handmade_debug.cpp: Investigate why we cannot edit the debug values]`
			`[49:05]["C++ is awesome and always does everything wrong"][quote 410]`
			`[49:10][handmade_debug_interface.h: #define DEBUG_B32 to manually specifiy that it is a boolean]`
			`[49:51][handmade.cpp: Call DEBUG_B32]`
			`[50:36][Debugger: Run the game, see that the debug values are still not editable and start to investigate why]`
			`[52:14][handmade_debug_interface.h: Provisionally introduce the notion of needing to DEBUGHandleValueEdit in DEBUG_B32 and DEBUG_VALUE]`
Fix some incorrectly converted annotations Also apply some :speech categorisation 2018-03-07 21:48:09 +00:00			`[55:37][Q&A][:speech]`
Relocate riscy and add newly converted hero The idea here is to reduce the amount of superfluous stuff downloaded to each server running cinera 2017-12-06 22:26:13 +00:00			`[56:12][@dino27_1988][Wednesday, you talked about Microsoft's Xbox process to detect which vertex was closest to another to form quads / tris / faces. Do you have the math behind that or maybe a link about it? I tried looking for it since then without any success]`
			`[56:46][Blackboard: Triface meshes and "locality"]`
			`[1:06:13]["It's just a full tristrip and it touches itself maximally"][quote 411]`
			`[1:06:25][Blackboard: A perfect patch for maximum throughput, without needing to restart the tristrip]`
			`[1:08:27][Blackboard: Primitive Assembly Cache and Vertex Transform Cache]`
			`[1:12:40][@dino27_1988][Well yes, what you are now figuring out, that was my question. How does it "know" to use which vertex point to make triangles when you add them? Like, in your first grid example, how does it know not to draw a triangle from your center vertex to the upper left vertex (or any opposing vertex, for that matter)?]`
			`[1:14:06][Blackboard: Primitive Assembly: Triangles, Tristrips and Trifans]`
			`[1:14:54][Blackboard: Triangles]`
			`[1:15:46][Blackboard: Tristrips]`
			`[1:17:09][Blackboard: Trifans]`
			`[1:19:33][@robrobby][You mentioned shortly to make Handmade Hero startup quicker which is slow now because of what OpenGL has to do. How? Would think we need to load the textures first before showing Handmade Hero?]`
			`[1:20:37][@ffsjs][For people who do 3D meshes, it seems there's a rule (at least for Blender, as far as I know) that using anything else than quads for topology produces rendering artifacts, so it has to be avoided. Is this because when rendering in-game everything gets split again into triangles? Ignore the Q: if what I'm asking doesn't make sense]`
			`[1:23:02][@ginger_bill][With OpenGL context creation, which bit is the slow bit? Is it SetPixelFormat, as it may be VS2013 that is the problem? In VS2015 this is not as slow]`
			`[1:23:49][shell.bat: set _NO_DEBUG_HEAP=1 in order to disable the debug heap]`
			`[1:25:47][Debugger: Run the game and note that the startup is now probably a little faster]`
			`[1:27:52][Explain the debug heap]`
Fix some incorrectly converted annotations Also apply some :speech categorisation 2018-03-07 21:48:09 +00:00			`[1:28:46][Close down][:speech]`
Relocate riscy and add newly converted hero The idea here is to reduce the amount of superfluous stuff downloaded to each server running cinera 2017-12-06 22:26:13 +00:00			`[1:29:34][Promote Handmade After Dark[ref`
			`site="Handmade After Dark"`
Fix some incorrectly converted annotations Also apply some :speech categorisation 2018-03-07 21:48:09 +00:00			`url="http://handmadedev.org/handmade-after-dark/"]][:research]`
Relocate riscy and add newly converted hero The idea here is to reduce the amount of superfluous stuff downloaded to each server running cinera 2017-12-06 22:26:13 +00:00			`[/video]`