- 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.
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.
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
* Removed all calls to Release(JQuad*).
* Updated flatten(). Prior flatten was buggy beyond belief.
* Done some extensive testing, but if this causes more trouble than it fixes, we'll have to revert. It's too close to release time.
- fix issue 20 (triangle button usage inplay)
- close issue 27 (gold effect on the gold bar). Please feel free to change the gold glow if you come up with something better, but I consider this perfectly releasable now
- code cleanup
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.
