fgsfdsfgs / perfect_dark

work in progress port of n64decomp/perfect_dark to modern platforms
MIT License
1.17k stars 70 forks source link

Request: ARM64 support #464

Open FrostKnight opened 2 months ago

FrostKnight commented 2 months ago

I know of a few system on chip devices that could handle this.

Rk3588 would be especially good, but I imagine there are others that could as well.

There is a device called mnt reform and one called pocket mnt reform. I bet they could run this regardless of which processor is being used, if ARM64 bit support could be added.

And yes i know you say 32 bit libraries are needed, but I recall hearing that ARM64 works differently. It has 32 bit support in it already regardless.

If you or anyone can tell me to the contrary, let me know though.

I will be getting one of those in less than 2 months so I could test if you desired me to. :)

fgsfdsfgs commented 2 months ago

You should already be able to build the game for ARMv7a and possibly run it on an ARM64 device, depending on the software that's on it. Native builds require 64-bit support, like I explained in the other issue.

megatog615 commented 2 months ago

Do you have instructions for compiling for arm 32-bit say for example on a raspberry pi 4?

fgsfdsfgs commented 2 months ago

No, I've never tried it. Should work the same as for other 32-bit Linux platforms.

megatog615 commented 2 months ago

First, should this be a new bug?

In any case, I tried setting HOST_PLATFORM to armv7a, and it dies on the first file with this:

$ make -f Makefile.port HOST_PLATFORM=armv7a TOOLCHAIN=arm-linux-gnueabihf-
Host platform: armv7a
Target platform: armv7a
cc -c -std=c11 -DVERSION=2 -DVERSION_HASH=\"b523b1e07\" -DVERSION_TARGET=\"armv7a\" -DVERSION_ROMID=\"ntsc-final\" -DVERSION_BRANCH=\"port\" -DMATCHING=0 -DPAL=0 -DPIRACYCHECKS=0 -DROM_SIZE=32 -D_LANGUAGE_C=1 -DAVOID_UB=1 -I include -I include/PR -I src/include -I src/generated/ntsc-final -I src/lib/ultra/audio -I port/include -I/usr/include/SDL2  -g -fno-inline-functions -fno-strict-aliasing -funsigned-char -fwrapv -Wall -Wno-address -Wno-int-in-bool-context -Wno-misleading-indentation -Wno-missing-braces -Wno-multichar -Wno-tautological-compare -Wno-unused-but-set-variable -Wno-unused-value -Wno-unused-variable -Wno-format-truncation -Wno-pointer-sign -Og -o build/ntsc-final-port/src/game/mplayer/setup.o src/game/mplayer/setup.c
In file included from src/include/types.h:12,
                 from src/include/data.h:5,
                 from src/include/game/camdraw.h:4,
                 from src/game/mplayer/setup.c:3:
src/include/platform.h:34:10: error: #error "64-bit platforms are currently not supported."
   34 |         #error "64-bit platforms are currently not supported."
      |          ^~~~~

I have binutils-arm-linux-gnueabihf and gcc-arm-linux-gnueabihf installed. It seems that even if I force TOOLCHAIN on the command line it still builds with the 'cc' command which is incorrect.

megatog615 commented 2 months ago

Ah, forcing CC and CXX to arm-linux-gnueabihf-gcc and arm-linux-gnueabihf-g++ respectively seems to get further. I guess TOOLCHAIN isn't being set correctly in the Makefile.

megatog615 commented 2 months ago

I managed to cross-compile a working pd.exe for raspberry pi.

You'll need to get the armhf sources for SDL2. I did it by enabling the armhf architecture with dpkg, apt updateing, and installing libsdl2-dev:armhf. You'll also need gcc-arm-linux-gnueabihf and g++-arm-linux-gnueabihf. apt install libsdl2-dev:armhf gcc-arm-linux-gnueabihf g++-arm-linux-gnueabihf

This unholy abomination of a make string put it together: make -f Makefile.port HOST_PLATFORM=armv7a CC="arm-linux-gnueabihf-gcc -I/usr/include/arm-linux-gnueabihf/" CXX=arm-linux-gnueabihf-g++

You have to add -I/usr/include/arm-linux-gnueabihf/ in the CC line so it doesn't clobber the existing cflags, or at least that's how I got it to work. It is by no means the correct way to do it, but it works. CXX doesn't seem to need to know where SDL is.

EDIT: The same make command works on the raspberry pi itself, so if you want to avoid cross-compiling you can.

fgsfdsfgs commented 2 months ago

Nice. You could probably use TARGET_PLATFORM instead of HOST_PLATFORM though. In fact something like make -f Makefile.port TARGET_PLATFORM=arm-linux should probably work out of the box without adding any extra arguments.

megatog615 commented 2 months ago

Just tested that. It does not work on aarch64 host(Raspberry Pi OS 64-bit on RPi4 [technically a CM4]). For some reason the Makefile.port is not switching cc to the correct toolchain. It just uses 'cc' (and I assume c++ as well, but it didn't get that far). I guess it's not detecting arm/aarch correctly.

I also wanted to report that in the build that I managed to create successfully, music is extremely crackly and adjusting the BufferSize up reduces the crackling but does not eliminate it entirely, trading crackling for timing inaccuracy. It is similar to #262.

megatog615 commented 1 month ago

I would like to add that, like sm64pc/sm64ex#567, audio crackling is fixed by using SDL_AUDIODRIVER=alsa.

fgsfdsfgs commented 1 month ago

The Makefile defaults to host toolchain. You need to pass TARGET_PLATFORM=arm-linux. If that doesn't work, you might have to pass overrides for TOOLCHAIN or CC/CXX. EDIT: Didn't notice that I already explained all of this above. You might need to unset CC and CXX, so something like make -f Makefile.port TARGET_PLATFORM=arm-linux CC= CXX=