- added 2 menus to wait for connection and wait for deck selection
- tested compilation on Qt Linux, Qt Windows and PSP
- deactivated everywhere (NETWORK_SUPPORT to activate).
The core problem I fixed was in CardView's (missing) destructor - on construction, a CardView will set itself as a member of its parent CardInstance, so it stands to reason that when it's about to be destroyed, it should do the inverse and remove itself in the same fashion from its parent. This explains why weird graphic glitches were seen when casting Animate Dead on cards in a graveyard - the position data it was trying to use was already deleted from memory (a cardview is deleted on cleanup at the end of a turn if it's gone to the graveyard), but no one nulled out the deleted card view reference from the instance, so we'd access invalid data.
Some peripheral changes in this checkin: two helper functions in CardGui (GetCenterX, GetCenterY) that are part of my navigation patch are included. They're unused in the current code base, so this has zero impact. (I'm only checking them in as it's more work than it's worth to refactor them into a separate changelist. The core of the nav patch requires my mods to Closest.cpp / CardSelector.cpp to have any effect.) I also included a helper function in the debug routines to spit out hex pointer addresses in trace outputs, which I used to chase down this bug.
While debugging this, I noticed a separate issue: when changing profiles, we'd actually call refresh twice. Removed the spurious call, as reloading profiles doesn't need to concern itself with the image cache - that's already covered by the game options menu.
Also did some minor formatting / cleanup in the JGfx code for PSP - stubbed out a bunch of JLOG calls I had put in while debugging the PNG loading code.
1) Consolidated the Loggers so that we only have one in JGE. Added a helper constructor/destructor to the JLogger class so that you can instantiate one at the top of a function, it'll trace out a 'start' and 'end' message when it goes in & out of scope.
2) Fixed the crash part of a bug I've been chasing down where, on the psp, after saturating the cache, the game dies when trying to reload the background PNG image of the deck menu. We still need to fix the root cause of the failure (not enough memory to allocate a temporary buffer for the swizzle operation), but at least the psp doesn't lock up anymore. I've also left behind all the log traces I inserted into the LoadPNG code, since we'll probably need them again.
- fixed the debug framerate calculation / drawing code (consolidated duplicated functions & variables mDelta vs a win-only mDeltaTime, no reason to have two), repositioned it to draw on the bottom left (it was colliding with other debug text for the cache info).
- for debug testing purposes, added a #define override to force the image cache to work with less memory (I've picked 8 megs, which is what the psp seems to use - the normal default on win/linux is 20 megs).
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.
- Added a possibility to put a file "Res.txt" instead of the folder "Res". The file Res.txt is a simple 1 line text file, telling where to find the Res folder, terminated by "/". For example: "../../wagic_res".
This addresses issue 428 . This could also help us in the future, to develop mods.
I'm also noticing that the GetQuad(int) variant never seems to get hit, so I suspect that the ID lookup map is redundant. I left it alone as the JResourceManager base class forces the need for the function; I need to spend more time looking at just how much of JResourceManager we actually use at this point.
- JGE updates : main accepts argv/argc. Compilation variables for MP3 and Network support
- Minor fix in Wagic (potentially fixes crashes when using activated abilities several times in onr turn. Couldn't reproduce the issue)
- fixed bugs introduced in revision 2034 (Giant Growth)
- Extended Story mode xml: much easier to write basic thing, font selection, possibility to position answers, answers now in correct order
- moved story in the menu because it is not major for now
- fix issue 392 (broken tests)
- Fix a bunch of memory leaks (guys please be careful!)
- Added Logging facility in JGE
- HBL Compatibility (cleaned up some code with MP3 in JGE)
- Added "winGame" ability. Currently used mostly by the story mode, but some cards could probably need it too
- Improved story mode and uncommented it from the source.
-- The current campaign is of course very basic, anybody who wants to improve it or create other ones feel free to do so
-- TODO (short term): save progress, rewards system, improve tutorial campaign
-- I'll talk a bit more about this on the forums/email after a night of sleep
* Make the FULLSCREEN function bindable on platforms that support it.
* Linux has F as default binding.
* Windows support is not implemented, but is there ; applications will
just not suggest it under windows for the moment.
* Some cosmetic cleanup.
* Have the unix version report analog control the same way the
windows version does.
* Move back Run() into JGE::Run(). The code for ::Run() is still
inside main.cpp.
- This fixes the "blinking screen problem", issue 341. I think.
- I have no idea WHY it does, but it's better than not fixing it.
- Run() would be better in ::Run() in main.cpp than in JGE, should
be moved back when we know more about the problem.
* This update has Wagic compile and work under Darwin 64-bits.
- Linux 64-bits is expected to compile and work from now on, but
was not tested. As with before, Linux 64 bits can still run
the 32 bits version.
- Darwin version is not using Carbon but X emulation.
- 64-bits versions have no sound because there is no 64-bits
version of fmod.
- Windows 64-bits probably does not compile. Windows 64-bits can
still run the 32 bits version.
- Darwin 32-bits probably does not work at the moment because the
libfmod requires another name to work on Macs, but as 64-bits
disables it it works.
- Other unix flavors are expected to work as long as they have
a working OpenGL library, X11, and *either* 64-bits *or* a
working fmod. Thus in the practice Tru64, Irix and the like
probably work, as should FreeBSD and other BSDs in 64 bits
versions, but 32 bits versions will search for a non-existing
fmod. All of this is pure conjecture and none was tested.
- All 64-bits versions have no sound.
- The mac version does not display the particles at the moment.
This is not critical, but the cause is unknown yet. I would
like to know if other 64 bits unices share the same bug or if
it is mac-specific.
* Test is needed in particular to see whether the program still
compiles and works in Linux and PSP. Windows is probably all
right, but compiling PSP in windows may be broken by this
update.
Added basic transition system that works with GameApp's phases. Currently does a fade-out between elements, which works well in some places and not-so-well in others. We'll definitely want to think about where and where not to use it... they'd work a lot better if we could spawn a thread to handle loading the next state while transitioning.
Also cleaned up the shop a bit, so it uses ReadButton() instead of GetButtonClick()-- hence the slight change to JGE. Added a tiled image for the task board, which loads conservatively (I tried 128x128, but it didn't look as good).
