-added an explanation to why there is a special Jaguar download (people appears to download it even when they should download the other one)
-removed the long outdated README_if_game_crashed_on_OSX.txt
if detected, WITH_ICONV will be defined in the C code
WITH_ICONV is also added to Makefile.config
OSX do not use this flag setting in Makefile.config, as it is set at compile time based on target OS version
the actual C code is not changed as the current iconv code is hardcoded for OSX and would break if any other OS got iconv
This detection system is by request of Darkvater
it now uses REV instead of RELEASE, which means RELEASE is not needed to be set manaully anymore
it also automatically adds "-jaguar" when making a build aimed at OSX 10.2 (codenamed jaguar)
Instead of compiling a binary for each arch and then join them in the end, each .o file is now compiled as a fat file
This means that the makefile will not call itself to make a binary for each target and we don't have to make clean between each build
it also means that if one file changed, we don't have to recompile all files
Another benefit is since it's handled at .o level and though LDFLAGS, no special code is needed if we decide to compile more binaries (like a lot of stuff used to happen at post linking)
We also needs much less flags to set up, so it should be even easier to get to work out of the box now
The tradeoff in doing so is that now the binary needs at least OSX 10.3.9 to execute
To deal with this issue, the JAGUAR flag can be used to compile for older OSes. We will release a binary for old OSes at next release to see if anybody even downloads it (not that many people use OSX 10.2 anymore)
GPMI will not work on 10.2 anyway so we will cut support for it some day anyway
It also adds a new error window, which can be used just like assert, but it is also active when asserts are turned off
This is useful for places where it's really important to check even if assert is turned off. It's not used in the code yet
the package is long gone and people don't read a doc about a missing package when they don't expect to find one
the doc is called install even though it's not a real install and have nothing to do with make install. People just read it the first time they see it when it's called install ;)
G4 have no problems using G3 code while G5 can, but really benefit from getting their own optimised code (Apple: G5 is not just a fast G4)
Also changed FAT_BINARY to UNIVERSAL_BINARY since Apple removed most (all?) references to fat binaries on their homepage two days after I added FAT_BINARY
This increases the execution speed a lot since GCC can't detect the OTTD macro as an endian conversion
while Apple's code uses the instruction to convert endian instead of a series of instructions to produce the same result
Since we don't have that many endian conversions in the game, overall performance should not increase noteworthy
you can still use SDL drivers if you like and you have to run "make upgradeconf" to start using the cocoa drivers (or manually write WITH_COCOA:=1)
since SDL breaks the cocoa drivers, you can't compile with both SDL and cocoa support
Using cocoa drivers makes it easier to make universal binaries and it solves:
-FS#18 [OSX] SDL is weird in universal binaries
-FS#2 [OSX] lazy pointer crash on exit
-FS#10 [OSX] linking error when linking statically to SDL 1.2.8 (needless to explain this, but it means it should be able to compile statically with the default settings now)
-[ 1215073 ] Switching to large size out of fullscreen crashes
Using SDL drivers will still have those issues though
now PPC code is always compiled before x86 code
strgen and lng files are only compiled once, which results in shorter building time
the makefile now assigns default values to undefined values so much less needs to be set up
the code is now easier to maintain
it needs both PPC and x86 libs to compile
due to this fact, compilation with libPNG or SDL is not tested (dedicated servers only)
only PPC part is tested as I don't have x86 OSX
This is not a fix for the issues with static linking, more like a workaround. Static linking still got issues
Apple recommends to use dynamic linking anyway, so I guess this doesn't matter much
