[37:42][Set up to implement WriteAsset() considering our .hha file format][:"asset loading" :research]
[40:34][Enable AllocateGameAssets() to track asset locations in .hha files][:"asset loading"]
[42:56][Consider either enabling .hha files to reference each other, or rewriting the header of a given .hha file on every asset edit][:"asset loading" :speech]
[46:56][Propose rewriting the entire header, and storing with each asset their type][:"asset loading" :speech]
[53:22][Remove WriteAsset() in favour of RewriteHHAHeader()][:"asset loading"]
[54:31][:Run the game to make sure it's fine]
[55:22][Consider possibly changes to our .hha file to pair up assets with their types][:"asset loading" :speech]
[59:31][Temporarily change GetBestMatchAssetFrom() and AllocateGameAssets() to chain up assets of whatever type as a linked list][:"asset loading" :"data structure"]
[1:10:22][:Run the game to see that we didn't mess anything up][:"asset loading"]
[1:10:44][Note our newfound ability to rewrite our .hha files at will and interleave our asset types, with a view to future improvements][:"asset loading"]
[1:12:42][Consider establishing the concept of editable .hha files][:"asset loading" :speech]
[1:15:06][Add EditingHHAIndex to game_assets, fixing AllocateGameAssets() to assert FileIndex < Assets->FileCount][:"asset loading"]
[1:18:50][:Run the game to see that all is okay][:"asset loading"]
[1:19:00][Make CheckForArtChanges() honour our EditingHHAIndex, and introduce RewriteHHADirectory()][:"asset loading"]
[1:21:49][Rename EditingHHAIndex to DefaultAppendHHAIndex for ProcessTiledImport() to set for the first .hha file][:"asset loading"]
[1:26:42][Add FileSize to asset_file][:"asset loading"]
[1:27:46][Growable Data Storage][:"asset loading" :blackboard :"file io"]
[1:32:14][][:"file io" :speech][quote 620]
[1:32:38][Overwriting tiny data with large data before rewriting the tiny data back out to the file][:"asset loading" :blackboard :"file io"]
[1:33:27][Add HighWaterMark to asset_file for AllocateGameAssets() to set using a newly introduced RetractWarterMark()][:"asset loading" :"file io"]
[1:46:28][Implement ReserveData() and WriteModificationsToHHA()][:"asset loading" :"file io"]
[1:56:55][Q&A][:speech]
[1:57:28][@quote_corn_if_brother][Q: Will you be making an editor for the engine?]
[1:57:41][@jixi85][Q: Did you mean to type it "retractwaRtermark"?]
[1:58:02][Fix name of RetractWaterMark()][:"asset loading" :"file io"]
[1:58:20][@enemymouse][Q: I may have missed this, but where are you handling the growth of an existing asset. Presumably you'd still need to memcpy a huge portion of the bitmaps to insert new data or remove from the middle?][:"asset loading"]
[2:00:03][@cynicalape][Q: I've probably missed this but why do we want to contiguously pack the bitmaps and the header?][:"asset loading"]
[2:02:21][@Brian][Q: Is asset_file (or forgive me, whatever you've named the file) actually a file?][:"asset loading"]
[2:03:16][@enemymouse][Q: Thanks, separate question, again from much earlier stuff I may have missed: What is the likelihood of a hash collision with the asset source names and do you handle that?][:"asset loading"]
[2:04:00][@gureitoro][Q: Wouldn't keeping different files for different assets, and keeping another file just for the index be better for source control?][:"asset loading" :vcs]
[2:06:02][@ivereadthesequel][Q: Are I/O puns off limits, cause I hope this question doesn't block! If you wouldn't mind, as you've often hailed it, what makes IOCP such a great API? How does it work better than other APIs?]
[2:08:57][@gureitoro][Q: I was thinking on the direction of always having a running build on source control][:vcs]
[2:09:45][@quickshift_][Q: When / where are you doing that Witness development presentation?]
[2:10:00][@ivereadthesequel][Q: Quick follow up: Is that just a matter of using the one message queue for more than I/O or when you need to use multiple message queues?]
[2:15:28][Close it down with a glimpse into the future tackling the tagging problem][:"asset loading" :speech]
