I originally wanted to create a Pocket Reform thread for this, but because all of the Reforms share the same SoCs I don’t really think there is a need for that.
So what I am really reporting on here is that the following games run without issue on the i.MX8MPlus:
Luftrauser (already reported)
Into the Breach (already reported)
Faster Than Light (already reported)
Stardew Valley
All of these are being launched (after some quick modification to the startup scripts) via Minigalaxy, which is a GoG frontend client.
I have a feeling that the RK3588 should see a lot more games added to this list.
I think instead of pocket vs classic vs next gaming we should breakout gaming based on SOC. Regardless of device you should get similar performance. One notable case I’ve had issues with is STALKER on rk3588 pocket. It seems unhappy and has weird issues if I try to play at non native resolutions and they pocket’s screen is higher res than the classic.
i can’t quite test this, but i do wonder if any of y’all are familiar with PortMaster? it’s a project that targets lower-powered linux gaming handhelds, and its git repository & documentation have a lot of useful starting points for getting many (mostly indie or older) games running on armhf/aarch64 & linux in general in contexts where the overhead of WINE/box64 or even X/wayland isn’t feasible or desirable.
some of the information is redundant for anyone familiar with gaming on linux in general, and the way the information is organized is sometimes frustrating, but the porting guides & scripts have been helpful to me in the past for getting more niche godot & gamemaker games without linux binaries (let alone binaries for arm) running natively on linux.
i plan on tinkering along these lines some after i get my pocket, but i figured i’d leave a note about it here just in case it’s helpful to anyone else in the meantime.
I got Fallout 1 up and running with no hassle at all using the portmaster build of fallout-ce.
The Fallout 1.sh wrapper script can be ignored as it is specific to handhelds.
I just copied the requisite files to the fallout1 directory and ran the fallout-ce binary directly. I had to make the copied files lower case and fallout-ce executable.
One thing I will note is that scaling in sway doesn’t play nice with full screen games. Text looks all weird and aliased with scaling set to 2. This was very noticeable in Exapunks. My solution was to set up key bindings to switch the scale between 1 and 2 quickly.
Has anyone tried RetroArch for emulation? If I use a MNT machine with the RG 3588, would it be capable of emulating up to the PS2? I would love to emulate the Nintendo Switch, but due to the lack of ARM support for Yuzu, Ryujinx, and CIA on ARM-based systems, I don’t think it’s possible at the moment.
Any comments or advice would be greatly appreciated! Honestly, I mainly play pokemon games.
Has anyone else started to have Luftrausers crash shortly after starting a game?
This is the error I am getting. It seems to come about 5 seconds after starting play:
[BOX64] Using emulated libFLAC.so.8
[BOX64] Using emulated libvorbisenc.so.2
[BOX64] Using native(wrapped) libz.so.1
[BOX64] Using native(wrapped) libpthread.so.0
[BOX64] Using emulated /usr/lib/box64-x86_64-linux-gnu/libstdc++.so.6
[BOX64] Using native(wrapped) libm.so.6
[BOX64] Using emulated /usr/lib/box64-x86_64-linux-gnu/libgcc_s.so.1
[BOX64] Using native(wrapped) libc.so.6
[BOX64] Using native(wrapped) ld-linux-x86-64.so.2
[BOX64] Using native(wrapped) libutil.so.1
[BOX64] Using native(wrapped) librt.so.1
[BOX64] Using native(wrapped) libbsd.so.0
entered main()[BOX64] Using native(wrapped) libXcursor.so.1
[BOX64] Using native(wrapped) libXfixes.so.3
[BOX64] Using native(wrapped) libXinerama.so.1
[BOX64] Using native(wrapped) libXi.so.6
[BOX64] Using native(wrapped) libXxf86vm.so.1
-7.63445s Mipmapping disabled
-8.61209s Mipmapping disabled -9.06492s Mipmapping disabled
-9.26126s Mipmapping disabled
-10.121s Mipmapping disabled
-10.1479s Mipmapping disabled
-10.1515s Mipmapping disabled
-10.156s Mipmapping disabled
-10.1614s Mipmapping disabled
-10.1713s Mipmapping disabled
-11.0608s No buffer scale given, defaulting to 1.
-15.8945s Component of type Camera is not expired.
./launch.sh: line 17: 14299 Killed ./luftrausers
This didn’t use to happen. Anyone have any clues on how to remedy this?
But what amazed me even more than that it’s possible to finish the game without any issues (not a single crash or glitch) was that the game does not even max out the processor. Not even close:
I want to play my favorite games on the Reform bad - namely Duke Nukem 3D, Quake1 and Quake2. I’ll have to see if I can get them working at some point.
FWIW, using the data in this thread, I’ve gotten my bpi-cm4 reform classic to play stardew valley from gog basically perfectly. I did not have much success getting steam to run (which I tried first, since I have more game there), but it’s probably possible, if not strictly “fun”. GOG was much more straightforward – fewer dependencies in general.
Well hot damn… I just intalled Yamagi Quake II from Flathub just about as easily, and it run remarkably well too
The one thing I notice however is that only sofware rendering works correctly. OpenGL crashes Duke Nukem 3D and it creates some weird streaks and “tremors” on the screen in Quake II.
As for Vulkan, it render well but it’s atrociously slow.
Software rendering not only renders perfectly, but it’s faster than OpenGL and Vulkan. Odd…
EDIT: and now Quake1 is installed too. Just like that All of my 3 favorite games run on the Reform, and quite a bit faster than on my slightly higher spec x86 HP laptop too, oddly enough.
If only the Reform could do Blender, it would do everything I need a laptop to do now!
I wonder if the rendering stuff is related to flatpak and how it’s accessing the DRI/DRM/GL layers? Is flatpak using containers?
ETA: I guess not strictly using containers, so they prefer calling them sandboxes. But it seems like even without containers, they’re using OCI and cgroups, so… either way, could see their sandboxing and process isolation models interfering with accessing kernel level stuff (ie flatpak apps are using a distinct /proc, not system /proc)
It’s interfacing just fine with the system, as evidenced by the fact that is renders and the games work. The problem is, with all versions of OpenGL, the rendering is all shades of terrible, and in the case of DN3D, eventually crashes the system.
I’m less than impressed by the Mali G610. It’s not very speedy, and the OpenGL implementation is basically unusable by all but one of the applications I’ve tried.
I decided to see if I could get a game without a linux port to function on the A311D reform classic. Alas, I seem to have run into a known issue with having aarch64 wine and armhf wine32 installed at the same time on debian.
Basic issue is that I keep getting this error:
wine: wineserver doesn't support the 014c architecture
Simply removing the armhf wine32 package allows wine to start up and do “stuff” (although it complains that you should install wine32), but then you can’t run 32-bit packages, which the games are. I’ll try the other way around. It sounds like this is addressed already in upstream, and just hasn’t been packaged for unstable yet.
ETA: fwiw, just having wine32:armhf also didn’t work, but in new and different ways (i got a weird tall unreadably thin dialog which vanished, replaced by a blank unclosable winedebug window which eventually ate all my memory and everything locked up.
All of my 3 favorite games run on the Reform, and quite a bit faster than on my slightly higher spec x86 HP laptop too, oddly enough.