PPSSPP for Pi

[arutema]

Well, the good news is I got it to build. The bad news is that it doesn't actually run, just gives the message "EGL Error: Unable to get display!" if run from the command line or "Unable to create EGL display." if run from an xterm.

EDIT: Some of this was wrong for the current Rasbian distro and PPSSPP version. See my updates post further down-thread for updated build instructions.

[arutema]

Well, I've gotten a little further by using USING_FBDEV and forcing it to link against /opt/vc/lib/libGLESv2.so instead of the default libGLES object.

Now it gets as far as

Quote:EGL ERROR: Unable to query for available configs.
Segmentation Fault

Help?

[arutema]

1.1.1 seems to compile on Pi with fewer hacks than previous versions.

Now up to

Quote:16:50:227 Core/Config.cpp:859 I[LOAD]: Loading controller config: /home/pi/.config/ppsspp/PSP/SYSTEM/controls.ini
16:50:227 Core/Config.cpp:864 E[LOAD]: Failed to read /home/pi/.config/ppsspp/PSP/SYSTEM/controls.ini. Setting controller config to default.
pure virtual method called
terminate called without an active exception
Pixels: 1680 x 1050
Virtual pixels: 1680 x 1050

in the startup process before terminating. From what digging i've been able to do, this may be related to not having any form of FFMPEG linked it. Trying to force it to link FFMPEG, and will share my CMakeLists.txt if tomorrow's session resolves that problem.

[arutema]

No luck.

I'm attaching my CMakeLists.txt. Can someone tell me if that's at fault, or the code itself?

Should I just give up and get a barebones x86_64 system for my emulator project?

[Sim_Piko]

iirc, when I was switching to rpi2, i had to block compile NEON/armv7 stuff
(i've read somewhere, some time ago that rpi2's cpu has/had(?) problems with NEON, or was it not compatible with it?, i dunno now, also, my old compile from rpi worked okay while i couldn't compile or run(segfault) rpi2 armv7 build)

so code-wise I had to comment out in CmakeLists.txt":
-armv7 detection

Code:

# Detect CPU from CMAKE configuration. Toolchains should set this up
if(CMAKE_SYSTEM_PROCESSOR)
    if(${CMAKE_SYSTEM_PROCESSOR} MATCHES "^arm")
        set(ARM ON)
#       if(${CMAKE_SYSTEM_PROCESSOR} MATCHES "^armv7")
#           set(ARMV7 ON)
#       endif()
    elseif(${CMAKE_SYSTEM_PROCESSOR} MATCHES "^x86" OR
        ${CMAKE_SYSTEM_PROCESSOR} MATCHES "^amd64" OR
        ${CMAKE_SYSTEM_PROCESSOR} MATCHES "i.86")
        set(X86 ON)
    elseif(${CMAKE_SYSTEM_PROCESSOR} MATCHES "^mips")
        set(MIPS ON)
    endif()
endif()

- and NEON-related stuff

Code:

set(CommonExtra)
if(ARM)
    set(CommonExtra ${CommonExtra}
        Common/ArmCPUDetect.cpp
        Common/ArmThunk.cpp)
#       Common/ColorConvNEON.cpp)

see if that'll fix anything. If not, I'll try to extract from CMakeCache.txt the values I've used.

[arutema]

(10-24-2015 05:51 PM)Sim_Piko Wrote:  iirc, when I was switching to rpi2, i had to block compile NEON/armv7 stuff
(i've read somewhere, some time ago that rpi2's cpu has/had(?) problems with NEON, or was it not compatible with it?, i dunno now, also, my old compile from rpi worked okay while i couldn't compile or run(segfault) rpi2 armv7 build)

so code-wise I had to comment out in CmakeLists.txt":
-armv7 detection

Code:

# Detect CPU from CMAKE configuration. Toolchains should set this up
if(CMAKE_SYSTEM_PROCESSOR)
    if(${CMAKE_SYSTEM_PROCESSOR} MATCHES "^arm")
        set(ARM ON)
#       if(${CMAKE_SYSTEM_PROCESSOR} MATCHES "^armv7")
#           set(ARMV7 ON)
#       endif()
    elseif(${CMAKE_SYSTEM_PROCESSOR} MATCHES "^x86" OR
        ${CMAKE_SYSTEM_PROCESSOR} MATCHES "^amd64" OR
        ${CMAKE_SYSTEM_PROCESSOR} MATCHES "i.86")
        set(X86 ON)
    elseif(${CMAKE_SYSTEM_PROCESSOR} MATCHES "^mips")
        set(MIPS ON)
    endif()
endif()

- and NEON-related stuff

Code:

set(CommonExtra)
if(ARM)
    set(CommonExtra ${CommonExtra}
        Common/ArmCPUDetect.cpp
        Common/ArmThunk.cpp)
#       Common/ColorConvNEON.cpp)

see if that'll fix anything. If not, I'll try to extract from CMakeCache.txt the values I've used.

EUREKA! That's got it booting. Having some problem setting up my controller though. Got to dig into that tonight, maybe just try a different controller.

[Sim_Piko]

It's probably because SDL/SDLjoystick.h has hard-coded button config (for xbox360 pad probably(it says that literally in comment above definitions):

Code:

#ifdef _WIN32
(config for windows)
#else
        SDLJoyButtonMap[0] = NKCODE_DPAD_UP;
        SDLJoyButtonMap[1] = NKCODE_DPAD_DOWN;
        SDLJoyButtonMap[2] = NKCODE_DPAD_LEFT;
        SDLJoyButtonMap[3] = NKCODE_DPAD_RIGHT;
        SDLJoyButtonMap[4] = NKCODE_BUTTON_10;
        SDLJoyButtonMap[5] = NKCODE_BUTTON_9;
        SDLJoyButtonMap[6] = NKCODE_BUTTON_5;
        SDLJoyButtonMap[7] = NKCODE_BUTTON_6;
        SDLJoyButtonMap[8] = NKCODE_BUTTON_7;
        SDLJoyButtonMap[9] = NKCODE_BUTTON_8;
        SDLJoyButtonMap[10] = NKCODE_BUTTON_SELECT;
        SDLJoyButtonMap[11] = NKCODE_BUTTON_2;
        SDLJoyButtonMap[12] = NKCODE_BUTTON_3;
        SDLJoyButtonMap[13] = NKCODE_BUTTON_4;
        SDLJoyButtonMap[14] = NKCODE_BUTTON_1;
        SDLJoyButtonMap[15] = NKCODE_BUTTON_11;

I had to 'fix' it to look like this:

Code:

#ifdef _WIN32
(config for windows, untouched)
#else
        SDLJoyButtonMap[0] = NKCODE_BUTTON_1;
        SDLJoyButtonMap[1] = NKCODE_BUTTON_2;
        SDLJoyButtonMap[2] = NKCODE_BUTTON_3;
        SDLJoyButtonMap[3] = NKCODE_BUTTON_4;
        SDLJoyButtonMap[4] = NKCODE_BUTTON_5;
        SDLJoyButtonMap[5] = NKCODE_BUTTON_6;
        SDLJoyButtonMap[6] = NKCODE_BUTTON_7;
        SDLJoyButtonMap[7] = NKCODE_BUTTON_8;
        SDLJoyButtonMap[8] = NKCODE_BUTTON_9;
        SDLJoyButtonMap[9] = NKCODE_BUTTON_10;
        SDLJoyButtonMap[10] = NKCODE_BUTTON_11;
        SDLJoyButtonMap[11] = NKCODE_BUTTON_12;
        SDLJoyButtonMap[12] = NKCODE_BUTTON_13;
        SDLJoyButtonMap[13] = NKCODE_BUTTON_14;
        SDLJoyButtonMap[14] = NKCODE_BUTTON_15;
        SDLJoyButtonMap[15] = NKCODE_BUTTON_16;

Don't know if that breaks some pad config, but at least fixed my usb gamepad.

[arutema]

Thanks, that got my gamepad mostly working. Now to figure out some weirdness with the keyboard. It seems as soon as I launch ppsspp, the keyboard stops responding, and doesn't start again until I send the bash process a SIGHUP over my handy SSH session.

[arutema]

Keyboard issues are partially fixed by installing libudev-dev and rebuilding SDL2 and PPSSPP. It recognizes the keyboard now, but the shell still won't respond to keyboard input after exiting PPSSPP.

[Sim_Piko]

Easiest workaround for that is pressing 'Alt + SysRq + R' (SysRq is usually on same key with PrintScreen )

Code-wise, at sdl2's video init, the keyboard is 'locked' so it can't spam all keypresses to shell (SDL_EVDEV_Init() function is probably doing that).
The 'unlock keyboard' function is hidden under SDL_EVDEV_Quit(), which is ran after executing SDL_VideoQuit() (to be specific, it's in "src/video/raspberry/SDL_rpivideo.c", under RPI_VideoQuit()).
That VideoQuit function is somehow not executed at ppsspp's exit, leaving keyboard in 'dead' state.
I remember i've tried to do something with it, but i can't remember or find any code changes i've made, either in ppsspp(and/or 'native') nor in sdl2 :/

[arutema]

Alright, update time with a new Raspberry Pi 3 on hand.

It builds with less tweaking, and runs at least some games decently. It is, however very particular about the build process and dependency order.

Here's my build instructions for those having trouble.

Code:

$ sudo apt-get install libudev-dev cmake libsdl1.2-dev

libudev-dev is required for keyboard and mouse
libsdl1.2-dev is required for sound
cmake is required to compile

Then you need to build SDL2 to fairly exact specifications. First get the source tarball from the SDL2 site.

Code:

$ tar xvzf SDL2-2.0.4.tar.gz
$ cd SDL2-2.0.4/
$ ./configure --prefix=/usr \
    --enable-sdl-dlopen \
    --disable-arts --disable-esd --disable-nas \
    --enable-alsa \
    --disable-pulseaudio \
    --disable-video-wayland \
    --without-x --disable-video-x11 --disable-x11-shared \
    --disable-video-x11-xcursor --disable-video-x11-xinerama \
    --disable-video-x11-xinput --disable-video-x11-xrandr \
    --disable-video-x11-scrnsaver --disable-video-x11-xshape \
    --disable-video-x11-vm --disable-video-opengl \
    --disable-video-directfb --disable-rpath \
    --enable-video-opengles --host=arm-raspberry-linux-gnueabihf
$ make -j4
$ sudo make install

Now you have the libraries PPSSPP needs built, next: git clone ppsspp into a local directory. cd into that directory and:

Code:

$ git submodule update --init
$ cd SDL
$ ./buildassets.sh
$ cd ..
$ cmake -DRASPBIAN=ON .

Now, to fix an issue with the keyboard locking up, edit ext/native/base/PCMain.cpp and comment out (add "//" before) the following lines near the end of the file:

Code:

#ifndef MOBILE_DEVICE
      exit(0);
#endif

finally, make -j4 and run.

Performance and compatibility reports in my next post.

[arutema]

Results so far:

BlazBlue: Calamity Trigger - playable.
Breath of Fire III - playable.
Castlevania: Dracula X Chronicles - playable.
Final Fantasy - playable, but world map can be very choppy. Missing some transparency effects in menus.
Final Fantasy II - FPS drops to unplayable levels on the world map. (Same thing as on my ARM tablet.)
Final Fantasy III - playable.
Final Fantasy IV - mostly playable. Severe FPS drop when the enemy death animation plays.
Final Fantasy Tactics: War of the Lions - Sound randomly drops out and textures glitch.
God of War: Chains of Olympus - unplayable slow framerate.
God of War: Ghost of Sparta - New game hangs after intro FMV.
Guilty Gear XX Accent Core Plus - too much in-match slowdown to be playable.
Legend of Heroes: Trails in the Sky (FC) - playable.
LittleBigPlanet - playable.
Megaman: Maverick Hunter X - playable as of latest GIT.
Megaman Powered Up - playable.
Prinny: Can I Really be the Hero? - playable.
Spectral Souls - playable.

Will edit this post as I test more of my collection.

[[Unknown]]

For stuttering: under Settings -> System, change "I/O timing method" to "Host (bugs, less lag)".

It may be a bit less compatible, but in many cases it should be better - when data loads slowly, games will typically show loading screens, rather than lag (as they would when a UMD is spinning up, etc.)

By the way, PPSSPP also supports reading ISOs via http:// range requests on wifi (for when your SD card is not big enough.) On Android, this is able to play videos smoothly etc. but for a good loading experience you need "Host" as above. If you run an Apache or similar server, you just need to run PPSSPP with a URL as the first argument.

Note: Maverick Hunter X requires you press a button after the video due to a bug right now, at least on other platforms.

-[Unknown]

[arutema]

(06-01-2016 02:39 AM)[Unknown] Wrote:  For stuttering: under Settings -> System, change "I/O timing method" to "Host (bugs, less lag)".

...

Note: Maverick Hunter X requires you press a button after the video due to a bug right now, at least on other platforms.

-[Unknown]

I'll try that change.

Maverick Hunter X doesn't seem to accept input on Pi to skip that screen. Which is strange since it accepts button presses just fine on Windows and Android there.

[arutema]

(06-01-2016 02:49 AM)arutema Wrote:  

(06-01-2016 02:39 AM)[Unknown] Wrote:  For stuttering: under Settings -> System, change "I/O timing method" to "Host (bugs, less lag)".

...

Note: Maverick Hunter X requires you press a button after the video due to a bug right now, at least on other platforms.

-[Unknown]

I'll try that change.

Maverick Hunter X doesn't seem to accept input on Pi to skip that screen. Which is strange since it accepts button presses just fine on Windows and Android there.

Changing the I/O timing didn't help. But I think these slowdowns are a system issue. Turns out I shouldn't use a cheap power supply and ignore undervoltage warnings.

More results tomorrow once I have a proper 5V 2.5A power supply to test with.