* Fix linux32 compilation.
* Wagic+JGE are now expected to compile on any unix that
has an X and an OpenGL library. If fmod is correctly
installed it will use it, else there won't be any sound.
* 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).
I'll upload the changes for the OptionItem code in a bit-- I'm a little concerned with that side of things, as I think I recall the reason for using GetButtonClick had something to do with what point in the process the game "eats" the button press... OptionItem stuff relies a lot on button presses falling through to other UI items.
* Fix another set of 64-bits related problems.
* The code is now expected to compile on linux-64bits, but as I
can't test, I can't be positive about it really compiling,
much less working.
* Fixes for compilation on 64-bit architectures :
string position-returning functions return size_t, not uint.
Fix that.
* Fixes warnings with new gcc about non-fixed string AND no arguments.
NOTE : 64-bit architectures still do not compile. There are 2 different places
where printf is used with a specifier that is not large enough on 64-bit because
size_t is now a ulong and not a uint. The solution on GNU systems is the %zu
specifier, but as I'm not sure it is supported on windows I don't want to
introduce a huge hard-to-notice bug, so I'll do it at a time when I got a
windowser to back me up.
- fix for issue 301 (creatures go to graveyard)
- This adds an important change to "movedTo", which now accepts a "full" target description in both "from" and "movedTo". The point is that a card does not move to "creature|graveyard" from "battlefield" but moves from "creature|battlefield" to "graveyard".
* Fix a bug where the closest card to the old coordinates of a no more
inplay card would be chosen regardless of whether it complies with the
user's request.
wagic.jeck
jean.chalard
wagic.the.homebrew@gmail.com
d32.wagic