Box86 and Wine on RPi4

EvilCreamsicle

So as promised I went to try and get this set up, but I didn't even get far enough to try and launch the game.

I set it up using the emulator branch, updated to, I think 4.7.19, and installed the packages via the scripts in order as described in the ReadMe

EmulationStation launches, but when I try to select the new emulator to simply view the list (which would contain my one .conf file and the default Wine scripts that live in there) it crashes emulationstation.

Says something about making sure the CPU/GPU split is set right... I never changed it from default, but I think that's just a generic error message so I wanted to check if anyone else has seen this before I go messing with it. Doesn't do this when I select any other of the default emulators.

EvilCreamsicle

Update, plugged this in in my office and... the crashing didn't happen.

Then it occurred to me that the default resolution is 'monitor preferred resolution'... and my Pi was connected to a 75-inch 4k Samsung TV. That is probably why it got angry.

So, I can confirm that RPG Maker VX games run using this solution!

Don't have audio yet but I think that's me misconfiguring something. I'll update when I know if thats an issue or not.

EDIT: Doesn't launch every time... crashes sometimes. Logs show:

Box86 with Dynarec v0.2.3 8b887c7 built on Sep 23 2021 04:37:01
0058:err:ole:start_rpcss Failed to start RpcSs service
0060:fixme:mountmgr:harddisk_ioctl Unsupported ioctl 4d004 (device=4 access=3 func=401 method=0)
/home/pi/RetroPie/roms/wine/Wine Desktop.sh: line 86:  1165 Segmentation fault      setarch linux32 -L /opt/retropie/emulators/wine/bin/wine "${PROGRAM}" $OPTIONS
xinit: connection to X server lost

waiting for X server to shut down wm_set_cursor_visibility: visible using XCreateFontCursor
(II) Server terminated successfully (0). Closing log file.
code_text

EDIT 2:
This seems to have been all about resolution.
DMT mode 16 allows RPG Maker VX Ace games (well, mine anyway) to launch reliably in Wine via Config file, and be played with a standard gamepad.

EvilCreamsicle

This post is deleted!

George

@dodonpachi can you post the output of /dev/shm/runcommand.log? Maybe there is something in the output that could give us a hint.

Also, I wonder whether or not the game requires desktop mode. I don't think I've seen that actually happen, but maybe it's not good at setting its own resolution and is trying to depend on the resolution from the desktop.

- George

EvilCreamsicle

@george I've got it running now, but have run into issues where performance is reeeeally bad even though CPU is at 50% and memory still has ~2GB free. I'm suspecting something to do with GPU.

I don't know if you've tried doing this on a display that is requesting a huge 4K image, but I suspect it was just too big of an ask for the hardware or EmulationStation. Is the Wine logo you use a vector image? Because it was so enormous that it just looked like my screen had a red gradient, and it looked like the WINE emulator had a blank image (and would crash if you selected it).

George

@evilcreamsicle in general, when running games via Box86 and Wine on the Pi 4, I reduce the resolution quite a bit. For me that's ok because I'm playing early games that weren't designed for more than 1024x768 with a screen that doesn't have much higher resolution screen either. (I enjoy making handheld games or playing on my arcade cabinet that has a CRT).

But it also sounds like you're experiencing an issue with an EmulationStation theme. Is that correct? A picture of what you're experiencing could help. Are you using my modified Pixel theme? If so, I'll have to take a look at it. I believe that my images are just plain PNGs, but I know from past experience that PNGs can be compressed in a variety of ways for space and performance. I didn't look at the original PNGs in the theme for that, so it's possible that something happened when I exported the images as PNG. Let me know.

Thanks!

- George

EvilCreamsicle

@george when I manually set the resolution lower, it isn't an issue. I was only offering that as evidence that 4K could have been part of the problem. I'm not concerned about the theme weirdness right now though. I was using the default RetroPie theme.

The game I'm running is made in RPG Maker VX Ace, which was released in 2012 and really doesn't need a high resolution either. It's pixel art graphics, doesn't look like anything that wouldn't run on a super nintendo, so I'm struggling to figure out why some scenes seem to be so graphically demanding.

Not sure if this is a box/wine thing or if it is an RPG Maker thing.

retropi19

mth75
Hi there can you try the games Gorky17 and dune2000 ???
And is it possible to make scripts available for download for some games like age of empires 2
Blitzkriek,sudden strike etc.
I dont mean the scripts to download the games i mean to install, configure any nesessary things the games needs including the sh script in ports
So all have left to do for a user is to put the game folder in a specific location.

I'm asking coz i dont have a clue how to run this games once wine,mesa,box86 are installed
If you cannot do the scripts at least to tell me how to run for example age of empires 2 or sudden strike?? Or to put a small guide/example how to run games

And finally age of empires and other window games needs directx how do i install this with wine? Or its not necessary?
Thanks in advance

George

Thanks @evilcreamsicle,

You may want to file an issue with the RetroPie team regarding 4k support, especially with EmulationStation. Then again, it might be an issue with kernel level support for 4k.

Looks like the default carbon theme does use SVGs and it doesn't have any images for Wine or Box86. I don't know what the behavior of the theme is when that happens.

Performance with regards to screen resolution seems to be a combination of many things. Beyond the limitations of the Pi 4 itself, the Mesa driver version, whether or not the emulator takes advantage of the GPU or is CPU bound, or in the case of Box86 if the program takes advantage of the GPU. I've had to experiment a lot with some games in order to get good performance. I don't know off-hand if there's a way to determine if a game is taking advantage of the GPU or is using the CPU to generate graphics.

I appreciate all the work you're doing to get it working and posting about your findings. Thanks again,

- George

mmeoj

@ecto said in Box86 and Wine on RPi4:

I've also hit a wall with my latest game installs...

Resident Evil 1-3 and Dino Crisis: There are REbirth patches for those games which allow for higher resolutions and much more, but so far I've not seen any in-game graphics :(

Ultima 9 I thought taht such an old game would put up no fight, but I was wrong... :( I can't get any glide wrapper to work, and D3D mode is glitched (text overlays). :(

The Sims 1 or 2 was already hard to get running on my PC without a CD, but on my Retropie they simply refuded to work. :(

Diablo 2 with QoL patches are working phantastically on my PC, but I get a lot of rendering errors on Retropie. Vanilla D2 with widescreen patch was working well before (ddraw mode), so I would think this has to work, too. But I can't get either of the 3 (!)modes suggested in the QoL patch to work. Has cost me many hours so far ^_^;

Sid Meyers Alpha Centauri: Game starts, I can hear sound but there is ony a black screen. ;_; None of the suggested fixes have worked so far...

So all in all I'm very frustrated right now. Lots of Time, and no further running games...

EDIT

Diablo 2 with QoL patches works. I had to start over, probably some setting was wrong. After that it (almost) worked out of the box. Almost, because I had to change the renderer from its default (DX11, which works great on real Windows 10) to DirectDraw. I also tried glide, which looks cooler (as it has some quasi 3D rendering and working cinematics) but is much slower and has a lot of rendering errors (everyhing is in rainbow-colors until I change the resolution). I wish I could get Gl4ES to work as it seems to work for others without those rendering errors.

Please note:

That guy managed to launch The sims 1 on his ARM-based device in Wine using a special .EXE he mentioned about in his video.

Take a look at it.

hooperre

Has anyone had increased success getting things to run from an xserver from the menu? I've had varying success depending on the game (Papers, Please and AM2R 1.1 run from EmulationStation soundly).

Edit: I'd also be interested in reading more about xservers and launching them from the command line.

boolean

@george I'm not sure on what version of RetroPie you're on or which hardware you're using, but I've experienced no such thing on the RPi4. TiMidity never hangs and my Pi hasn't been restarted for over three months. TiMidity is pre-installed on RetroPie v4.7.1 but isn't configured as a service/daemon. You can execute "sudo apt-get -y install timidity-daemon" to accomplish that. By default it's configured to be started/stopped through script whenever you start an application (like DOSBox) that needs it. I've opted for installing the daemon instead and removed the start/stop commands from the scripts, but that's a personal choice.

mth75

@George

I've tried mesa 21.3.2, Box0.2.5 and Wine 7.0~rc2 and 6.23-devel. The combo's seem to work and indeed, somewhat more performance.

Regarding Wine, I installing the Bullseye bins, the Buster repro isn't updated anymore it seems.

All FYI.

mth75

@George

I'm still trying to use the Mesa/Vulkan combo to experiment with Directx11 games (Thimbleweed Park :-)), not successful at the moment.

Do you have any idea's?

I noticed these packages ...maybe they would enable an easy way to accomplish my goal

libvkd3d1_1.2~bullseye-1_i386.deb

ecto

@mth75 On the Box86 channel on discord, there is a whole thread about dxvk... but sadly it will probably never(?) work on rpi4. Here is some background information about the limitations..

retro-devil2

@George
Hello again so we just tried the one line installer we made with Supreme and you= method on newest rpi images . Install failed both time . Neither worked .

LivenCorpse

Hey, wanted to share my experience trying to install these scripts on a raspberry RPi3 (armv7l - OS version : 4.7.20). It seems most everyone was trying this on RPi4 but I hoped that on a RPi3 I could at least get Space Cadet - 3D Pinball working.

Basically I did everything instructed on https://github.com/GeorgeMcMullen/rp-box86wine down to the wine installation but then I started experiencing issues. All 3 modules were listed as installed but running any of the wine scripts (like winecfg) did nothing but kick you back to the splash-screen. A quick investigation found it to be a "Permission Denied" issue in logs.

Debugging eventually made me discover my box86 was corrupted.... how I discovered that is a bit winded but I want to share it in case anyone else experienced the same vague problems.

I thought chmoding /opt/retropie/ports/wine/bin would solve the issue but no configurations I tried (even 7777) did anything. Eventually I reasoned something corrupted during the installation phase. After uninstalling wine and box86 to reinstall them I found that box86 actually failed even though it was listed as "installed" in pi setup packages. Some of the issues were because folder liks ...build/box86 or ...build/LICENSE did not exist. Making those folders got the installation further along but then when it reached a dynarec_arm_66.c.o file (around 31% built) it kept experiencing a "fatal error." At this point I decided to try and install box86 directly using instruction at https://github.com/ptitSeb/box86/blob/master/docs/COMPILE.md and it finally passed! The only difference between these instructions and the box86.sh retropie install script was that the "-DARM_DYNAREC=1" flag was not set. I am still not sure that flag is meant to do but it was only noticeable difference between the builds.

Now that I fixed box86 (or so I think) I tried to install wine again. After removing the code snippet

    # On RPI systems, we need to make sure Box86 is installed.
    #if isPlatform "rpi"; then
    #    if ! rp_isInstalled "box86" ; then
    #        md_ret_errors+=("Sorry, you need to install the Box86 scriptmodule")
    #        return 1
    #    fi
    #fi

it installed successfully with no "Permission Denied" issues! However now I am experiencing a new problem.. now when running winecfg I see

Wine requires a 3G/1G user/kernel memory split to work properly.

and that is basically where I am now. I believe based on some quick searches on this forum and online that this is a fundamental problem with RPi3. So for now I have shelved trying to make this work... perhaps if I ever upgrade to the latest Pi module I will try again.

Though it didn't work I do support this project as I think running old school bullet hell's on Retropie would be amazing.

George

Hi all,

It's been a while since my last post. Happy new year! I don't have any updates per se, but thought I should post a reply because a few folks have had questions and comments.

@hooperre I'd like to hear more about the issue you're experiencing. Are you running from within an existing X session? Most of my scripts try to initialize a X session with xinit and Matchbox. So there could be some issues there. I've been thinking about modifying my scripts to test if X is running already. Otherwise, there are so many other issues that can cause a game to crash. The best bet is to enable all logging and then post the results here. Or even try TwisterOS and check out their Discord channel.

@boolean yeah I used to have Timidity installed as a service. It could be a myriad of things causing the audio issues. Once I got things stable to my own needs I kind of dropped it as nobody else complained about any issues. There have been lots of updates though since my last test, so maybe I'll revisit it.

@mth75 Thanks for testing up the updates to Mesa, Box86, and Wine. I'll have to do the same and update the scripts. I looked at https://dl.winehq.org/wine-builds/debian/dists/buster/main/binary-i386/ and it looks like that is still being updated for Buster. I agree with @ecto though in that DXVK may never work completely on the RPi4. I hope to be proven wrong on that though. I've played around with a lot of Vulkan demos on the RPi4 and they all seem to work really well.

@retro-devil2 Were you able to resolve your issue? Can you provide more info on the RPi image that you were using? I'd like to dig in if possible.

@LivenCorpse I'm glad to hear you resolved your issues with getting Box86 to compile. For the issue with running on an RPi3 though, I've not done it, and for the exact reasons you have also come across. You need to recompile the Kernel to configure it for a 3G/1G memory split. You may have already seen the following pages, but they may help:

Personally, I'd be looking at how to cross compile from withing a Docker container. If you're really interested in Space Cadet on Raspberry Pi, you might be interested in the work someone has done to make it cross platform compatible. The source is on GitHub (not sure if I'd be able to post it here), you'd need the original assets from the game, but other folks have tried it and say it works excellently. I haven't tried it out yet, but looking forward to doing so.

If you'd like to see how some open source Linux x86 games run with Box86 on RPi3, you can check out another repository of mine. https://github.com/GeorgeMcMullen/rp-box86-games

Lastly, this is my own little task list of things to do.

Do some kind of detection to determine if X is already running before trying to launch X. I've done some research on different methods of doing this.
Test updates to Mesa/Box86/Wine
Push the emulator branch to main, as it seems that's really the way to go
Test and play more games!!!

- George

LivenCorpse

@george Hey thanks for the guidance and the links to those x86 games to try out! The scripts in that repo had the flag

rp_module_flags="!all rpi4"

Which I had to comment out to install but each one works!... sort of. Both "Pleet The Bear" and "Maldita Castilla" are unplayably slow. I was seeing the thermometer icon consistently when playing MC. "Defend GUIN" had no performance issues even if reaching a "game over" meant you have to restart the raspberry pi. I would say the flag check for rpi4 is unnecessary for all of these ports considering they do (though very slowly) work.

This is after of course I checkout-ed the "emulator" branch for Box86 and Wine repo you have. Without it none of the box86 games ran because the rom folder (and emulationstation configs) didn't exist... Also that branch fixes a lot of the folder issues I had faced when trying to first run the main branch. For RPI3 I still had to customize the box86 installation following https://github.com/ptitSeb/box86/blob/master/docs/COMPILE.md Can isPlatform or some other helper commands be used to do this custom install for legacy raspberry pi modals?

Considering how slow even "Pleet The Bear" was on my hardware I have doubts old bullet hells would fair better. Maybe its an optimization thing since PTB was pre-compiled but still... I have a steam link setup with a windows 10 machine so that honestly is the easiest route to get that working. Cross-plateform space cadet might be a future project haha.

George

@LivenCorpse Since RPI4 has a different GPU than RPI3, one possibility is that Mesa might perform differently on the two devices. You could try to change the following line in the script:

export LD_LIBRARY_PATH="/opt/retropie/supplementary/mesa/lib/:/opt/retropie/emulators/box86/"

to

export LD_LIBRARY_PATH="/opt/retropie/emulators/box86/"

That would keep the script from using MESA for OpenGL and then just use whatever was installed on the device. I haven't tested it of course. It might not work at all.

isPlatform can be used to customize different installation paths during installation, but not when running the game (I think). So if something is required on one platform vs. another, that would be the way to test what platform you are on.

- George