* This is a little dirty, as it's loading the profile multiple times. The proper way to do it would be to add any line starting with "unlocked_" to an array for deferred loading. This would also allow us to write those lines back even without the associated set being loaded. The clean solution is on my todo-list now :)
* Decks now support naming and renaming. Also added a "Switch decks without saving" option.
* Removed unused static const char * menuTexts, from old 6-deck limited system
* Keypad didn't display correctly when not given a title, and was never destructed. Fixed.
* profileFile() default behavior was to fall back to RESPATH/player. Fixed.
* New iconspsp.png, updated look to seem like PSP buttons, added some extra (unused) button icons.
* 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.
This is pretty major, so there'll probably be something wrong with it... even though I did spend a few hours looking.
NOTES:
* If you've Retrieved it, don't delete it--- Use resources.Release(Whatever).
Textures automatically release subordinate quads.
* Most of the time, use resources.RetrieveQuad to grab a quad. Should handle everything for you.
RetrieveQuad will load the required texture, if needed.
Only managed resources have a resource name ("back", "simon", etc).
Managed resources can be retrieved with GetTexture/GetQuad/GetWhatever.
Non managed quads lookup by position/dimensions, defaulting to the whole texture.
* Use resources.RetrieveTexture only when you need to do something special to it.
Calling retrieve texture with RETRIEVE_MANAGE will permanently add a texture to the manager
RETRIEVE_LOCK and RETRIEVE_VRAM will lock a texture. It will not leave the cache until
Release(JTexture*) is called, or as a last resort during cache overflow.
* Try to only store (as a class member) pointers to textures retrieved with RETRIEVE_MANAGE.
All others may become invalid, although locked textures do have a high degree of stability. It's
pretty safe to store a locked texture if you're not going to load much between uses.
There's a lot going on here, so I might have missed something... but it runs through the test suite alright.
TODO:
* When called without any arguments, RetrieveQuad sometimes leaves a thin border around the image.
This can be bypassed by specifying a quad one or two pixels less than the image size. Why?
* I've had a crash while runing the Demo mode, something to do with receiveEventMinus?
This hasn't exactly reproduced on a clean SVN copy, (being a hang, rather than a crash) so
I've probably done something to worsen the problem somehow? I'll look into it tomorrow.
* Clean up lock/unlock system, memory usage. Streamline interface, consider phasing out calls using GetWhatever() format.
* New interface.
* This breaks a lot of things. It is not feature-equivalent. It
probably doesn't compile under windows and doesn't work on PSP.
* Damage is not resolved any more. This will have to be fixed.
* Blockers can't be ordered any more. This will have to be fixed.
* A lot of new art is included.
- Replaced the BasicAbilities Array with a map. This reduces the size of MTGCard from >500 bytes to 392. Should be cool for people who have memory issues
* Add the rolling phasebar.
* This is a preview version. It shares most of the code with the definitive
version, but when the real code is checked in, this will be deleted.
- Added a few "stats" to the main menu. This might slow down loading times on the PSP (needs testing). In that case I'll move it to the options, or optimize it if needed
- fixed a problem with DOS card files under psp/linux
- Added a bunch of SAFE_DELETE, not sure they're really necessary
- fixed a small interface problem in Shop
- It is now possible to have avatars associated to each Deck
- Added SFX
- Added Music files
- Possibility to choose your opponent
- Opponents' difficulty is measured according to their number of victories against a given deck
- Fixed MP3 play bug on the psp. MP3 files need to have NO Id3v2 tag, or they won't play. Also, volume control is broken
- added dt to moving W's easter egg movement.
- Added fullscreen for windows version
- other stuff ?
