I moved the target quad near the source card and moved the action string
forward so there is no overlapping of action string and the target quad
if the action string is too long...
format is as follows
HINT#combo hold(blah|myhand)^until(blah|mygraveyard)^until(blah|opponentshand)^restriction{type(creature|mybattlefield)~morethan~2}^cast(blah) targeting(blah|mygraveyard)^totalmananneeded({g}{g}{r}{u}{2})
the ai can be told to hold more then one card, until as many condiations as you want are met, until( is a TC and can basically be used in a fasion of saying "hold arbor elf until you have a lord of atlantas in play and a gaint growth in you hand"
once the condiations are met you can later tell it to cast(gaint growth) targeting(arbor elf[fresh]|mybattlefield)...
I also included the whole of the games restrictions system...
so you can get really really creative with this so far.
the next thing I will do is ability targeting and card favoring.
- Modified DuelLayers to not use a global MTGPhaseGame instance anymore
- Moved the reset of currentActionCard out of the ActionLayer render function : that fixes the remaing problematic tests in the multithreaded testsuite
- Added a method in ActionLayer converting a card ability into a menu index
- Used this new method in the game observer to log correctly AI ability actions
- Added a DumpAssert method in the game observer, it can be used to dump the game and assert in order to easy crash reproduction
- Cleaned up TargetList properties access
- Added an optimisation in GuiMana to not compute update code if the rendering is not used (multi-threaded mode)
- Added a deadlock detection in the test AI vs AI multithreaded mode
- Fixed minor bugs in test AI vs AI multithreaded mode
- Added a games/second counter in the test AI vs AI rendering
Included in a new modrules.xml tags.
<cardgui>
<background> Stores information concerning the colors </ background>
<renderbig> Stores information to draw the card </ renderbig>
<rendertinycrop> Stores information to draw the card </ rendertinycrop>
</ cardgui>
Change the variables array for vectors
- removed every references to the gameobserver singleton. This object can now be instantiated several times as it's needed for minmax. To be able to do that, I mostly added a reference to a gameobserver from any targetable object (cards, players, spells) and abilities.
This btw points out another circular dependancy between the texture and the JQuad - a texture owns a bunch of JQuads, yet the renderer uses JQuads and always assumes that the texture is valid. We're going to need to add more defensiveness to JGE to protect against this.
Other changes in this check-in: WResourceManager doesn't derive from JResourceManager anymore. It actually didn't require anything from the base, so I killed the dependency. Also cleaned up the notion of a WTrackedQuad in the WCachedResource - it didn't need a separate class, just a better container.
I've build this & tested against PSP, win, linux, QT (linux). I haven't tried against iOS and QT Win, or Maemo. If these other platforms are broken, I apologize in advance! - I'm hoping it should be fairly simple to put them back into play.
added new mana display option "No Glitter" acciddently(?) lost "both" options somehow.
the new "no glitter mana display is basically "eye candy without particle effects" on PC created 2000 mana...no FPS drop...on PSP created an EXTREMELY large amount of mana before i noticed an FPS drop of any kind, this is dramatically better then
what was in previous rev, create 20 mana and crash.
if someone could figure out how i manage to lose the "Both" option, please explain to me why it wasnt showing up, i spent 2 hours trying to get it back.
both "optimize starting hand" and "Unlock all Ai Decks" appear in options under the option to "enable cheats"
optimize gives you decent starting hands, and Unlock all Ai decks is basically just a bypass options for the unlock deck mode varible wololo added.
tweaked abilitygranting Eff in Ai lessons to be divided by the number of cards in hand, this will mean Ai will tend to focus on using mana to cast spells instead of using them to grant abilities, until theres only 1 or less cards in hand, at this point it will go all out. there is a splash of randomness in Ai so it will still often do whatever it freaking wants lol, you should notice a proformence increase from Ai in this aspect. no more giving unblockable to a creature in 2nd main.
please note, one of the recent previous revs broke cheat mode "unlock cards" in deck editor, i filed a bug report. its a probelm i was not able to fix myself so there is no fix included in this rev....i came across the bug while testing cheat mode stuff.
Two things: 1) there was an extremely inefficient implementation in the particle system of a queue where, when particles expired, each expired element would be copied over(replaced) by one at the rear of the container. Depending on the performance of the update, this could range anywhere from 100 to 500 (the max particle count) memcpy operations per update loop. I replaced the flat array with a std::list, and simply pop the unneeded elements when they expire now. This seems to shave ~30% off the time spent in the Update() call.
2) Hardcoded the number of emitters for the mana particles to 60 (the default in the psi file seems to be around 114). This reduces the amount of iterations per tapped mana by just over half, which also helps the performance, and it's not really noticeable - the glow effect is a *tiny* bit more muted, but chances are, if you didn't read this comment, you probably wouldn't have noticed.
I've gone from having my psp start lagging noticeably at 8 tapped mana to about 12 - at this point, I think the bigger remaining lag is the fact that when there's a cache miss for a card image, we're doing synchronous i/o on the main thread - the framerate drop this causes is far more noticable than the mana particle lag.
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 :) )
-Issue 26: added an option for Mana Display. This needs a bit testing, but it should also lower the priority of "manapool slowness" as this mode probably fixes performance issue as well.
-I can't seem to be able to "save" some options (hand position, mana display) ion the windows version, does this change break something ?
* 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.
