Dungeon Master / Chaos Strikes Back

[mlvj]

I am working on a Nokia 770 port of the linux port of the windows remake of the Atari/Amiga FTL game Dungeon Master / Chaos Strikes Back.

Speed is just fine, and the only input is via a mouse, so input is perfect too.

Currently stuck (and have been for a few months) on some display problem. Graphics show beautifully on the scratchbox, but are slightly messed up (enough to make it not worth playing) on the 770 itself. Probably something to do with endianism. Or something.

I'm working with the original developer to resolve this.

If I get this final thing going, is anybody interested in this - in which case I'll invest the time to create debs - otherwise I'll just keep it as binaries!

[rattis]

I am working on a Nokia 770 port of the linux port of the windows remake of the Atari/Amiga FTL game Dungeon Master / Chaos Strikes Back.
...
If I get this final thing going, is anybody interested in this - in which case I'll invest the time to create debs - otherwise I'll just keep it as binaries!

Playing Dungeon Master in meetings on my "PDA". Oh yeah.

[Hedgecore]

Coming from a guy who spent WAY too many hours playing Eye of the Beholder I and II, I look forward to this!

[runestone]

Cool indeed, that was the first game that I really got into. Got it for birthday when I went 14. I remember it had an "unbreakable" copy protection when released, I guess someone got around that ;) Dont remember really what it was, a laserhole in the floppydisc itself or something, anyone?

[Serge]

Currently stuck (and have been for a few months) on some display problem. Graphics show beautifully on the scratchbox, but are slightly messed up (enough to make it not worth playing) on the 770 itself. Probably something to do with endianism. Or something.
Probably that's alignment problem. ARM cpu requires all the memory access operations to be aligned (32-bit memory accesses aligned at 4-byte boundary, 16-bit accesses aligned at 2-byte boundary respectively). I already encountered such problems when porting UFO2000. By the way, qemu does not emulate such alignment behaviour.

If you provide a link to that project sources and some other information (library dependencies), I may have a quick look at it.

[rattis]

Coming from a guy who spent WAY too many hours playing Eye of the Beholder I and II, I look forward to this!

I spent way too many hours playing the original dungeon master on the atari 800.

[mlvj]

serge - here is the original link
http://debian.frodo.looijaard.name/csb/
When building under 2005 lots of probs because gcc did not respect packed directive. Had to put loads of attribute packeds in.
Got rid of all that for 2006.
You need to change sdl to use 16 bit mode, and I commented out sound too. And I built without hermes or libdb3.

Let me know how you get on!

[tabletfan]

I spent many nights on my Atari 1024ST playing these 2 games, and would be interested in the debs. 8-)

[cojeeper]

I wish Carrier Command would get released to public. That was one of the first Atari "computer" games that I couldn't get enough of with its "3D" graphics. But, DK would definitely be a welcome edition to my 770.

[rachid]

yeah, the old days :) i loved that games. Now I am playing Titan Quest, but i am sure, i had more fun with chaos strikes back...

[mlvj]

Hi Serge,

If you tell me the compiler directives to force stuff to be aligned, I'll try adding them in to (hopefully) the appropriate places.

Thanks!

[Serge]

If you tell me the compiler directives to force stuff to be aligned, I'll try adding them in to (hopefully) the appropriate places.

All the stuff should be already properly aligned by the compiler. But you can get into a trouble if using pointers conversion though, such as '*(int *)(buffer + 1)' in the example below. Modern compilers can warn about suspicious pointers conversion with -Wall option. Also beware of packed structs on ARM, there are two pitfalls: first is the alignment of data members, the second is the size of struct itself.

Here is the example of code you can experiment with to see these pitfalls:


#include <stdio.h>
#include <stdlib.h>
#include <stddef.h>

#pragma pack(1)
typedef struct s
{
char x;
int y;
} S;
#pragma pack()

int main()
{
int i;
char *buffer = (char *)malloc(16);
for (i = 0; i < 16; i++) buffer[i] = i;

printf("reading unaligned value from the buffer at offset 1: %08X\n",
*(int *)(buffer + 1));
printf("offsetof(S, y)=%d\n", offsetof(S, y));
printf("sizeof(S)=%d\n", sizeof(S));

free(buffer);
return 0;
}


On x86 it prints:

reading unaligned value from the buffer at offset 1: 04030201
offsetof(S, y)=1
sizeof(S)=5


On arm (and also when run with qemu) the results will be different.

[mlvj]

Problem is - the whole programme that I'm porting very much depends on tight structure packing - so have to have pack(1) most of the time.

I'll see if adding pack() at strategic places helps.

[mlvj]

hmm... no luck with pack(4). I have to say - I AM a bit rusty with the old c and pointers malarky. I have some fuzzy thinking in my brain after a long day's work and drive. And kids keeping me awake at night! Enough excuses.

Right, looking at a suspicious bit of code now. Here we go:

i8 *STScreen;
ui16 *scr = (ui16*) (STScreen + 160*y0 + LineStart);

/* Read the four ST planes. */
ui16 _one = *(scr++); ui16 four = GUINT16_FROM_BE(_one);
ui16 _two = *(scr++); ui16 three = GUINT16_FROM_BE(_two);
ui16 _three=*(scr++); ui16 two = GUINT16_FROM_BE(_three);
ui16 _four= *(scr++); ui16 one = GUINT16_FROM_BE(_four);

So... do you reckon that *(scr++) is behaving differently on the arm box than on the i86? e.g. *(scr++) is jumping too many or too few bytes forward I guess.

If so, could you recommend a replacement?

[mlvj]

hmm ok so using gdb on that portion of code shows scr incrementing by two bytes each line. So I guess that bit is ok at least.

Time to get a debug build on the local box and step through that at same time as on 770

[mlvj]

Got to what appears to be the critical line with a difference between i86 and 770.

And yes it is a pointer operation.

Time to figure out that it's definitely that, then fix it.

By the way, sound doesn't work at the moment, but the main thing would be to get the main functionality going.

I reckon.

[mlvj]

Right nearly there.

The problem seems to be that a variable:

char somedata [] = {
0x00. 0x01. etc };

...is not aligned on a four byte boundary.

I've tried sticking

#pragma pack(4)

in front of the line, but the thing still doesn't align.

I don't want to stick padding bytes there (nasty idea).

Anyone suggest the right approach, given that I'm porting and I don't want to change the code that assumes it's aligned on a four byte boundary?

Thanks!

[Serge]

char __attribute__ ((aligned(4))) somedata [] = {
0x00. 0x01. etc };

[mlvj]

This is the answer:

char somedata [] __attribute__((aligned (4))) = {
.......
};

Anyone want the raw binaries, or wait for debs (which may be a little while!)

[rattis]

This is the answer:

char somedata [] __attribute__((aligned (4))) = {
.......
};

Anyone want the raw binaries, or wait for debs (which may be a little while!)

hmm... I think I'll wait for the deb. While I want to play this game, I don't want to be the first person on the beta block.

[Serge]

This is the answer:
char somedata [] __attribute__((aligned (4))) = {
.......
};

Hmm, now I'm curious, is the code with different attribute placement wrong (if that's the case, I'll have to look through my code fixing it)? Could you post a testcase showing the problem?

[mlvj]

Hi Serge,

For some reason when I refreshed, I didn't see your answer post!

I located the way I did it using good old google (and lots of it).

Probably both positionings work, if yours works. I stuck mine according to the instructions on the page from where I copied it.

The port still has problems though - that was just the second hurdle. It segfaults on the 770 where it doesn't in scratchbox, and there are some user interface issues - the click of the stylus causes a click in the last position the mouse pointer was, and some things expect a right mouse click.

[Serge]

For some reason when I refreshed, I didn't see your answer post!

I located the way I did it using good old google (and lots of it).

Probably both positionings work, if yours works. I stuck mine according to the instructions on the page from where I copied it.
OK, I understand now, just your previous post sounded like the other positioning is wrong, so I got worried :)

Well, I actually prefer searching google first and posting questions in forums only if the search did not reveal anything useful, but nevermind ;)

The port still has problems though - that was just the second hurdle. It segfaults on the 770 where it doesn't in scratchbox, and there are some user interface issues - the click of the stylus causes a click in the last position the mouse pointer was, and some things expect a right mouse click.
The segfault is most likely caused by a similar alignment issue. You can try adding lots of guard assert checks to the code verifying pointers alignment and structure packing somewhere near the code that fails.

Anyway, congratulations on your progress so far, now you should be able to eventually hunt down all these bugs. I know that as I was stuck with a similar problem and spent some time figuring out these arm architecture specific tips and tricks. By the way, probably it would be a good idea to make a page at maemo wiki with x86 -> arm porting guide as some people may have the same difficulties but are too shy to ask for help in the forum :)

[mlvj]

I take your points.

I think I'm getting old!

Spending an hour or so coding each night (after a full day's work) has left me shattered, so I skipped it yesterday.

- good idea about the FAQ on Maemo wiki. When I get a chance I'll put some words in.

- and I've created a maemo garage project for this, so other people will be able to upload stuff.

I got csb working as far as loading, saving, playing whole first level pretty much. Segfaults when you go downstairs.

So my current tasks are:

- sort the segfaults as I find them
- package as an armel debian
- get sound working
- do a wiki entry

[quicksilver524]

is this game functional?