Unifying Debug and Editor Modes
References ▼
Windows Dev Center
Multi-engine n-body gravity simulation
[1]1:55:41
Pastebin
The even simpler dumping format
[2]2:12:33
Wikipedia
Krampus
[3]2:37:32
The Reremouse
Krampus Ruten
[4]2:37:32
Filter mode:
Topics
Media
api
asset system
debug system
file io
hardware
input handling
language
library
memory
rendering
ui
(null topic)
🗪Chat Comment
🏃In-Game
🖮Programming🟉
📖Research
🗩Speech
🎭
🏟
🔗
Link to: current timestamp
Credits
Host
Casey Muratori
Indexer
Matt Mascarenhas
?
?

Keyboard Navigation

Global Keys

[, < / ], > Jump to previous / next episode
W, K, P / S, J, N Jump to previous / next timestamp
t / T Toggle theatre / SUPERtheatre mode
V Revert filter to original state Y Select link (requires manual Ctrl-c)

Menu toggling

q Quotes r References f Filter y Link c Credits

In-Menu and Index Controls

a
w
s
d
h j k l
←
↑
↓
→

Esc Close menu / unfocus timestamp

Quotes and References Menus and Index

Enter Jump to timestamp

Quotes, References and Credits Menus

o Open URL (in new tab)

Filter Menu

x, Space Toggle category and focus next
X, ShiftSpace Toggle category and focus previous
v Invert topics / media as per focus

Filter and Link Menus

z Toggle filter / linking mode

Credits Menu

Enter Open URL (in new tab)
0:00Recap and set the stage for the day
🗩
0:00Recap and set the stage for the day
🗩
0:00Recap and set the stage for the day
🗩
0:52Set up to unify the debug and asset editing interfaces
🏃
0:52Set up to unify the debug and asset editing interfaces
🏃
0:52Set up to unify the debug and asset editing interfaces
🏃
5:42Introduce the notion of a global dev_mode, of which asset editing and profiling are modes
5:42Introduce the notion of a global dev_mode, of which asset editing and profiling are modes
5:42Introduce the notion of a global dev_mode, of which asset editing and profiling are modes
11:16The categories in our current debug system
🏃
11:16The categories in our current debug system
🏃
11:16The categories in our current debug system
🏃
12:18Add keybindings for our modes in GameUpdateAndRender(), making each mode monopolise the keyboard
12:18Add keybindings for our modes in GameUpdateAndRender(), making each mode monopolise the keyboard
12:18Add keybindings for our modes in GameUpdateAndRender(), making each mode monopolise the keyboard
23:38Try out our UI mode-switching keys
🏃
23:38Try out our UI mode-switching keys
🏃
23:38Try out our UI mode-switching keys
🏃
23:58Set up to split the debug system's UI across modes
📖
23:58Set up to split the debug system's UI across modes
📖
23:58Set up to split the debug system's UI across modes
📖
29:05Make DEBUGDrawElements() draw only the elements associated with the current mode
29:05Make DEBUGDrawElements() draw only the elements associated with the current mode
29:05Make DEBUGDrawElements() draw only the elements associated with the current mode
43:48Flesh out GetName() to produce fuller information appropriate to the element's type
43:48Flesh out GetName() to produce fuller information appropriate to the element's type
43:48Flesh out GetName() to produce fuller information appropriate to the element's type
1:01:41See no immediate change in the debug UI
🏃
1:01:41See no immediate change in the debug UI
🏃
1:01:41See no immediate change in the debug UI
🏃
1:02:02Change debug variable links to use their linked element's info directly, introducing CreateNameElement()
1:02:02Change debug variable links to use their linked element's info directly, introducing CreateNameElement()
1:02:02Change debug variable links to use their linked element's info directly, introducing CreateNameElement()
1:18:14Try out the debug UI and crash in DEBUGBeginInteract()
🏃
1:18:14Try out the debug UI and crash in DEBUGBeginInteract()
🏃
1:18:14Try out the debug UI and crash in DEBUGBeginInteract()
🏃
1:19:02Enable DrawTreeLink() to add child elements to trees
🏃
1:19:02Enable DrawTreeLink() to add child elements to trees
🏃
1:19:02Enable DrawTreeLink() to add child elements to trees
🏃
1:20:28Check out our debug UI to find our Root text appearing in the "Profile" section
🏃
1:20:28Check out our debug UI to find our Root text appearing in the "Profile" section
🏃
1:20:28Check out our debug UI to find our Root text appearing in the "Profile" section
🏃
1:20:50Fix CanHaveChildren() to correctly handle our circular linked list
1:20:50Fix CanHaveChildren() to correctly handle our circular linked list
1:20:50Fix CanHaveChildren() to correctly handle our circular linked list
1:21:55Check out our functional debug UI
🏃
1:21:55Check out our functional debug UI
🏃
1:21:55Check out our functional debug UI
🏃
1:23:05Make DEBUGEnd() draw only the tree of debug elements associated with the current mode, introducing DrawTree()
1:23:05Make DEBUGEnd() draw only the tree of debug elements associated with the current mode, introducing DrawTree()
1:23:05Make DEBUGEnd() draw only the tree of debug elements associated with the current mode, introducing DrawTree()
1:35:07Try out mode-switching to find our asset editor unexpectedly appearing when pressing F5
🏃
1:35:07Try out mode-switching to find our asset editor unexpectedly appearing when pressing F5
🏃
1:35:07Try out mode-switching to find our asset editor unexpectedly appearing when pressing F5
🏃
1:37:24Fix UpdateAndRenderEditor() to only operate in its own mode
1:37:24Fix UpdateAndRenderEditor() to only operate in its own mode
1:37:24Fix UpdateAndRenderEditor() to only operate in its own mode
1:37:56Try out our Profile mode, and crash in StringLength()
🏃
1:37:56Try out our Profile mode, and crash in StringLength()
🏃
1:37:56Try out our Profile mode, and crash in StringLength()
🏃
1:38:26Introduce DEBUG_UI_HUD() for GameUpdateAndRender() to initialise a HUD to house our Profile mode
1:38:26Introduce DEBUG_UI_HUD() for GameUpdateAndRender() to initialise a HUD to house our Profile mode
1:38:26Introduce DEBUG_UI_HUD() for GameUpdateAndRender() to initialise a HUD to house our Profile mode
1:44:49Find that our Profile mode now works
🏃
1:44:49Find that our Profile mode now works
🏃
1:44:49Find that our Profile mode now works
🏃
1:44:56Make GameUpdateAndRender() initialise HUDs for all our debug modes
1:44:56Make GameUpdateAndRender() initialise HUDs for all our debug modes
1:44:56Make GameUpdateAndRender() initialise HUDs for all our debug modes
1:45:30Try out all of our debug modes
🏃
1:45:30Try out all of our debug modes
🏃
1:45:30Try out all of our debug modes
🏃
1:45:52Make DEBUGEnd() snap our UI to the screen corners
1:45:52Make DEBUGEnd() snap our UI to the screen corners
1:45:52Make DEBUGEnd() snap our UI to the screen corners
1:48:15Try out our debug UI snapped to the corner, noting some inconsistent scaling / positioning
🏃
1:48:15Try out our debug UI snapped to the corner, noting some inconsistent scaling / positioning
🏃
1:48:15Try out our debug UI snapped to the corner, noting some inconsistent scaling / positioning
🏃
1:49:50Make UpdateAndRenderEditor() draw the UI in UISpace
1:49:50Make UpdateAndRenderEditor() draw the UI in UISpace
1:49:50Make UpdateAndRenderEditor() draw the UI in UISpace
1:53:27Check out our asset editor sidebar
🏃
1:53:27Check out our asset editor sidebar
🏃
1:53:27Check out our asset editor sidebar
🏃
1:54:01Make DEBUGEnd() also draw the UI in UISpace
1:54:01Make DEBUGEnd() also draw the UI in UISpace
1:54:01Make DEBUGEnd() also draw the UI in UISpace
1:55:06Check out our debug modes sidebar
🏃
1:55:06Check out our debug modes sidebar
🏃
1:55:06Check out our debug modes sidebar
🏃
1:55:41printf_armin Q: How would you go about exposing a very object-oriented API to C without ending up in the disaster that DX12 did (with their C API1)? Especially if the API has something like a device for its central access point like this gives you queues and surfaces and buffers
🗪
1:55:41printf_armin Q: How would you go about exposing a very object-oriented API to C without ending up in the disaster that DX12 did (with their C API1)? Especially if the API has something like a device for its central access point like this gives you queues and surfaces and buffers
🗪
1:55:41printf_armin Q: How would you go about exposing a very object-oriented API to C without ending up in the disaster that DX12 did (with their C API1)? Especially if the API has something like a device for its central access point like this gives you queues and surfaces and buffers
🗪
2:00:22zrizi Q: (Off-topic) Best way of moving data from disk to GPU: What I think I really want is to get a GPU mapped memory chunk and map my asset file right over there (assuming I prepared the data to be GPU friendly). What I have right now is loading from disk into memory and then either doing glBufferSubData or glBufferMapView and copying the data. How can I avoid this copy?
🗪
2:00:22zrizi Q: (Off-topic) Best way of moving data from disk to GPU: What I think I really want is to get a GPU mapped memory chunk and map my asset file right over there (assuming I prepared the data to be GPU friendly). What I have right now is loading from disk into memory and then either doing glBufferSubData or glBufferMapView and copying the data. How can I avoid this copy?
🗪
2:00:22zrizi Q: (Off-topic) Best way of moving data from disk to GPU: What I think I really want is to get a GPU mapped memory chunk and map my asset file right over there (assuming I prepared the data to be GPU friendly). What I have right now is loading from disk into memory and then either doing glBufferSubData or glBufferMapView and copying the data. How can I avoid this copy?
🗪
2:12:33thebirkisreal Q: Updated the dumpview "spec" a little.2 Is this a little clearer about things? Also added some elements with a determined length
🗪
2:12:33thebirkisreal Q: Updated the dumpview "spec" a little.2 Is this a little clearer about things? Also added some elements with a determined length
🗪
2:12:33thebirkisreal Q: Updated the dumpview "spec" a little.2 Is this a little clearer about things? Also added some elements with a determined length
🗪
2:13:46quickshift_ Q: So OOP's fallacy is basically overusing inheritance?
🗪
2:13:46quickshift_ Q: So OOP's fallacy is basically overusing inheritance?
🗪
2:13:46quickshift_ Q: So OOP's fallacy is basically overusing inheritance?
🗪
2:19:28zrizi Q: Great answer. So is it possible to memory map a file to GPU pinned memory for non texture data then? I think about a complex 3D model. Sounds like you can't avoid this memory copy. I agree that textures are trickier, especially if they are compressed already
🗪
2:19:28zrizi Q: Great answer. So is it possible to memory map a file to GPU pinned memory for non texture data then? I think about a complex 3D model. Sounds like you can't avoid this memory copy. I agree that textures are trickier, especially if they are compressed already
🗪
2:19:28zrizi Q: Great answer. So is it possible to memory map a file to GPU pinned memory for non texture data then? I think about a complex 3D model. Sounds like you can't avoid this memory copy. I agree that textures are trickier, especially if they are compressed already
🗪
2:23:57quickshift_ Q: The main thing I'm concerned with is, since I've never really programmed in OOP (got to know about Handmade Hero early enough), I can't be sure if I'm sometimes transitioning into OOP accidentally. And it really bugs me, since you could say that "device" or "texture" structs are "objects" or something like that
🗪
2:23:57quickshift_ Q: The main thing I'm concerned with is, since I've never really programmed in OOP (got to know about Handmade Hero early enough), I can't be sure if I'm sometimes transitioning into OOP accidentally. And it really bugs me, since you could say that "device" or "texture" structs are "objects" or something like that
🗪
2:23:57quickshift_ Q: The main thing I'm concerned with is, since I've never really programmed in OOP (got to know about Handmade Hero early enough), I can't be sure if I'm sometimes transitioning into OOP accidentally. And it really bugs me, since you could say that "device" or "texture" structs are "objects" or something like that
🗪
2:34:20zrizi Q: In the OOP example that you gave, you assume that you have access to the source code. That might be the case in Handmade Hero but if you're using a library you sometimes don't have access to the cpp sources. Another reason to use unity build without libraries
🗪
2:34:20zrizi Q: In the OOP example that you gave, you assume that you have access to the source code. That might be the case in Handmade Hero but if you're using a library you sometimes don't have access to the cpp sources. Another reason to use unity build without libraries
🗪
2:34:20zrizi Q: In the OOP example that you gave, you assume that you have access to the source code. That might be the case in Handmade Hero but if you're using a library you sometimes don't have access to the cpp sources. Another reason to use unity build without libraries
🗪
2:34:46skulboy_dota Q: You are right that OOP is bad when every single field of a class has a getter / setter, however in general it is better to only have getters for most fields, making sure they can only be changed by the class itself. It's the same reason globals are generally to be avoided, state changing randomly makes code hard to follow
🗪
2:34:46skulboy_dota Q: You are right that OOP is bad when every single field of a class has a getter / setter, however in general it is better to only have getters for most fields, making sure they can only be changed by the class itself. It's the same reason globals are generally to be avoided, state changing randomly makes code hard to follow
🗪
2:34:46skulboy_dota Q: You are right that OOP is bad when every single field of a class has a getter / setter, however in general it is better to only have getters for most fields, making sure they can only be changed by the class itself. It's the same reason globals are generally to be avoided, state changing randomly makes code hard to follow
🗪
2:37:32Wrap it up with a recommendation of Krampuslauf3,4
🗩
2:37:32Wrap it up with a recommendation of Krampuslauf3,4
🗩
2:37:32Wrap it up with a recommendation of Krampuslauf3,4
🗩