Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
pkubaj opened this issue Oct 15, 2018 · 15 comments
Open

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

pkubaj opened this issue Oct 15, 2018 · 15 comments

Comments

@pkubaj
Copy link

pkubaj commented Oct 15, 2018

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
Copy link
Owner

NagyD commented Oct 29, 2018

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
Copy link
Author

pkubaj commented Oct 30, 2018

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

@NagyD
Copy link
Owner

NagyD commented Nov 2, 2018

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
Copy link
Author

pkubaj commented Nov 2, 2018

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
Copy link
Owner

NagyD commented Nov 3, 2018

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

@pkubaj
Copy link
Author

pkubaj commented Nov 3, 2018

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
Copy link
Author

pkubaj commented May 22, 2019

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
Copy link
Owner

NagyD commented Jun 1, 2019

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
Copy link
Contributor

Falcury commented Aug 9, 2019

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.
SDLPoP_MacOS10 4_color_bug

@NagyD
Copy link
Owner

NagyD commented Aug 11, 2019

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
Copy link
Contributor

thrimbor commented Aug 11, 2019

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 thrimbor@eb0ffe7, which fixed the colors for me (before/after screenshots below).
image
image

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.
image

@Falcury
Copy link
Contributor

Falcury commented Aug 12, 2019

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
Copy link
Contributor

@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 added a commit to Falcury/SDLPoP that referenced this issue Aug 17, 2019
@Falcury
Copy link
Contributor

Falcury commented Aug 17, 2019

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: Falcury@6a330c2 and Falcury@ab4050c). 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: Falcury@a5fbdad

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

Falcury added a commit to Falcury/SDLPoP that referenced this issue Aug 17, 2019
@pkubaj
Copy link
Author

pkubaj commented Nov 9, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants