Mm I see you point. That said, having both the warehouse entry, and a script that could be run on the side could be a great way to encourage people to delve into their console for purposes other than just Retroarch emulation.
Delta rune would be a good tech demo to showcase how undertale could run, once you inject your own licensed files.
Spoilers aside, but the final boss in undertale possibly uses a higher resolution than the gameshell can handle.
I’ll include it here under a spoiler tag. Not that it really spoils anything, since it looks completely random! From memory, this is the only time higher resolutions are used.
spoiler
Later on there are meta moments when the game literally forcibly crashes your game, alters your registry (if on Windows) and deletes your save file. These are vital experiences for those wanting the full undertale experience, and no doubt would be problematic on the Gameshell.
I just posted a sort of “compatibility list” of x86 games I’ve been testing under box86. It’s mostly to support the work ptitSeb is doing on the box86 code, and the discussion in this thread over on a different forum:
But I figured it might be of interest here. Note that just because I marked a game as “working” doesn’t mean it works perfectly at 100% speed. Some require the mouse hack to be usable, and some are working (as far as I can tell), but the screen resolution either won’t scale to the Gameshell or looks too bad to be playable at 320x240.
It’s also very much a work in progress, and I’m hoping more games can be added to the “working” group when box86 receives some bug fixes, etc.
So I finally flashed OS 0.5.
None of the game you posted above work for me.
I tried with the other box86 you provided, no luck.
There must be some dependencies I am missing…
I’m not sure how I missed your edit here, but it sounds like you and @Lix both tested from a fresh 0.5 install and not all of the games worked?
I guess I hadn’t noticed it, but EFMB doesn’t have sound for me either! :-o Glad to hear Gaurodan works for you, @javelinface. But it sounds like @Lix couldn’t get either of these to run either? So neither of you got Maldita Castilla, Super Crate Box, Super Crate Box Together, or Rom Check Fail to run?
It seems I missed some dependencies in the warehouse uploads. Could you check the log.txt files for these after you tried running them? They should be in directories like: /home/cpi/aria2download/madcock/warehouse/master/Freeware%20box86%20Games/[gamename]/file/[gamename]
So, for instance: /home/cpi/aria2download/madcock/warehouse/master/Freeware%20box86%20Games/Gaurodan/file/Gaurodan/log.txt
Sorry for the long paths, but that’s where the warehouse puts stuff.
Hopefully the log files will offer a clue. If there are libraries not loading because they can’t be found, it should be in the log.
I’m onto it! Good thing I have a bunch of spare SD cards to test this on!
I’ll be doing it on a fresh 0.5 install, just with the latest launcher update.
Doom RL might be possible. I didn’t even know it existed until now, and since it’s free, has a 32bit Linux version for download, and seems to use standard SDL stuff, it might work. I’m not sure how playable it will be though as I haven’t played it so I don’t know if there are enough buttons on the Gameshell to map to the game controls. Also, if the game doesn’t allow full screen to fit (shrink) the display on the Gameshell screen, then it won’t be playable. And even if it does work full screen, I’m afraid the text may not be readable based on some of the screenshots on the Doom RL website. But I’ll try it out when I get a chance!
EDIT: Ok, I just tried the windows version to see what the game looked like. I’m pretty sure it’s going to be unplayable on Gameshell even if it does work. The text will be too small to read. I took a few screenshots and shrunk them down to the Gameshell display size and this is what they look like:
And it expects you to be able to type your character name. That’s not going to happen on the Gameshell, unless you have a bluetooth keyboard connected.
Just out of curiosity though, I’ll see if I can get it to run anyway.
EDIT: So it seems to try to start up, but I never get past a black screen. There are lots of options to configure and I forced it to fullscreen, but I didn’t get it to work. I don’t see anything weird in the log so I’m not sure what’s causing it to fail:
05:25:53 : INFO : — Logging start : 28-1-20 05:25:53 —
05:25:53 : REPORT : ---------------------- Compiler info -------------------------
05:25:53 : REPORT : This program was compiled at 13:15:29 on 2013/03/19 by user
05:25:53 : REPORT : Compiler version : 2.6.0
05:25:53 : REPORT : Target OS : Linux
05:25:53 : REPORT : Target CPU : i386
05:25:53 : REPORT : ---------------------- OS runtime Using native(wrapped) libSDL-1.2.so.0
Using native(wrapped) libGL.so.1
Using native(wrapped) libGLU.so.1
Using native(wrapped) libSDL_image-1.2.so.0
-28-2020 05:25:53
05:25:53 : INFO : Root path set to -
05:25:53 : INFO : <TDoom//0> Initialized.
05:25:53 : INFO : <TDoom//0> 0.9.9.7
05:25:53 : INFO : DoomNet: downloading doom.chaosforge.net/info.xml to info.xml…
05:25:53 : INFO : HTTP/1.1 403 Forbidden
05:25:53 : INFO : DoomNet: EHTTPError caught - GET doom.chaosforge.net /info.xml - 403 Forbidden
05:25:53 : INFO : Remote stable - 0.0.0 ()
05:25:53 : INFO : Remote beta - 0.0.0 ()
05:25:53 : INFO : MOTD - Could not connect to ChaosForge server!
05:25:53 : INFO : DoomModules loading…
05:25:53 : INFO : DoomModules loaded.
05:25:53 : INFO : Initializing SDL…
05:25:53 : INFO : Checking mode 320x240/32bit…
05:25:52 : INFO : Mode 320x240/32 set.
05:25:52 : INFO : SDL IO system
Ancient Domain of Mystery is commercial and I don’t own it so I don’t really have a way to test that. Based on the screenshots though, it seems like it would need a larger display (they claim 800x600 on Steam). And since it’s Steam, it will almost certainly suffer from the same problem all the Steam games suffer from – the DRM won’t work. So far no Steam games work with box86, but ptitSeb mentioned a while back that he was making progress getting Steam to work under it. If there was a Humble Bundle or DRM-free version of the game, it might work, but like I say the display probably wouldn’t fit the Gameshell anyway.
The thing is, the early (and most modern) roguelikes are meant to be played with a keyboard. And we don’t have a keyboard built into the Gameshell. We’ve pretty much got a d-pad and 7 buttons (shift doesn’t count). With the shift key we also have access to a slightly more awkward total of 17 buttons and the d-pad. The lightkey (which I’ve not used yet since I felt like it would be even more awkward) give only another 4 buttons since they repeated the shift key, and reused 4 of the other button assignments. So at most, even with the lightkey, you’ll have 21 buttons plus the D-pad to use. I guess that’s actually a lot of buttons, but remembering what is mapped to what for a roguelike sounds like it would be a challenge!
Another thing about the classic text based roguelikes is they generally use text characters for the display, and it might not be possible to fit that much text on the screen and still be able to tell what is what.
Ooops, looks like others already said a lot of that here:
Powder should work ok on Gameshell though, as I don’t think it uses that many buttons and it has graphics that would fit on the display with @r043v’s port.
Cool, thanks for trying again and checking out those logs!
Whatever we find out, and whatever needs to get added to my warehouse repository, it probably makes sense for me to update the files there with the latest build of box86. There have been a number of improvements since I put those files up. But I’ll wait and do whatever changes are needed all at once.
The plot thickens. There doesn’t seem to be a log file generated. Almost as if it didn’t even get past the initial execution of the *.sh file.
I’ll have a poke around to see what I can do. It wouldn’t be something as simple as just a chmod +x to the *.sh files would it?
Okay, now trying to run it from a terminal, I get this message:
**cpi@clockworkpi** : **~/aria2download/madcock/warehouse/master/Freeware%20box86%20Games/RomCheckFail/file/RomCheckFail** $ ./RomCheckFail.sh
xmodmap: unable to open display ''
xmodmap: unable to open display ''
xmodmap: unable to open display ''
xmodmap: unable to open display ''
Video initialization failed: Unable to open a console terminal
./RomCheckFail.sh: line 10: 4371 Segmentation fault ./b
Same thing if I try to pass it to the gameshell display
Using default BOX86_LD_LIBRARY_PATH: ./:lib/:lib32/:x86/
Using default BOX86_PATH: ./:bin/
Counted 20 Env var
Looking for bin/RomCheckFail
Using native(wrapped) libpthread.so.0
Using native(wrapped) libz.so.1
Using native(wrapped) libutil.so.1
Using emulated lib/libtuxcap.so.3
Using emulated lib/libMagick.so.9
Error initializing native libjpeg.so.62 (last dlerror is libjpeg.so.8: cannot open shared object file: No such file or directory)
Using emulated lib/libjpeg.so.62
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux.so.2
Using native(wrapped) librt.so.1
Error initializing native libpng12.so.0 (last dlerror is libpng12.so.0: cannot open shared object file: No such file or directory)
Using emulated lib/libpng12.so.0
Using native(wrapped) libm.so.6
Using native(wrapped) libdl.so.2
Using emulated lib/libMagick++.so.9
Using emulated lib/libWand.so.9
Using emulated lib/libstdc++.so.6
Using emulated lib/libgcc_s.so.1
Using native(wrapped) libSDL-1.2.so.0
Using native(wrapped) libSDL_mixer-1.2.so.0
Using emulated lib/libpython2.5.so.1.0
Using native(wrapped) libGLU.so.1
Using native(wrapped) libGL.so.1
Error: Symbol argz_next not found, cannot apply R_386_JMP_SLOT @0xb6358c24 (0x2054a)
Error: Symbol argz_stringify not found, cannot apply R_386_JMP_SLOT @0xb6358fe0 (0x2143a)
Error: Symbol argz_insert not found, cannot apply R_386_JMP_SLOT @0xb6359170 (0x21a7a)
Error: Symbol argz_create_sep not found, cannot apply R_386_JMP_SLOT @0xb63594ec (0x2286a)
Warning: Weak Symbol _ZGTtnaj not found, cannot apply R_386_JMP_SLOT @0xb5f7d19c (0x6b506)
Warning: Weak Symbol _ZGTtdlPv not found, cannot apply R_386_JMP_SLOT @0xb5f7d478 (0x6c076)
Using emulated /home/cpi/aria2download/madcock/warehouse/master/Freeware%20box86%20Games/RomCheckFail/file/RomCheckFail/bin/math.so
Using emulated /home/cpi/aria2download/madcock/warehouse/master/Freeware%20box86%20Games/RomCheckFail/file/RomCheckFail/bin/binascii.so
Using emulated /home/cpi/aria2download/madcock/warehouse/master/Freeware%20box86%20Games/RomCheckFail/file/RomCheckFail/bin/_random.so
This is weird. I’d swear I tested each one of these, but I can’t get RomCheckFail to run from the warehouse either. And yet if I run it from SSH pointing to DISPLAY=:0, it works.
Speaking of which, everything in your log matches mine. Did the game not run even from SSH for you? It takes a little while to load and sits on a black screen, but mine did start up.
I still don’t know why it’s not working from the warehouse menu though. I need to spend some time on this and figure it out. The main difference between Gaurodan and RomCheckFail is that the files are in different places, with the RomCheckFail executable in the “bin” directory, and some libraries in “libs”. With Gaurodan, everything is in the same top level directory. But the path stuff in the script looks good, I think? I’m not sure what is going on.
How strange, I can’t get it to run exporting it to DISPLAY=:0; let alone getting it to run directly via SSH. It would immediately post the display I pasted above.
The error message Cannot open display "default display" could be pointing to the error; perhaps needing to specify the display explicitly? But nothing else needs that so hmm.
The other message, xmodmap: unable to open display '' - was there possibly a line where you needed to specify which display to use there, between the ’ ’ marks?
I just tried running box86 with the binaries from the command line, and got this:
**cpi@clockworkpi** : **~/aria2download/madcock/warehouse/master/Freeware%20box86%20Games/RomCheckFail/file/RomCheckFail** $ ./box86 bin/RomCheckFail
Using default BOX86_LD_LIBRARY_PATH: ./:lib/:lib32/:x86/
Using default BOX86_PATH: ./:bin/
Counted 20 Env var
Looking for bin/RomCheckFail
Using native(wrapped) libpthread.so.0
Using native(wrapped) libz.so.1
Using native(wrapped) libutil.so.1
Using emulated lib/libtuxcap.so.3
Using emulated lib/libMagick.so.9
Error initializing native libjpeg.so.62 (last dlerror is libjpeg.so.8: cannot open shared object file: No such file or directory)
Using emulated lib/libjpeg.so.62
Using native(wrapped) libc.so.6
Using native(wrapped) ld-linux.so.2
Using native(wrapped) librt.so.1
Error initializing native libpng12.so.0 (last dlerror is libpng12.so.0: cannot open shared object file: No such file or directory)
Using emulated lib/libpng12.so.0
Using native(wrapped) libm.so.6
Using native(wrapped) libdl.so.2
Using emulated lib/libMagick++.so.9
Using emulated lib/libWand.so.9
Using emulated lib/libstdc++.so.6
Using emulated lib/libgcc_s.so.1
Using native(wrapped) libSDL-1.2.so.0
Using native(wrapped) libSDL_mixer-1.2.so.0
Using emulated lib/libpython2.5.so.1.0
Using native(wrapped) libGLU.so.1
Using native(wrapped) libGL.so.1
Error: Symbol argz_next not found, cannot apply R_386_JMP_SLOT @0xb634ec24 (0x2054a)
Error: Symbol argz_stringify not found, cannot apply R_386_JMP_SLOT @0xb634efe0 (0x2143a)
Error: Symbol argz_insert not found, cannot apply R_386_JMP_SLOT @0xb634f170 (0x21a7a)
Error: Symbol argz_create_sep not found, cannot apply R_386_JMP_SLOT @0xb634f4ec (0x2286a)
Warning: Weak Symbol _ZGTtnaj not found, cannot apply R_386_JMP_SLOT @0xb5f7319c (0x6b506)
Warning: Weak Symbol _ZGTtdlPv not found, cannot apply R_386_JMP_SLOT @0xb5f73478 (0x6c076)
Video initialization failed: Unable to open a console terminal
Using emulated /home/cpi/aria2download/madcock/warehouse/master/Freeware%20box86%20Games/RomCheckFail/file/RomCheckFail/bin/math.so
Using emulated /home/cpi/aria2download/madcock/warehouse/master/Freeware%20box86%20Games/RomCheckFail/file/RomCheckFail/bin/binascii.so
Using emulated /home/cpi/aria2download/madcock/warehouse/master/Freeware%20box86%20Games/RomCheckFail/file/RomCheckFail/bin/_random.so
Segmentation fault
Again, a seg fault.
This is its own fun meta game to be honest haha. “How to get Warehouse working properly”
Also, let me know if you need me to test any more. I just chose Rom Check Fail, because it was the easiest to type haha.
I spent some time on it but I’m still not sure what is going on. The only two games I could get to run from the default warehouse location were Gaurodan and EFMB. I remember testing them all before I posted though, so I’m not sure if I’m going crazy or if something changed.
I probably won’t have time to update this until the weekend, but I think I need to change the way I use the warehouse. Instead of just keeping the files in the default ~/aria2download/… path, I think I’ll package this up differently so it installs them in the usual place under /apps/Menu. I know they work well there, as that’s how I’ve been using them on a regular basis. And it makes them easier to get to as well.
On a positive note, I saw that ptitSeb made lots of updates to box86 in the past few days, and although I’ve only tried it on a few things, it seems to be more compatible and faster too. PixelJunk Monsters Ultimate seems to be playable now, though it’s rather slow in places. Rom Check Fail seems faster than before. Super Crate Box seems slower though. When I update the warehouse, I’ll test these with the latest version and include it. I might see about including an entry in the warehouse to download and build the latest box86. Then maybe I could have all the individual games that depend on it look (and install it) in the same place, and have the build option put the newly built one there. That way each game would work if downloaded alone, but the build option would let you install the latest version for all the games.
In any case, I’m convinced running the stuff in the default warehouse location is a bad idea. I still don’t know why some things work and others don’t. I checked permissions, but the only thing I can figure is the way stuff gets launched in the warehouse is somehow messing with the paths and it’s not finding files. I tried several different ways to define the paths in my launch scripts, but nothing worked.
I thought about splitting box86 out, but then I’m sure some people would just install a game and not the box86 option and probably wonder why it isn’t working. The only way to ensure each game works alone, is to include everything they need independently of each other. I agree it’s a waste though. I suppose I could check to see if box86 exists already, and not overwrite it for individual games. But a separate box86 option could overwrite it, as a way to upgrade. I’d rather have a box86 option do a full build from the latest code though, since I don’t know how often I’d be able to update it in the warehouse.
Re: /usr/bin/env do you mean use it and dump to a log so I can see what might be missing, or to do something like this to actually run box86?
it will be a lot of work for you at each update ^^
env will simply load all environment variable, depending on how scripts are run it can be cases where it’s not set, it’s pretty specific yet and must not be the case here as all use classic method on the local system
I downloaded the 32bit Linux version, copied it to the Gameshell and uncompressed it, and then ran it with box86 from SSH like this: DISPLAY=:0 ./box86 doomrl
There’s a config.lua file that’s installed with it, and I took a look at that and played around with a few options. I know I set StartFullscreen = true. It can also be set to just generate a random player name so you don’t have to type it in (which would have been impossible on the Gameshell alone) with: AlwaysRandomName = false. I never actually tried that since I couldn’t get it to go that far. There are a bunch of other options too. It’s possible that the right settings would let it skip past whatever was causing it to fail. I think it’s possible to turn off whatever network checking it’s doing, and there might be some fancy screen effects or something that’s causing it trouble.
It might just be that whatever it needs isn’t implemented yet in box86.
Thanks for the link! Looks like that is exactly what I need to be able to figure out where the script is being run from. I was avoiding using full paths, since I figured the location of the warehouse stuff could change at some point in the future. But the things mentioned there at stackoverflow should allow me to use relative paths, which is what I was trying (and failing) to do.
