Assets and Resources

[manic saffron]

I struggle with the semantics of asset/config work. Is what I have going here how I should do that?

The code loads mutable states once from config and keep mutations on the resource. Or is accessing the asset directly for runtime modifications recommended?

fn apply_loaded_audio_config(
mut commands: Commands,
handle: Res<AudioConfigHandle>,
assets: Res<Assets<AudioConfig>>,
mut audio_config: ResMut<AudioConfig>,
) {
// write to audio_config on game launch
}

The implications that I can understand:

• Accessing the Res<Asset<T>> is verbose
• Making a Res copy duplicates the memory footprint

I think the bottom line of my problem is that I do not understand the semantic and functional difference of Res<Asset<T>> and Res<T>. Any help is appreciated.

[hot turret]

I never dived deep into assets but Resource is a Singleton. Ie, at most one instance of given type exists in the world, if you insert second it will be a replace operation.
Res<Asset<T>> then hints at Assets being a Resources. Assets themselves are just collection of the data. You can think of it as a Singletons storing all your data of type T. Like Sprites, fonts, sounds etc. All the data where you want to have it hidden behind common handle so you don't need to copy it all every time you use it.
In your case, what is exactly AudioConfig? Is that some text file you load via AssetServer?

[main radish]

a Handle<T> is the size of a usize, maybe 2, so cloning it is trivial, reading the T from Assets and cloning it does clone the entire object

acessing the data from the Assets requires a Handle (or AssetId), accessing a resource decreases that indirection

you can always drop the data from the Assets after cloning it into a Resource

[azure pawn]

Assets<T> is just another resource, the same as how you defined your AudioConfig resource. Assets<T> internally is basically a HashMap<AssetId<T>, T> (way more complicated than that of course, but it's basically that).

So if you've benchmarked, and the extra lookup is too much, then making your AudioConfig a resource could make sense.

If you haven't benchmarked though, don't do this. Making your thing a resource and an asset is a bad idea, and will likely result in desync between those two versions which is confusing at best.

Maybe that's fine though if you just want to load the initial config from disk and you never need another audio config?

If you want to avoid the memory footprint issue you can make your AudioConfig store an Arc internally btw