[0:00][Recap and set the stage for the day][:speech]
[0:52][Set up to unify the debug and asset editing interfaces][:"asset system" :"debug system" :run :ui]
[5:42][Introduce the notion of a global dev_mode, of which asset editing and profiling are modes][:ui]
[11:16][The categories in our current :"debug system"][:run]
[12:18][Add keybindings for our modes in GameUpdateAndRender(), making each mode monopolise the keyboard][:"input handling" :ui]
[23:38][Try out our :UI mode-switching keys][:"input handling" :run]
[23:58][Set up to split the :"debug system"'s :UI across modes][:research]
[29:05][Make DEBUGDrawElements() draw only the elements associated with the current mode][:"debug system" :ui]
[43:48][Flesh out GetName() to produce fuller information appropriate to the element's type][:"debug system"]
[1:01:41][See no immediate change in the debug :UI][:"debug system" :run]
[1:02:02][Change debug variable links to use their linked element's info directly, introducing CreateNameElement()][:"debug system"]
[1:18:14][Try out the debug :UI and crash in DEBUGBeginInteract()][:"debug system" :run]
[1:19:02][Enable DrawTreeLink() to add child elements to trees][:"debug system" :run :ui]
[1:20:28][Check out our debug :UI to find our Root text appearing in the "Profile" section][:"debug system" :run]
[1:20:50][Fix CanHaveChildren() to correctly handle our circular linked list][:"debug system"]
[1:21:55][Check out our functional debug :UI][:"debug system" :run]
[1:23:05][Make DEBUGEnd() draw only the tree of debug elements associated with the current mode, introducing DrawTree()][:"debug system" :ui]
[1:35:07][Try out mode-switching to find our asset editor unexpectedly appearing when pressing F5][:"asset system" :"input handling" :run :ui]
[1:37:24][Fix UpdateAndRenderEditor() to only operate in its own mode][:"asset system" :ui]
[1:37:56][Try out our Profile mode, and crash in StringLength()][:"debug system" :run :ui]
[1:38:26][Introduce DEBUG_UI_HUD() for GameUpdateAndRender() to initialise a HUD to house our Profile mode][:"debug system" :ui]
[1:44:49][Find that our Profile mode now works][:"debug system" :run :ui]
[1:44:56][Make GameUpdateAndRender() initialise HUDs for all our debug modes][:"debug system" :ui]
[1:45:30][Try out all of our debug modes][:"debug system" :run :ui]
[1:45:52][Make DEBUGEnd() snap our :UI to the screen corners][:"debug system"]
[1:48:15][Try out our debug :UI snapped to the corner, noting some inconsistent scaling / positioning][:"debug system" :run]
[1:49:50][Make UpdateAndRenderEditor() draw the :UI in UISpace][:"asset system"]
[1:53:27][Check out our asset editor sidebar][:"asset system" :run :ui]
[1:54:01][Make DEBUGEnd() also draw the :UI in UISpace][:"debug system"]
[1:55:06][Check out our debug modes sidebar][:"asset system" :run :ui]
[1:55:41][@printf_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 API[ref
site="Windows Dev Center"
page="Multi-engine n-body gravity simulation"
url=https://docs.microsoft.com/en-us/windows/desktop/direct3d12/multi-engine-n-body-gravity-simulation])? 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:22][@zrizi][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?][:"file io" :hardware :rendering]
[2:12:33][@thebirkisreal][Q: Updated the dumpview "spec" a little.[ref
site=Pastebin
page="The even simpler dumping format"
url=https://pastebin.com/raw/Dz9gCpAa] Is this a little clearer about things? Also added some elements with a determined length]
[2:13:46][@quickshift_][Q: So OOP's fallacy is basically overusing inheritance?][:language]
[2:19:28][@zrizi][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][:"file io" :hardware :rendering]
[2:23:57][@quickshift_][Q: The main thing I'm concerned with is, since I've never really programmed in OOP (got to know about [~hero 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][:language]
[2:34:20][@zrizi][Q: In the OOP example that you gave, you assume that you have access to the source code. That might be the case in [~hero 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][:language]
[2:34:46][@skulboy_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][:language]
[2:37:32][Wrap it up with a recommendation of Krampuslauf[ref
