This program is not (yet) prepared for big endian CPUs

[pkubaj]

I'm trying to compile this program on FreeBSD/powerpc64, but I'm getting: types.h:54:2: error: #error This program is not (yet) prepared for big endian CPUs, please contact the author.

[NagyD]

Comment out this #error line and see if the game compiles and runs correctly.

One area where I'm expecting problems is the handling of DAT files, because they contain data in little-endian byte order, and they are read by code that assumes that the CPU is also little-endian. As you can see here, SDLPoP uses DAT files for sounds, music, and guards.

To solve the problems, values read from DAT files must be passed through SDL_SwapLE32 or SDL_SwapLE16 before using them.

@Falcury might be able to help.

[pkubaj]

Yes, it builds, but I don't have yet big-endian desktop machine, so I can't check whether it actually works.

[NagyD]

but I don't have yet big-endian desktop machine,

I'm confused: You wrote that you are compiling on powerpc64, which is big-endian! Or are you just (cross-)compiling for powerpc64, and not on it?

[pkubaj]

I am compiling natively, but this is not my desktop, to which I have local access.

This is a (native powerpc64) build host, to which I have only remote access via SSH.

[NagyD]

Ah, now I understand. But why are you compiling for a platform that you don't have?

[pkubaj]

Ah, now I understand. But why are you compiling for a platform that you don't have?

1. I am bulk building FreeBSD ports for powerpc64 to improve the support for powerpc64 in ports tree (I want to get a POWER9 machine at some point).
2. With sdlpop it's a coincidence, but I'm also FreeBSD's maintainer for this software.

[pkubaj]

I have a Talos II machine running FreeBSD as my desktop. sdlpop segfaults when starting. Here's a backtrace:

(gdb) bt
#0  0x00000000100310bc in load_font_character_offsets (data=0x100727f0 <hc_small_font_data>) at /tmp/usr/ports/games/sdlpop/work/SDLPoP-1.19/src/seg009.c:1020
#1  0x0000000010031204 in load_font_from_data (data=0x100727f0 <hc_small_font_data>) at /tmp/usr/ports/games/sdlpop/work/SDLPoP-1.19/src/seg009.c:1036
#2  0x0000000010031480 in load_font () at /tmp/usr/ports/games/sdlpop/work/SDLPoP-1.19/src/seg009.c:1073
#3  0x00000000100372c8 in set_gr_mode (grmode=5 '\005') at /tmp/usr/ports/games/sdlpop/work/SDLPoP-1.19/src/seg009.c:2379
#4  0x000000001000aa10 in parse_grmode () at /tmp/usr/ports/games/sdlpop/work/SDLPoP-1.19/src/seg000.c:1599
#5  0x0000000010004298 in pop_main () at /tmp/usr/ports/games/sdlpop/work/SDLPoP-1.19/src/seg000.c:90
#6  0x000000001000400c in main (argc=1, argv=0x3fffffffffffdb40) at /tmp/usr/ports/games/sdlpop/work/SDLPoP-1.19/src/main.c:27

[NagyD]

I've made an attempt to make SDLPoP work on big-endian CPUs, on a new branch called big-endian.

I say attempt, because I don't have access to any system with a big-endian CPU.

Could you please test it?

[Falcury]

I tried to get SDLPoP to compile and run on a Mac mini G4. After a lot of trial and error (mostly, getting it to compile at all on older Mac OS X versions), I got it to work. The colors and the sound are way off, though. I guess there are endianness bugs in the code related to color palettes and sound resampling.

[NagyD]

I tried to get SDLPoP to compile and run on a Mac mini G4. After a lot of trial and error (mostly, getting it to compile at all on older Mac OS X versions), I got it to work.

Hey, this sounds great!

The colors and the sound are way off, though. I guess there are endianness bugs in the code related to color palettes and sound resampling.

On your screenshot I see that the blue component of colors is always 0xFF, except in the black background.

Could you please push the source to a new branch in your repo so I can try to look into it? By the way, did you use my big-endian branch as basis?

Related: I've found another big-endian branch, by @thrimbor: https://github.com/thrimbor/SDLPoP/tree/big_endian

[thrimbor]

Hey,

nice to see someone working on this :) As you can see, the branch where I worked on it myself is a huge mess - I really just poked at stuff without having any understanding of the sourcecode. But while I didn't get the game to fully work, I at least managed to make it look correctly. The most relevant commit is probably this one https://github.com/thrimbor/SDLPoP/commit/eb0ffe70a65ea3b791e414f1d5a65318d38c0032, which fixed the colors for me (before/after screenshots below).

Screenshots were made on Debian on my Mac Mini G4. Feel free to reuse my changes if they're useful to you.

/edit: Another screenshot to demonstrate the fixed colors. The prince is invisible in this one because he fell through the floor.

[Falcury]

Basically, I combined the changes from this branch with the changes from @NagyD's big-endian branch.

The git history got a bit messy in the process. I will try to clean things up and upload the branch when I get back home, next weekend.

I had to use an older version of SDL2 version (2.0.3, which is the version that tigerbrew offers). It is possible that some of the problems could also be related to that.

[thrimbor]

@NagyD Cherry-picking the top commit from by branch onto yours fixes the gameplay issues I had and makes the game look correct (apart from the screen flashing blue instead of red when you get hit). Didn't test sound though.

[Falcury]

I rebased my mac_app branch (onto the latest commit on master) and added some extra tweaks to allow it to compile on the Mac mini G4 (specifically: https://github.com/Falcury/SDLPoP/commit/6a330c279c560222e36a75e9d8c63f71cfe31493 and https://github.com/Falcury/SDLPoP/commit/ab4050c6a380413c6649e0fc7954d7fcccc20f94). Then, I merged the big-endian branch.

See: https://github.com/Falcury/SDLPoP/commits/mac_app_big_endian

Indeed, it looks like all calls to SDL_CreateRGBSurface() need to be checked for endianness issues. I think I fixed most of these here: https://github.com/Falcury/SDLPoP/commit/a5fbdad97edc3e438e7b862087ac7ed657c4d073

The game looks and plays fine :)

Issues:

• Sound is now working OK (no longer need to revert to 8-bit audio samples on SDL < 2.0.4, because the SDL routines for resampling are no longer relied on). However, the MIDI music crackles and plays too slowly.
• Flashes are the wrong color (already mentioned by @thrimbor)

Savestates and replays work fine, but they probably can't be exchanged between big endian and little endian systems.

Edit: attached build SDLPoP_1.19_Mac10.4_PPC.zip

[pkubaj]

Would it be possible to merge it to official SDLPoP repo?

[Link4Electronics]

Hello, thanks to @thrimbor changes I could make it run on a PowerMac G5 with Linux PPC64.

The only problem is the flashing screen when get the sword or get hit that flashes wrong color (a blue color instead of yellow), and the pause menu shows too the wrong RGB channel colors.