This needs some impact testing, to be certain it doesn't noticeably slow anything down. In a future version I'd like to memoize checking for zip file existence in each "Res/sets/XXX/" directory once during boot, and in the themed directory whenever switching themes.
* Restored quad locking to textures, but ignore quad locks when Release(JTexture*) is explicitly called. (I just copied and modified the code from the template, rather than do anything elegant).
* Some minor fiddling with cache error states.
* Removed all calls to Release(JQuad*).
* Updated flatten(). Prior flatten was buggy beyond belief.
* Done some extensive testing, but if this causes more trouble than it fixes, we'll have to revert. It's too close to release time.
* The alternate theme is just useful for testing themes, but please comment on the changes to the main theme.
* Options reading and initializing separated from UI.
* Options UI abstracted a bit, made more easily extensible.
* With some extension, the options UI could be used as the basis for more complicated themes, if we load a file and use it to do stuff like GameStateOptions::Start()
- fix issue 65 (quads when no image load slowly in shop/deck editor)
- Possibly fix issue 92, please let me know if it reproduces
- Fix issue 97 (Deck editor: weird behavior of deck display)
- Fix issue 39 - please verify
- Issue 56 can probably be closed as well
- Fix issue 86
* Restored OptionItem saving fix.
* Booster duplicate replacement was picking random cards from the wrong set. My fault, but I've fixed it :)
* The problem with cache had nothing to do with memory fragmentation, but I've switched to an array rather than map<> just in case. The actual issue was that in GameStateDeckViewer, I'd given the cache unlimited space, thinking that AttemptNew would recover from any bad_allocs. Unfortunately, the image loading routines and similar stuff called by various implementations of WResource::Attempt() could fail halfway through, leaking memory.
The temporary solution is to set a proper limit (8000000 px, more or less) and (in case we still run out of memory) test to make certain CACHE_SPACE_RESERVED can be malloc'd/free'd. The proper solution would be to keep byte-perfect records of memory used (right now we're kinda fuzzy-- we track pixels per image and bytes per sound, but not the space for jquads or other incidentals) instead of testing a malloc, and potentially cleaning up all calls inside of Attempt() so they fail without leaks. That's what I'm working on now.
Still, it's nice to have identified the problem. This version of the cache should be fully functional, it's just a bit inelegant.
* mtgid now defaults to 0.
* TextScroller will not update when empty.
* Cache now moves WCachedResources we're finished with to a garbage pool for later use (to reduce memory fragmentation).
* Demo still crashes... but I'm thinking that has to do with fragmentation, not a leak?
* Numerous cache fixes, reduced filesystem access.
* Cache fails very gracefully.
* Cache is now a templated class, with individual caches per data-type.
* Much easier to extend.
* Extensively debugged. Try compiling with -DDEBUG_CACHE.
* Caches limits can be set on a per-item basis.
* hgeParticleSystemInfo are now cached, mana particles now fall back to defaults.
* Samples are not cached, but track filesystem misses using the cache backbone.
* Avatars are cached. Default baka avatar is now baka.jpg, to prevent collision with player.
A note on the retrieval types:
RETRIEVE_MANAGE puts a resource into a seperate, managed resource list.
Managed resources are guarenteed valid for the lifetime of the program.
Retrieving a managed quad promotes the associated texture to managed. Don't do that by mistake.
Calls to Resources.Refresh() will attempt to reload managed resources in place.
RETRIVE_LOCK (and by extension, RETRIEVE_VRAM), returns a resource after locking it.
A resource may have many locks, and remains in cache until they are all released.
If the resource is managed, it returns it unmodified.
A note on quads:
Unlike all other RetrieveWhatever() functions, the default behavior for RetrieveQuad is RETRIEVE_LOCK. Worse, Release(JQuad*) is slow, and will /always/ release one lock from the associated texture.
There's a long and complicated explanation for this, involving support for live relinking of textures to existing quads, but basically what it means is that we only use RetrieveQuad for quads we intend to store and later Release(). If a temporary quad is needed, the preferred method is to use NEW JQuad* and SAFE_DELETE with RetrieveTexture(). RetrieveTempQuad is also provided, but is only guaranteed until the next call to the cache.
Note that RetrieveCard has none of these problems.
