[0:01][Recap and set the stage for the day][:speech]
[1:08][Update ~remedybg[ref
site=RemedyBG
url=https://remedybg.itch.io/remedybg] and show off its new Save Layout functionality][:admin]
[3:25][Demo our :memory profiler, with the determination to draw blocks at sizes proportional to their allocation size][:"debug system" :run]
[16:59][Look into why the :memory Sizes viewer does not show all the allocations mentioned in the Arenas viewer][:"debug system" :research]
[18:53][Let DrawArenaInterval() record suppressed blocks][:"debug system"]
[20:59][Find that the :memory Sizes viewer still does not show all our expected allocations][:"debug system" :run]
[21:43][Continue to investigate the discrepancy between the Sizes and Arenas viewers][:"debug system" :research]
[24:33][Step through DrawArenaInterval() to see what it draws][:"debug system" :run]
[27:49][Fix DrawArenaInterval() to offset the BlockY when drawing suppressed blocks][:"debug system"]
[28:18][Check out our suppressed allocations in the Arenas viewer][:"debug system" :run]
[30:41][Add a toggle to the debug :UI for drawing suppressed blocks][:"debug system"]
[35:41][Crash in DrawTopMemList()][:"debug system" :run]
[36:12][Fix DrawTopMemList() to sort the correct number of arenas][:"debug system"]
[37:03][Try out our Debug toggle :UI button][:"debug system" :run]
[38:51][Investigate why the Sizes viewer does not display all Asset Storage allocations mentioned by the Arenas viewer][:"debug system" :research]
[40:14][Make DrawTopMemList() write out "blocks" and "allocs"][:"debug system" :ui]
[40:43][Check out our not pretty printout][:"debug system" :run]
[40:51][Change DrawTopMemList() to title the list][:"debug system" :ui]
[43:12][Check out our prettier, if slightly off, printout][:"debug system" :run :ui]
[43:31][Fix up our titling in DrawTopMemList()][:"debug system" :ui]
[43:38][Check out our prettier printout()][:"debug system" :run :ui]
[43:53][Tweak the titling in DrawTopMemList()][:"debug system" :ui]
[44:09][Consider merging allocation statistics by call-site][:"debug system" :research :ui]
[47:16][Set up DrawTopMemList() to display arena usage amounts per call-site, introducing debug_memory_callsite][:"debug system" :ui]
[56:05][See nothing different in the Sizes viewer][:"debug system" :run :ui]
[56:37][Enable DrawTopMemList() to print out the arena usage per call-site, adding a "Show Callsites" toggle][:"debug system" :ui]
[1:02:05][Check out our allocations per call-site Sizes viewer][:"debug system" :run :ui]
[1:03:09][Fix up the formatting of the call-sites][:"debug system" :ui]
[1:03:25][Check out our allocations per call-site, to see a high number in handmade_asset.cpp and handmade_stream.cpp][:"debug system" :run :ui]
[1:05:16][Investigate our allocations in handmade_asset.cpp, and determine that we don't care about them][:memory :research]
[1:06:20][Investigate our allocations in handmade_stream.cpp][:memory :research]
[1:07:48][Enable the Sizes viewer to more specifically locate the call-sites of string allocations, augmenting stream_chunk with a GUID for Outf() and OutfArgList() to use][:"debug system" :"string manipulation"]
[1:13:18][Hi @Molly Bean!][:speech]
[1:15:49][Check out our more detailed string allocations in the Sizes viewer][:"debug system" :run]
[1:17:03][Investigate our allocations by the call to Outf() in UpdateSingleAssetMetadata() in handmade_import.cpp][:memory :research]
[1:18:14][Fix ParseFontBlock() to apply the FontGlyph tag][:"asset system"]
[1:24:05][Rebuild the assets and find that handmade_import.cpp no longer shows up in the Sizes viewer][:"debug system" :run]
[1:25:50][Investigate our string allocations in handmade_asset.cpp][:memory :research]
[1:28:36][Dump base_game.hha and check it out in TabView, to see that multiple chained portions of an audio asset occupy the same "spritesheet" slot][:admin :"asset system"]
[1:34:01][Change AllocateGameAssets() to let all chained audio portions use the same index][:"asset system"]
[1:35:26][Find that this change did not remove our string allocations in handmade_asset.cpp][:"asset system" :"debug system" :memory :run]
[1:37:19][Step in to an erroring Outf() call in AllocateGameAssets()][:"asset system" :"debug system" :memory :run]
[1:38:31][Fix AllocateGameAssets() to correctly identify HHAAsset_Sound assets][:"asset system"]
[1:38:44][Step in to an erroring font Outf() call in AllocateGameAssets()][:"asset system" :"debug system" :memory :run]
[1:53:09][Set up to draw :memory blocks at sizes proportional to their allocation size, introducing DrawMemoryRange()][:"debug system" :ui]
[1:58:56][Q&A][:speech]
[1:59:59][@midnighttangentryan][Q: Do you code C++ for your day job?]
[2:00:11][@zrizi][Q: All these with / without comma macros is a complete nonsense… Is there any better way to deal with it?][:language]
[2:01:22][Introduce DEBUG_MEMORY_NAME to compress the debug macros][:"debug system" :language]
[2:07:43][@neutrinoq][Q: I'm a Web developer by trade and my day-to-day code seems to abstract away more logic than you do in your engine. Could you explain why that is?]
[2:08:32][@midnighttangentryan][Q: What would you do differently if you had to work with other developers on this project?]
[2:11:52][@zrizi][Q: Yes, this is a lot better. We would have a problem when dealing with a function with 0 parameters, though (I mean, the DEBUG_MEMORY_NAME is the only parameter) because of the trailing comma][:language]
[2:12:34][@said6289][Q: I'm wondering what :language feature would make what you have done with memory tracking easier. Would it be possible to make the entire call stack available for every function at compile time at all times so you don't have to do all this macro nonsense. I'm asking in the abstract sense, not whether C++ supports it]
[2:13:58][@juiceweasel][Q: If someone were looking to get into game programming today, would you recommend starting with using an engine like Unity, or would you recommend doing this lower level programming?]
[2:17:23][@zrizi][Q: (Off-topic) A question about RenderGroup, which was introduced many days ago (when we were still working on the software renderer). What is the purpose of this entity / object / :API in few words nowadays? Is it essentially a command buffer for a specific FBO with for a specific glState?][:rendering]
[2:19:43][@stric9][Q: Why are games unable to saturate storage bandwidth when loading? With modern SSDs it seems like loads should never take longer than 2-3 seconds?][:"file io"]
[2:21:43][@Brian][Q: You've mentioned that with the engine you are writing for 1935 you are spending a lot more time documenting your process and decisions when tackling a problem. Do you have any tips or examples of what you find useful to keep track of? And what you find is just noise? I find documenting well difficult and it's easy to write too much and, ironically, not enough][:documentation]
[2:23:16][@devsigner][Q: Is there a good rule of thumb when it comes to guarding against errors in your code? Is there such a thing as too much handling? I could imagine having many if-statements to check conditions could cause a performance hit][:"error handling"]
[2:26:08][@zrizi][Q: So does it mean that you have augmented this caller information in your :metaprogramming scheme so you can always query who called you? I hope that [@naysayer88 Jon] integrated these features in JAI already…][:language]
[2:26:41][@Brian][Q: For more specifics on where you log, do you have a file for each function? Do you have one / few giant document that you just keep adding to? Do you just add it directly to the code itself?][:documentation]
[2:26:57][@zrizi][Q: RenderGroup: Thanks for answering. Sounds like an abstraction of the gl :API + the notion of a renderpass?][:rendering]
[2:28:13][@synchronizerman][Q: What are your thoughts on visual programming languages? Do you imagine good use cases for them and, if so, in what contexts do you think they work? My understanding is that it's challenging to make a good visual :language and that usually the special-purpose ones work better than attempts at general-use ones]
[2:30:47][@rokuhodo][Q: To touch on the over-error checking, what about the case where you're making an API that is to be accessed by other developers? Right now I'm making a library for the TwitchAPI that will be constantly interfaced by users, but I feel like I'm holding their hand too much with errors instead of assuming they have any idea what they're doing, to the point where a significant amount of the library is just error checking][:"error handling"]
[2:33:46][@reltz_][Q: Going back to a question near the beginning about "abstracting logic", I think the heart of the questions is due to a discussion about what is "clean code". Some higher level languages seem to make things "look good" but "clean code" is, at least to me, isn't very well defined. Maybe they were looking for why does this look complex vs something that's a few lines of code (but contained in a bunch of little files, in my opinion). My thoughts are due to performance, fine tuning, and knowing exactly what's going on rather than guessing. I do that a lot using python][:language]
[2:44:01][@synchronizerman][Q: Have you tried ~Odin? Any thoughts?][:language]
[2:44:13][@zrizi][Q: [@cmuratori Casey], what you're saying is really good, but opposite to what devs are being told in schools…]
[2:46:55][@synchronizerman][Q: Java is still Intro to CS and oftentimes C / C++ is barely covered. Why do you think that is? I think it's because a lot of old "corporate" financial companies in the old guard were stuck in OOP server land. It's frustrating][:language]
