Currently asset reloading is causing a bunch of issues.
The main issue is that objects which store direct pointers to assets (E.G renderable->material) get invalidated if somewhere else in the system the asset pointed to is reloaded.
It seems that objects sharing assets in unavoidable so this reloading is always going to happen in one form or another. Unless very careful steps are taken this will increase to be an issue. I see a few options:
1. Ensure objects never hold pointers directly to assets.
This solution is annoying because it causes a performance overhead (in the lookup) and forces objects to store string identifiers which means more memory management and are just generally a pain.
An alternative to string identifiers is to store a pointer to an asset pointer. If this were the case the asset manager could still manipulate the second pointer and change it at reload time. This is faster and less hassle than storing the string identifier but still a pain, and still relies on policy that no object holds pointers directly to assets.
2. Ensure assets reload into the same location.
This is appealing for many reasons but it rings alarm bells in my head because I am sure there will be unforeseen issues. It would require some serious adaptions to the asset manager but should be viable.
One potential issue is that pointers inside an asset struct become different on reload. But providing no exterior objects hold pointers one level deep into an asset this should be okay.
Another issue is that if someone does an "unload" and "load" rather than a "reload" it is impossible to ensure the asset is loaded again into the same location and so it may still cause invalidation.
Until more bright ideas come up I will continue in consideration.
Currently asset reloading is causing a bunch of issues.
The main issue is that objects which store direct pointers to assets (E.G renderable->material) get invalidated if somewhere else in the system the asset pointed to is reloaded.
It seems that objects sharing assets in unavoidable so this reloading is always going to happen in one form or another. Unless very careful steps are taken this will increase to be an issue. I see a few options:
1. Ensure objects never hold pointers directly to assets. This solution is annoying because it causes a performance overhead (in the lookup) and forces objects to store string identifiers which means more memory management and are just generally a pain. An alternative to string identifiers is to store a pointer to an asset pointer. If this were the case the asset manager could still manipulate the second pointer and change it at reload time. This is faster and less hassle than storing the string identifier but still a pain, and still relies on policy that no object holds pointers directly to assets.
2. Ensure assets reload into the same location. This is appealing for many reasons but it rings alarm bells in my head because I am sure there will be unforeseen issues. It would require some serious adaptions to the asset manager but should be viable. One potential issue is that pointers inside an asset struct become different on reload. But providing no exterior objects hold pointers one level deep into an asset this should be okay. Another issue is that if someone does an "unload" and "load" rather than a "reload" it is impossible to ensure the asset is loaded again into the same location and so it may still cause invalidation.
Until more bright ideas come up I will continue in consideration.