Quote from forum "General OpenTTD", "topic OpenTTD gone mobile!":
blakeyez wrote:
I, along with my friend, have been experimenting with getting OpenTTD running on the Sharp Zaurus SL-C750 pda. It's a japanese-only model that runs linux
...
The other major issue is that the sprites aren't all being loaded correctly. For example, 2 of the 4 train depot graphics are slightly messed up, and in some cases the train comes out of the side of the depot instead of the entrance
It does crash occaisionally as well, but it all seems to trace back to incorrectly loading the sprites.
I'm a bit sorry, I did not check out all forums about OpenTTD before doing what I did. I could have joined forces with you ...
Anyway, above I have posted an IPK installer of version 0.3.2.1 for the Zaurus SL-C760 (should run on the 750 as well). So far, it seems it's running without hickups for quite a while (did'nt test run for very long).
Nearly all of the porting problems are caused by alignment issues between x86 and ARM. The code for extracting the right sprites is heavily byte/byte pointer related. Ints and Longs are often regained in the code from byte pointers by doing this:
If the data you access is accidentially not aligned to 4 byte words, the ARM will return somewhat "rotated" data, thus screwing for example sprite IDs.
So if you run into problems it's a bit more secure to use
Code: Select all
(sbp[0] + (sbp[1] << 8)) + (sbp[2] << 16)) + (sbp[3] << 24))
to explicitly put together your uint32 (or uint16) from bytes (sbp = some_byte_pointer).
The other major problem is alignment related as well. The access to
structs with mixed byte/int/long elements may fail because the arm compiler works with "padding", filling up bytes silently to the next word boundary because memory access is optimized to read whole words.
If you access these structs bytewise you again get in trouble with the data you get back.
The solution/workaround in this case is to add a compiler attribute to the structure to prevent this padding from happening:
Code: Select all
struct {
uint16 element1;
byte element2;
uint32 element3
} __attribute__((packed)) MyStruct;
Luckily, there is already a nicer macro for this in OTTD so you just have to change the structs like this:
Code: Select all
struct {
uint16 element1;
byte element2;
uint32 element3
} GCC_PACK MyStruct;
These problems obviously affect string and sprite management the same.
I've really learned a lot during this port, it seems ...
(If somebody is interested about my SDL setup contact me personally and I'll put up the information in one of the other forums.)
