In details:
- I removed my player swap idea, it caused tons of issues with randoms
- instead I simply keep both peer on the exact same game and added one single parameter allowing to configure the view on the game. So, each peer is rendering the same game (gameObserver class) from a different player point of view (DuelLayers and related classes).
- a lot of gui stuff are missing to prevent user forbidden interactions but it works fine on Windows
this can also be used for "equipped creature has unattach and blah" cards using
auto=teach(creature) {unattach}:blah
also corrected a long standing guiupdating issue. a long long time ago a replace was removed from GuiPlay::Update in hopes to increase performance no amount of performance increase is worth having cards not updating thier position after an event recieve happens. this means curse will finally go to the correctly choosen players battlefield, equipment will no longer just linger after its target dies, auras won't stay on battlefield after a card is exiled. ect. no preformance decrease noticed, if anyone else notices one let me know.
adjusted the calculation of x for enstack attackers to avoid drawing cards on top of the phase wheel out outside of the red box. adjusted the red box length for uniformity.
the previous calculation only drew cards to the middle of the screen and after about 15 attackers it pushed cards out of the red box, over on top of the phase wheel making it impossible to click or touch requiring alternative methods to advance to damage phase or reduction of the amount of attackers.
the new calculation draws attackers at the start of the red box keeping the enstack a cardwidth and a half from the edge of the screen on both sides instead instacking massive amounts of attackers tighter inside the red box, much how we handle battlefield enstack...attacking with more then 40 creatures no longer pushes attackers off screen.
- Modified the testsuite and gameobserver to be able to replay all the testcases based on the actions logged during the first pass. This allows to test the action logging and replay used during undo. It's only activated in multithreaded mode and it does not work on Momir tests.
- Modified choice logging and replay to use menuId instead of ability index, as, for some obscur reasons related to Lord, those ability indexes may change.
- Fixed bug in nextphase logging wrongly generating click actions
- Added a "stack" zone to the click ability logging to be able to replay properly interrupt
- Fixed a wonderful bug mixing card names with zone names in the actions execution engine
- Added a "combatok" action logging/execution
- Added a "clone" virtual method to MTGCardInstance and Token to be able to clone correctly the right object type. Used that in MTGGameZones::removeCard
- Reworked the testsuite to be able to work multithreaded. This is deactivated by default everywhere except in QT_CONFIG as one testcase still refuses to pass in multithreaded mode. On my 4 cores linux desktop, the 650 tests passes now in 4 seconds (1 fails).
- Replaced usage of CardSelectorSingleton by a card selector per game observer.
- Modified the resource manager to be optionnal and per game observer instance instead of being a singleton. Two reasons here : threading AND Open Gl access. I only updated the crashing parts called from the game observer, so most of the code is still using the single instance. Beware of copy-paste concerning resources ...
- Cleaned up the game observer constructors
- Fixed several problems in action logging code while testing proliferate decks
- Cleaned up Threading implementation based on QThread
- 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.
* 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.
