105 lines
4.2 KiB
Plaintext
105 lines
4.2 KiB
Plaintext
Porting Oolite
|
|
==============
|
|
|
|
Oolite is portable to any platform that supports SDL and GNUstep. It is
|
|
known to run on Linux, FreeBSD 5 and 6 and SGI IRIX. (The OS X version
|
|
is the 'canonical' version - Oolite appeared on Mac OS X first and was
|
|
later ported). It also runs under Windows.
|
|
|
|
Oolite doesn't care about the endian-ness of the architecture - so far,
|
|
it is known to have run on PowerPC, Intel/amd x86, amd x86_64 (and
|
|
presumably Intel's emt64 when it's available) and 64-bit MIPS.
|
|
|
|
Oolite uses the BSD strl* string functions. These aren't included in
|
|
GNU's libc, so make sure that src/BSDCompat files are included in your
|
|
build if you are using a libc that doesn't have the strl* functions.
|
|
|
|
Making binary packages for your platform
|
|
========================================
|
|
There is a tarball installer system. To generate a tarball installer
|
|
for your platform, run 'tools/mktarballs'. The result is deposited in
|
|
TarballPackages off the root of this repository.
|
|
|
|
There should be a directory 'deps/OPSYS-CPU-deps', where OPSYS is
|
|
the OS reported by 'uname' with no flags, and CPU is the result of
|
|
'uname -p' (for i686 etc. this is converted to x86). If you are making
|
|
a new dependency bundle for your platform, deps/OPSYS-CPU-deps should
|
|
contain the following:
|
|
|
|
In the root:
|
|
|
|
install A shell script that installs Oolite on the user's computer.
|
|
oolite.src A shell script fragment that is used to make the shell
|
|
script 'oolite' that runs the game.
|
|
oolite-update.src A shell script fragment that can rsync updates.
|
|
OoliteReadMe.pdf Brief players guide.
|
|
OoliteRS.pdf Players Reference Sheet.
|
|
README.TXT Readme for your platform.
|
|
|
|
Subdirectories:
|
|
oolite-deps
|
|
GNUstep A minimalist set of GNUstep run time files
|
|
lib Shared libraries that support the game
|
|
|
|
If your platform does not yet have this dependencies directory, you can
|
|
model yours on the Linux-deps directory. Most things will be the
|
|
same.
|
|
|
|
Issues you may encounter when building Oolite on a new platform
|
|
===============================================================
|
|
|
|
Symptom:
|
|
Altitude bar drawn right across the screen, time under the scanner
|
|
showing stupid value (it should be something like NNNNNNN:NN:NN:NN),
|
|
probably no rotating Cobra showing on startup (and no view out of the
|
|
window when you launch your ship)
|
|
|
|
Cause:
|
|
Bad maths.
|
|
floor(), part of the standard C math library, is returning funny values
|
|
or your int type is not at least 32 bits wide.
|
|
Make sure #include <math.h> is done in all applicable files; for Linux
|
|
this was put in oolite-linux.h which is included by every file.
|
|
|
|
Check that floor() returns a sensible value by writing a short program that
|
|
does:
|
|
|
|
int result;
|
|
double thing=180058016009.741669;
|
|
result=floor(thing / 86400.0);
|
|
printf("Result is %d and thing is %f\n", result, thing);
|
|
|
|
Result should equal 2084004. Try it including math.h and not including
|
|
math.h and note any differences. If it gives the right result with math.h
|
|
but the wrong result without, then you've not included math.h
|
|
|
|
In the case that your int type is only 16 bits, this will probably work:
|
|
#define int long
|
|
|
|
and put it in your equivalent of oolite-linux.h.
|
|
|
|
Additional info: see the manpage for floor().
|
|
|
|
TODO: Include an assertion on startup that causes the game to exit
|
|
immediately with an error message describing the problem if floor()
|
|
doesn't return the correct value. I'll only bother if this problem
|
|
keeps cropping up. An error message that can be reported is much
|
|
better than a vague description of these symptoms by some guy who
|
|
just wants to play the game.
|
|
--------------------------------------------------------------------------
|
|
|
|
Symptom: Floating point exceptions
|
|
|
|
Cause: Some rhs of / and % expressions are turning out to be zero (I
|
|
assume this isn't the case on OS X). In some instances, the simple
|
|
fix of doing an if(rhs_of_expression)... before the div or mod
|
|
operation is appropriate. It's probably best to look for the root
|
|
cause of why the rhs is zero in the first place to check that it's not
|
|
harmless and you're not going to hide a new problem or hide the root
|
|
cause by doing this test.
|
|
|
|
The location of the exception is easily found by doing 'make debug=yes'
|
|
and doing 'debugapp oolite.debug' and then looking at the line of code
|
|
it crashes in.
|
|
|