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 :) )
Please note that I don't plan to update this file for future Wagic versions, so if anybody wants to take over, please do. :)
Some files were updated in the process:
- CardGui.cpp - exposed the card rarity info on the alternate render cards to the translation engine. Also switched the color of said info to white on green and blue cards, imho they are much easier to read now.
- GameStateDeckViewer.cpp - exposed the term "Collection" (shown under the scrollbar) to the translation engine.
- GuiPhaseBar.cpp - exposed the strings denoting "your turn", "opponent's turn", "you play", "opponent plays", to the translation engine.
- SimplePad.cpp - exposed the special keys ("Spacebar", "Confirm" etc.) to the translation engine. Had to increase the keypad width to make room for "Abbrechen" (Cancel). I couldn't translate it differently because there's also a *spell* called cancel, and to have a different translation in SimplePad, I would have had to change the official German name of the Cancel spell, which wasn't an option.
- MTGAbility.cpp - exposed the words from which the text of mana-producing abilities is constructed to the translation engine. Please review this one and suggest a better solution - the one I chose is somewhat awkward. The translation works, but when the whole translated sentence is constructed and gets returned, the calling procedure tries to translate it again (all other ability descriptions work this way, translation takes place *after* the string has been returned). However, for mana producing abilities this doesn't work, since the costructed string can take an infinite number of diffeent forms, depending on the mana produced, and we can't translate that. Hence I chose to translate the individual words during construction, with the described side effect that the engine now tries to translate them again later in the process (and the sentence ends up in missing.txt).
- Also, cheat mode menu items now aren't denoted by the ugly "(cheat)" appended to them, instead they are enclosed by asterisks. Uses less space.
* 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 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
-print phase name on the screen. In the middle-term I'd like this zone to be some scrolling text: it will usually show the phase name, but after some inactivity from the player, it would start scrolling and show help messages
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.
* New interface.
* This breaks a lot of things. It is not feature-equivalent. It
probably doesn't compile under windows and doesn't work on PSP.
* Damage is not resolved any more. This will have to be fixed.
* Blockers can't be ordered any more. This will have to be fixed.
* A lot of new art is included.
* Add the rolling phasebar.
* This is a preview version. It shares most of the code with the definitive
version, but when the real code is checked in, this will be deleted.
