Exception handling in the cache means that Wagic runs slightly, but noticeably slower. However, it also means that the cache works the way it was intended to, and should prevent all sorts of awkward errors I introduced because things were half-allocated or worse.
I've learned my lesson from tonight, and once I get this stuff put back together without exception handling I think I'll self-impose a manditory 24 hours debugging time before any commits. Sorry for the inconvenience.
If for some reason you can't compile with exceptions, r862 should be completely without them. Again, wow, this was stupid-- I hadn't even realized exceptions were off for like 24 hours, as the compiler wasn't producing warnings.
Apologies,
—Jeck
* 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.
- Fixed empty ActionStack "interrupt" messages
- If no attackers are declared, go straight to Combat end phase
- Once First strike damage is declared, attacking player needs to "actively" request a next phase event to go to the next damage step
- Second Damage step is called "Combat Damage (2)"
- UserRequestNextPhase is to be used knowing that it might not succeed
- Step change for GuiCombat is now computed at GameObserver::nextGamePhase
Note: Combat damage to creatures is not assigned when AI attacks. As this seems to be a problem with the previous SVN version, I4m still committing this change
-fixed problem with lifelink+wither, although combat damages are not entirely correct. Once combat damages actually deal the correct amount of damage, let's put test "armadillo_cloak" back in the suite
