Also fixed the project includes so that we don't need to always use the indirect include path, ie:
#include "../include/foo.h" -> #include "foo.h"
I'm don't know much about make files - if I busted the linux build, mea culpa, but I think we're okay on that front too. For future reference, here's the most straightforward link on the topic of adding pch support to make files:
http://www.mercs-eng.com/~hulud/index.php?2008/06/13/6-writing-a-good-makefile-for-a-c-project
(I did a cursory check to make sure chinese still displays correctly - at a glance, I'm seeing what looks correct to someone who doesn't read the language :) )
CAREFUL : this update REVERSES the triggers default actions.
* Make the right trigger opens the hand and the left trigger skips to
next phase.
* Add an option to reverse triggers (and thus revert to old style).
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.
- Updated Parser mechanism. Right now this doesn't change functionalities much, but should be more readable, and make it easier to code some new abilities in the future
- Fixed regenerate, broken with r532
- Death Ward now works
- I think "&&" now works with all abilities, needs to be tested...
- Added the possibility to narrow a spell/ability target according to color,tapped status, attacker/blocker, abilities...
- Changed the games phase system to become a phaseRing. This allows to add cards that have an impact on the phases, such as stasis
- Added a few cards
- Fixed a (windows) bug in gatherer tool
- Adding stdint.h for VC++ (see wikipedia->stdint.h)
- deleting the compiled PSP lib to avoid confusion. People who work from the sourcehave to compile the lib by themselves.
