38 lines
3.6 KiB
Plaintext
38 lines
3.6 KiB
Plaintext
[video output=day159 member=cmuratori stream_platform=twitch stream_username=handmade_hero project=code title="Cleaning Up the Loaded Asset Infrastructure" vod_platform=youtube id=ZrAoRHSTzMY annotator=debiatan annotator=ZedZull]
|
|
[00:00:22][Recap and plan for today]
|
|
[00:02:02][Preventing eviction of locked assets (those used in background tasks)]
|
|
[00:04:06][We never lock any asset; let's lock some]
|
|
[00:07:01][Not locking sounds]
|
|
[00:07:55][The render group knows whether an asset should be locked or not]
|
|
[00:08:21][Safeguarding against caller mistakes]
|
|
[00:12:41][Preventing the eviction of assets before they are completely loaded]
|
|
[00:15:54][Testing the changes]
|
|
[00:16:26][Moving the most recently used asset to the front of the linked list]
|
|
[00:22:04][Getting the header from the slot is tricky]
|
|
[00:29:29][MoveHeaderToFront should only affect loaded bitmaps]
|
|
[00:30:14][Deciding to clean up the loaded asset code]
|
|
[00:30:30]["Locked" as a flag, independent of asset loading stage]
|
|
[00:36:48][Checking the commit size of the game on the Windows task manager. Casey's head gets in the way; see Q at 01:01:43]
|
|
[00:39:06][Simplifying the loaded asset infrastructure]
|
|
[00:40:29][Merging asset slot and asset]
|
|
[00:44:24][Condensing everything necessary to work with an asset into the asset header]
|
|
[00:52:49][Storing the size of the loaded asset instead of its type]
|
|
[00:54:01][Some debugging]
|
|
[00:58:39][Removing GetSizeOfAsset]
|
|
[01:00:55][Q&A][:speech]
|
|
[01:01:43][@ttbjm][Your head was over the window when you were looking at the commit size]
|
|
[01:02:59][@constantinopol][The linked-list way of computing least-used asset seems like a simple and neat trick. What are its drawbacks?]
|
|
[01:05:58][@manicthenobody][Garlandobloom may be too drunk today]
|
|
[01:06:11][@gasto5][Can you explain the code in which you changed the asset loading so that it stops blinking (the bitmaps and sounds)?]
|
|
[01:13:53][@culver_fly][Will there be a concern of cache misses while manipulating the doubly linked lists every frame?]
|
|
[01:15:16][@graeme7][You've got a TODO about the size of the audio asset struct. How important do you think it is to keep structs compact? -- (Casey undoes the size shrinking of LoadedBitmap, since now it's included in the asset header and not in the asset slot (blackboard))]
|
|
[01:20:20][@braincruser][Do you have a hard drive to check this system on it?]
|
|
[01:20:38][@captainduh][Is there a problem setting the asset header to null after unlocking it? I thought there was some background loading of some stuff]
|
|
[01:21:19][@breadthofhair][Is the heap and the stack just different sections of RAM, managed by the OS? Also, if so, do different programs ever share stack space? Would you please shed some light on this or point me to some video of yours that I missed?]
|
|
[01:22:25][@breadthofhair][I'm confused as to what the memory layout will be after using the doubly linked list for a while? The memory will fragment eventually as of now, no?]
|
|
[01:23:32][@constantinopol][Couldn't we use just use a 'IsLocked' bool, inside 'Asset->Header' struct?]
|
|
[01:23:50][@groggeh][Won't this method of swapping the assets cause memory fragmentation?]
|
|
[01:27:47][@captainduh][So something like this can't happen? Asset evict function is called, release happens, unlock happens, thread context switches to loader, something gets loaded into that slot with some header, thread context switches back, header is cleared to 0]
|
|
[01:30:37][@jameswidman][Is it possible that, due to the kernel caching disk accesses, we're paying more than once for each asset? Like, after we evict an asset, is another copy of it likely to be cached in physical memory because of the OS's caching of the pack file?]
|
|
[/video]
|