* pruned out unused local variables.
---- There's no need to define something if it isn't going to be referenced. It consumes extra memory temporarily and more than anything is a potential cause for confusion down the road.
- This is some Work in progress to make Wagic less "game" dependent.
This change especially is an attempt at moving away from some dangerous patents owned by some company.
It introduces "modrules.xml", a global configuration file describing dynamic settings for any given Wagic mod. It is very basic for now, but allows to customize a bit. In particular, it allows to remove the concept of shop and deck editor from the game, dynamically generate the main menu, and represent card activation with a mask rather than a rotation.
I have a sample in progress which I hope to submit in the days to come, a proof of concept (nothing fancy yet) for another type of game using these ideas, as well as a few other things I introduced recently.
In the future, I am hoping to extend modrules.xml so that it entirely describes the rules of a given card game. the other files in rules.txt will describe "extensions" to the core rules, just like they do right now, so this new file does not make them obsolete.
- Also fixed minor bugs I stumbled upon while developing
I've marked all the ones I found with the following TODO comment:
TODO: C6246: <blah blah>
a few in particular are the ones related to "oneShot" and "_target". These are local variables that are declared that
mask either a method parameter or a member variable.
reason for this change is that it becames WAY to hard to player decks which contained mostly artifacts to share the feild, give 9 cards half the screen to display just didnt seem like a good choice compared to the creatures horizontal stack which can display almost 200 cards in the same screen width.
2nd, started laying some ground work for planeswalkers.
added the planeswalker rule, as per mtg rules, if you have a type=planeswalker subtype=jace already on the battlefield, both are sent to the graveyard. so you can not have a jace mind scuptor and a jace beleren out at the same time. i choose to use subtype= and type= rather then adding another variable to MTGCard...
also, added GuiPlay positioning for planeswalker,
i think theres been a HUGE misunderstanding about planeswalkers which has most going "battlefield is too crowded where would be put them...easy...slap them at the end of the lands ..done...theyre not creatures or artifacts/enchantments..so i moved them to the colum with the lands and have guiplay slap them at the end of that colum...btw this is in no means final...if someone can think of a better solution be my guest, but looking at the planeswalker (workaround) thread, its pretty obvious that no one will care where we slap the planeswalkers, as long as theyre supported. planeswalkers have alot more ground to cover...
what this change does is this. if i have 20 enchantments on the battlefield Ai's creatures and lands no longer slide to the right. and vice versa. made no sense that if the other player had no artifacts/enchantments that HIS lands and creatures would slide simply because the OTHER player had artifacts/enchantments.
I've also added my current work on the zone navigation system (class Navigator) - it's currently turned off for now (the override for this is inside of CardSelectorSingleton's Instance() call, simply comment out the NEW CardSelector and uncomment out the NEW Navigator line.) It's functional, but I want to do more testing before considering wiring it into the game options or something similar. (Also, note that it currently doesn't support the mouse functionality added by DJardin.)
Lastly, there's a bug crash fix in ActionStack that I tripped across while testing - basically, an illegal index value would have us walk off the bounds of a vector.
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
* Some cleaning after r1062 code review.
- Remove code that was never reached.
- Remove a useless function.
- Make GuiPlay treat cards that are both spells and creatures as
creatures and not spells.
- fix issue 65 (quads when no image load slowly in shop/deck editor)
- Possibly fix issue 92, please let me know if it reproduces
- Fix issue 97 (Deck editor: weird behavior of deck display)
- Fix issue 39 - please verify
- Issue 56 can probably be closed as well
- Fix issue 86
* 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.
