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 :) )
Zethfox: "Opponenthand gui access, cards that target(*|opponenthand) can now be coded as such, target chooser will activate allowing you to click the new icon under the avatar of the opponent and open the opponents hand Gui so you may select the target card."
Cards in opponents hand are only viewable when target choosing would allow you to enter that zone! ;)
- Added the new keyword "NAME". (by Zethfox).
When used in an autoline it replaces an autoline's "ability" text with a custom ability name.
The basic phrase is: "auto=name(whatever you want) &&".
Example card:
[card]
name=Order of the Stars
abilities=defender
auto=choice name(white) && counter(0/0,1,White) all(this)
auto=choice name(blue) && counter(0/0,1,Blue) all(this)
auto=choice name(black) && counter(0/0,1,Black) all(this)
auto=choice name(red) && counter(0/0,1,Red) all(this)
auto=choice name(green) && counter(0/0,1,Green) all(this)
auto=this(counter{0/0.1.White}) protection from white
auto=this(counter{0/0.1.Blue}) protection from blue
auto=this(counter{0/0.1.Black}) protection from black
auto=this(counter{0/0.1.Red}) protection from red
auto=this(counter{0/0.1.Green}) protection from green
text=Defender (This creature can't attack.) -- As Order of the Stars enters the battlefield, choose a color. -- Order of the Stars has protection from the chosen color.
mana={W}
type=Creature
subtype=Human Cleric
power=0
toughness=1
[/card]
The popup window for this card will now contain a list with
"white,"blue","black","red" and "green"
instead of
"ability","ability","ability","ability","ability".
This will make a lot of cards much easier to handle!
- Added 42 successfully test using one (or both) new keywords.
Card list --> First comment
Note that we did not add tests for both new keywords:
It is simply not possible to write them yet! They will follow as soon as they are possible. We guarantee that everything we submitted in this revision has been tested excessively!
* Change inplay balance.
- Spells now stack three by three.
- Spells try to space a little more.
- Creatures and land stack to the left until they hit the big card,
at which point they start displaying more compactly. At some point,
they start using all the screen even if it's under the hand.
* Add the Trash facility and use it for CardViews.
* Fix a graphical bug with card shadows.
* Fix a graphical bug with limitors.
* Enhance the graphical appearance of cards going to graveyard.
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.
wrenczes
wrenczes@gmail.com
Xawotihs
omegablast2002@yahoo.com
solo81@web.de
wagic.the.homebrew@gmail.com
jean.chalard
wagic.jeck