orangeduck / Corange

Pure C Game Engine
http://www.youtube.com/watch?v=482GxqTWXtA
Other
1.82k stars 199 forks source link

Asset Reloading #4

Closed orangeduck closed 12 years ago

orangeduck commented 12 years ago

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.

orangeduck commented 12 years ago

This was essentially fixed in 28f2e9d793b56a82a1ff18d3127d383ad7663a14