Finishing the Debug Hierarchy — Handmade Hero — Episode Guide

0:45Run the game and see where we're at in terms of the debug hierarchy

2:45handmade_debug.cpp: Look through how the hierarchy is currently being built

6:52handmade.cpp: Note that the DEBUG_VALUE should have appeared in the debug view

7:55handmade_debug_interface.h: Confirm that DEBUG_VALUE should be being set correctly

8:36handmade_debug.cpp: Investigate why DEBUG_VALUE is not appearing as expected

10:25Debugger: Step into a DEBUGDrawEvent call and inspect the Event

10:44"Somebody is doing something dumb"^α

11:17Debugger: Try to step into a StoreEvent call and realise that the Event is already being parsed previously

13:23handmade_debug.cpp: Delete the GetElementFromEvent call from CollateDebugRecords and call it on demand where it's needed

15:39Propose putting everything into the hierarchy, to avoid the constant problem of needing to decide whether Elements should go into DataBlocks or not

16:54handmade_debug.cpp: Make the GUID get set correctly

18:02handmade_debug.cpp: Comment out the GUID setting in StoreEvent

20:02handmade_debug.cpp: Rework how the debug groups get set

24:01Run the game and see that it isn't working at all

24:39handmade_debug.cpp: Initialise Element to 0 when making an OpenDebugBlock

28:53handmade_debug.cpp: Introduce debug_parsed_name and DebugParseName

30:16handmade_debug.cpp: Call DebugParseName and continue reworking

34:30Debugger: Compile and hit a first-chance exception

35:29handmade_debug.cpp: Remove StoreEvent call for CloseDataBlock

35:38Debugger: Compile and run and see that we're almost there, with possibly only a data bug

36:08handmade.cpp and win32_handmade.cpp: Correct the names of our DEBUG_DATA_BLOCK

37:01Run the game and admire our debug information

38:13handmade_debug.cpp: Modify the logic in GetGroupForHierarchicalName to enable correct expansion of the hierarchy

45:40Run the game and see that we seem to be good, besides the fact that debug values are not editable

46:44Lodge a complaint against Mr Five minute warning^β

46:52handmade_debug.cpp: Delete everything related to OpenDataBlock

47:20handmade_debug.cpp: Investigate why we cannot edit the debug values

49:05"C++ is awesome and always does everything wrong"^γ

49:10handmade_debug_interface.h: #define DEBUG_B32 to manually specifiy that it is a boolean

49:51handmade.cpp: Call DEBUG_B32

50:36Debugger: Run the game, see that the debug values are still not editable and start to investigate why

52:14handmade_debug_interface.h: Provisionally introduce the notion of needing to DEBUGHandleValueEdit in DEBUG_B32 and DEBUG_VALUE

55:37Q&A

🗩

55:37Q&A

🗩

55:37Q&A

🗩

56:12dino27_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:12dino27_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:12dino27_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:46Blackboard: Triface meshes and "locality"

1:06:13"It's just a full tristrip and it touches itself maximally"^δ

1:06:25Blackboard: A perfect patch for maximum throughput, without needing to restart the tristrip

1:08:27Blackboard: Primitive Assembly Cache and Vertex Transform Cache

1:12:40dino27_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:12:40dino27_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:12:40dino27_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:06Blackboard: Primitive Assembly: Triangles, Tristrips and Trifans

1:14:54Blackboard: Triangles

1:15:46Blackboard: Tristrips

1:17:09Blackboard: Trifans

1:19:33robrobby 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:19:33robrobby 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:19:33robrobby 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:37ffsjs 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:20:37ffsjs 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:20:37ffsjs 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:02ginger_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:02ginger_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:02ginger_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:49shell.bat: set _NO_DEBUG_HEAP=1 in order to disable the debug heap

1:25:47Debugger: Run the game and note that the startup is now probably a little faster

1:27:52Explain the debug heap

1:28:46Close down

🗩

1:28:46Close down

🗩

1:28:46Close down

🗩

1:29:34Promote Handmade After Dark¹

📖

1:29:34Promote Handmade After Dark¹

📖

1:29:34Promote Handmade After Dark¹

📖

Keyboard Navigation

Global Keys

Menu toggling

In-Menu and Index Controls

Quotes and References Menus and Index

Quotes, References and Credits Menus

Filter Menu

Filter and Link Menus

Credits Menu