Box86 - Linux Userspace x86 Emulator

[adcockm]

To check that, launch your cames with "BOX86_DYNAREC_LOG=1", and you'll see on the console if dynarec have some unimplemented opcodes. In that case, open a ticket on github, or give my the hex code here and I'll try to add them...

Just want to verify I'm finding and sending the right thing before I find and post more. If this is what you're looking for I'll make tickets for others, to help tracking and keep this thread clean. With "Dynarec log level is 1", I get the following from ROM Check Fail (although aside from a few speed hiccups it seems to work):

Error: Symbol argz_next not found, cannot apply R_386_JMP_SLOT @0xb62a5c24 (0x2054a)
Error: Symbol argz_stringify not found, cannot apply R_386_JMP_SLOT @0xb62a5fe0 (0x2143a)
Error: Symbol argz_insert not found, cannot apply R_386_JMP_SLOT @0xb62a6170 (0x21a7a)
Error: Symbol argz_create_sep not found, cannot apply R_386_JMP_SLOT @0xb62a64ec (0x2286a)
Warning: Weak Symbol _ZGTtnaj not found, cannot apply R_386_JMP_SLOT @0xb5eca19c (0x6b506)
Warning: Weak Symbol _ZGTtdlPv not found, cannot apply R_386_JMP_SLOT @0xb5eca478 (0x6c076)

I also get a couple of library init errors, but I'm guessing those matter since it ends up using the emulated version immediately after?
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
...
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

Anyhow, If those symbol errors are what you're looking for to identify opcodes, I'll make some tickets.

 

[adcockm]

*EDIT*: Mmmm yeah, you are right, the repo is gone, no traces of it anywhere... I wonder why?!

Yeah, not sure what happened to that repo. Looking through the games I have to try, Theora only seems to be referenced as a library in Reus, A Virus Named TOM, and Dust An Elysian Tale. The other games I have don't seem to need it.

That said, I've tried several games, and I only managed to get one working on the Gameshell, and ironically it was A Virus Named TOM (though it did eventually crash, but it showed the main menu and worked for a bit). Most of the games are probably unplayable at 320x240, even if they did work, and any that require a mouse are also impractical on this device. But I was hoping I might get games like Fez or Towerfall running.

Maybe I should adjust the parameters I'm passing in? I've just been using the ones from the example in that article you shared:
LC_ALL="C" LIBGL_ES=2 LIBGL_GL=21 LIBGL_DEFAULTWRAP=2 LIBGL_FBOFORCETEX=1 LD_LIBRARY_PATH=~/monolibs mono FEZ.exe > log.txt
I get a bunch of messages from LIBGL in the log, but all look just informational, and I don't see any errors or warnings. The only other thing I get is an unhelpful message on the command line: ./Fez.sh: line 2: 9977 Segmentation fault

Spoiler: log.txt

LIBGL: Initialising gl4es
LIBGL: v1.1.3 built on Jan 16 2020 01:23:30
LIBGL: Using GLES 2.0 backend
LIBGL: loaded: libGLESv2.so
LIBGL: loaded: libEGL.so
LIBGL: Float and Half-Float texture support disabled
LIBGL: Using GLES 2.0 backend
LIBGL: Hardware Full NPOT detected and used
LIBGL: Extension GL_EXT_blend_minmax detected and used
LIBGL: FBO are in core, and so used
LIBGL: PointSprite are in core, and so used
LIBGL: CubeMap are in core, and so used
LIBGL: BlendColor is in core, and so used
LIBGL: Blend Substract is in core, and so used
LIBGL: Blend Function and Equation Separation is in core, and so used
LIBGL: Texture Mirrored Repeat is in core, and so used
LIBGL: Extension GL_OES_mapbuffer detected
LIBGL: Extension GL_OES_element_index_uint detected and used
LIBGL: Extension GL_OES_packed_depth_stencil detected and used
LIBGL: Extension GL_OES_depth24 detected and used
LIBGL: Extension GL_OES_rgb8_rgba8 detected and used
LIBGL: Extension GL_EXT_multi_draw_arrays detected
LIBGL: Extension GL_EXT_texture_format_BGRA8888 detected and used
LIBGL: Extension GL_OES_depth_texture detected and used
LIBGL: high precision float in fragment shader available and used
LIBGL: Extension GL_EXT_frag_depth detected and used
LIBGL: Max vertex attrib: 16
LIBGL: Extension GL_OES_get_program detected and used
LIBGL: Number of supported Program Binary Format: 0
LIBGL: Max texture size: 4096
LIBGL: Max Varying Vector: 8
LIBGL: Texture Units: 8(8), Max lights: 8, Max planes: 6
LIBGL: Hardware vendor is lima
LIBGL: sRGB surface supported
LIBGL: Targeting OpenGL 2.1
LIBGL: NPOT texture handled in hardware
LIBGL: Not trying to batch small subsequent glDrawXXXX
LIBGL: try to use VBO
LIBGL: Force texture for Attachment color0 on FBO
LIBGL: Default wrap mode is GL_CLAMP_TO_EDGE, enforced
LIBGL: glX Will try to recycle EGL Surface
LIBGL: Current folder is:/home/cpi/x86/box86 mono/Fez

It also creates a game debug log in./.local/usr/share/FEZ which contains a MojoShader issue:

Spoiler: debug log

(14:12:32.747) [Version] INFORMATION : 1.12, Build Date : 2016-11-27 22:12:43
(14:12:33.021) [FNA] INFORMATION : IGLDevice: OpenGLDevice
(14:12:33.030) [FNA] INFORMATION : OpenGL Device: GL4ES wrapper
(14:12:33.031) [FNA] INFORMATION : OpenGL Driver: 2.1 gl4es wrapper 1.1.3
(14:12:33.031) [FNA] INFORMATION : OpenGL Vendor: ptitSeb
(14:12:33.032) [FNA] INFORMATION : MojoShader Profile: glsl120
(14:12:33.074) [FNA] INFORMATION : EXT_swap_control_tear unsupported. Fall back to standard VSync.
(14:12:33.224) [Instancing] INFORMATION : Hardware instancing is disabled
(14:12:33.415) [FNA] INFORMATION : EXT_swap_control_tear unsupported. Fall back to standard VSync.
(14:12:33.422) [SettingsManager] INFORMATION : Screen set to {{Width:2944 Height:2104 Format:Color}}
(14:12:33.423) [SettingsManager] INFORMATION : Screen mode is : Fullscreen
(14:12:33.424) [SettingsManager] INFORMATION : Backbuffer is 336x240
(14:12:33.424) [SettingsManager] INFORMATION : VSync is on
(14:12:33.425) [SettingsManager] INFORMATION : Multisample count is 0
(14:12:33.832) [Threading] INFORMATION : Multithreading is enabled
(14:12:38.968) [Intro] INFORMATION : First draw done!
(14:12:39.156) [Unhandled Exception] ERROR : System.EntryPointNotFoundException: MOJOSHADER_glProgramViewportFlip
at (wrapper managed-to-native) MojoShader.MOJOSHADER_glProgramViewportFlip(int)
at Microsoft.Xna.Framework.Graphics.OpenGLDevice.ApplyVertexAttributes (Microsoft.Xna.Framework.Graphics.VertexBufferBinding[] bindings, System.Int32 numBindings, System.Boolean bindingsUpdated, System.Int32 baseVertex) [0x00288] in <a9ba90109dce4c00a8252247c08a4a41>:0
at Microsoft.Xna.Framework.Graphics.GraphicsDevice.DrawIndexedPrimitives (Microsoft.Xna.Framework.Graphics.PrimitiveType primitiveType, System.Int32 baseVertex, System.Int32 minVertexIndex, System.Int32 numVertices, System.Int32 startIndex, System.Int32 primitiveCount) [0x00006] in <a9ba90109dce4c00a8252247c08a4a41>:0
at Microsoft.Xna.Framework.Graphics.SpriteBatch.DrawPrimitives (Microsoft.Xna.Framework.Graphics.Texture texture, System.Int32 baseSprite, System.Int32 batchSize) [0x00087] in <a9ba90109dce4c00a8252247c08a4a41>:0
at Microsoft.Xna.Framework.Graphics.SpriteBatch.FlushBatch () [0x000fb] in <a9ba90109dce4c00a8252247c08a4a41>:0
at Microsoft.Xna.Framework.Graphics.SpriteBatch.End () [0x00029] in <a9ba90109dce4c00a8252247c08a4a41>:0
at FezGame.Components.Intro.Draw (Microsoft.Xna.Framework.GameTime gameTime) [0x00314] in <17c795b28e00420dbe494c0ec426f378>:0
at Microsoft.Xna.Framework.Game.Draw (Microsoft.Xna.Framework.GameTime gameTime) [0x00078] in <a9ba90109dce4c00a8252247c08a4a41>:0
at FezGame.Fez.Draw (Microsoft.Xna.Framework.GameTime gameTime) [0x00141] in <17c795b28e00420dbe494c0ec426f378>:0
at Microsoft.Xna.Framework.Game.Tick () [0x00236] in <a9ba90109dce4c00a8252247c08a4a41>:0
at Microsoft.Xna.Framework.SDL2_FNAPlatform.RunLoop (Microsoft.Xna.Framework.Game game) [0x00640] in <a9ba90109dce4c00a8252247c08a4a41>:0
at Microsoft.Xna.Framework.Game.Run () [0x0002f] in <a9ba90109dce4c00a8252247c08a4a41>:0
at FezGame.Program.MainInternal () [0x00024] in <17c795b28e00420dbe494c0ec426f378>:0
at Common.Logger.Try (System.Action action) [0x00000] in <f7a6cc600a974ee9a6b21d6cfcfe354d>:0
(14:12:39.379) [FEZ] INFORMATION : Exiting.

I had also adjusted my Fez settings file to try to force 320x240, so I guess it's possible the game just doesn't like the low resolution and is exiting out because of that.

Spoiler: settings

settings type="FezEngine.Tools.Settings, FezEngine" {
useCurrentMode false
screenMode "Fullscreen"
scaleMode "FullAspect"
width 320
height 240
highDPI false
language "English"
soundVolume 1F
musicVolume 1F
vibration true
pauseOnLostFocus true
singlethreaded false
brightness 0.5F
keyboardMapping Jump="Space" GrabThrow="LeftControl" CancelTalk="LeftShift" Up="Up" Down="Down" Left="Left" Right="Right" LookUp="I" LookDown="K" LookRight="L" LookLeft="J" OpenMap="Escape" OpenInventory="Tab" MapZoomIn="W" MapZoomOut="S" Pause="Enter" RotateLeft="A" RotateRight="D" FpViewToggle="RightAlt" ClampLook="RightShift"
controllerMapping Jump="A" GrabThrow="X" CancelTalk="B" OpenMap="Back" OpenInventory="Y" MapZoomIn="RightShoulder" MapZoomOut="LeftShoulder" Pause="Start" RotateLeft="LeftTrigger" RotateRight="RightTrigger" FpViewToggle="LeftStick" ClampLook="RightStick"
uiKeyboardMapping Up="Up" Down="Down" Left="Left" Right="Right" Jump="Enter" CancelTalk="Escape" Pause="Enter" OpenMap="Escape" GrabThrow="LeftControl" LookUp="I" LookDown="K" LookRight="L" LookLeft="J" OpenInventory="Tab" MapZoomIn="W" MapZoomOut="S" RotateLeft="A" RotateRight="D" FpViewToggle="RightAlt" ClampLook="RightShift"
deadZone 40
disableController false
invertLookX false
invertLookY false
vSync true
hardwareInstancing false
multiSampleCount 0
multiSampleOption false
lighting true
}

I get MojoShader errors on TowerFall and one or two others. (But I did build the libmojoshader.so file and it's with the other custom mono libs!) So I'm not sure what's going on.

Sorry again for the off topic post!

 

[ptitSeb]

Just want to verify I'm finding and sending the right thing before I find and post more. If this is what you're looking for I'll make tickets for others, to help tracking and keep this thread clean. With "Dynarec log level is 1", I get the following from ROM Check Fail (although aside from a few speed hiccups it seems to work):

Error: Symbol argz_next not found, cannot apply R_386_JMP_SLOT @0xb62a5c24 (0x2054a)
Error: Symbol argz_stringify not found, cannot apply R_386_JMP_SLOT @0xb62a5fe0 (0x2143a)
Error: Symbol argz_insert not found, cannot apply R_386_JMP_SLOT @0xb62a6170 (0x21a7a)
Error: Symbol argz_create_sep not found, cannot apply R_386_JMP_SLOT @0xb62a64ec (0x2286a)

This is not Dynarec log, but "regular log". Still those 4 functions should be wrapped probably, I'll what I can do.

Warning: Weak Symbol _ZGTtnaj not found, cannot apply R_386_JMP_SLOT @0xb5eca19c (0x6b506)
Warning: Weak Symbol _ZGTtdlPv not found, cannot apply R_386_JMP_SLOT @0xb5eca478 (0x6c076)

Those 2 warning are alway there and can be safely ignored....

I also get a couple of library init errors, but I'm guessing those matter since it ends up using the emulated version immediately after?
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
...
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

Anyhow, If those symbol errors are what you're looking for to identify opcodes, I'll make some tickets.

Those 2 native library missing... Well, it would probably load stuff faster if it could find them...

All in all, no missing opcodes here.

It also creates a game debug log in./.local/usr/share/FEZ which contains a MojoShader issue:

The crash you have is because of this mojoshader issue. The function is either missing or need to be activated with some compilation switch. I already saw that issue somewhere in a forum (not here), but I don't remember how it was fixed. I think the code of that function has to be added back (or maybe just use an older revision of mojoshader).

 

[adcockm]

I solved the MojoShader issue! I took a look at the commit history and seemed like they removed support for the function that kept showing up in my errors at a certain point. So I grabbed the last version of the code before they made the change, built it, and Fez now runs!

Here's the version I used:

GitHub - icculus/mojoshader at df8a5c1674e99f6cf0d4d9cb28c138fd217ec543

Use Direct3D shaders with other 3D rendering APIs. - GitHub - icculus/mojoshader at df8a5c1674e99f6cf0d4d9cb28c138fd217ec543

github.com

(I'm missing all the updates since last July, but at least the game launches and seems to work.)

I haven't tried other games again, but I'm hopeful this will fix them too.

 

[MTPDA]

Try here: https://github.com/FNA-XNA/Theorafile
(it used often for intro video and things like that).

*EDIT*: Mmmm yeah, you are right, the repo is gone, no traces of it anywhere... I wonder why?!

I don't know if the repo is still gone for you guys but when I clicked on it just now I was brought to the github page, there was a commit 4 days ago and the jump to file button brought me to a list of files. Is that the repo or am I misunderstanding?

 

[ptitSeb]

I don't know if the repo is still gone for you guys but when I clicked on it just now I was brought to the github page, there was a commit 4 days ago and the jump to file button brought me to a list of files. Is that the repo or am I misunderstanding?

Yeah, the issue is not for the TheoraFile repo that I linked, but for TheoraPlay-CS the cannot be found anymore (no link this time).

 

[MTPDA]

Yeah, the issue is not for the TheoraFile repo that I linked, but for TheoraPlay-CS the cannot be found anymore (no link this time).

Ah, ok. Thanks for the clarification.

 

[adcockm]

So I spoke too soon about Fez. I got it to show the splash screens, and the main menu. But when I try to actually start the game, it crashes. Unfortunately, neither the output I'm logging from the game, or the game's own log file in ~/.local/share/FEZ have any errors or warnings. The last thing the game logs is the level successfully loading and then the log stops. The game itself just exits. No more Mojoshader errors, or indeed, errors of any kind that I'm aware of, but clearly something is wrong somewhere! :-( I've seen a similar thing on a few other games, which get farther than before. And some games seem to run, but are just not playable on the Gameshell due to screen resolution or the control scheme (mouse).

On a positive note, I'm feeling more comfortable now working with the library hackery required to get games working under box86. I got a few more games working by taking x86 libraries from elsewhere and forcing a preload and emulation rather than using the native library that box86 wanted to use by default. Up until now, I've just let box86 do what it wanted to do, and was happy when it worked. But now I'm learning to appreciate the finer control you've built in. I realize the native version would run faster, but I think some games were tripping up because the native library was missing something, and I just set it aside and tried another game. I plan to go back through the "broken" ones and see if I can force them to work with library hackery and parameters. ;-)

I've also found some legit dynarec opcode "missing" errors. So I'll send those your way soon, but I figured I'd bundle them up rather than send you a bunch of stuff separately. Hopefully there are patterns and some that occur more frequently.

In other news, it seems the Lima-based GL support on Gameshell is missing some GL opcode that are required for some games. I recently got this: "undefined symbol: glGenFramebuffersOES". I tried using the libraries I built using your guide, but that didn't seem to change anything. So I'm guessing the current GL support on Gameshell is lacking, and that might be tripping me up in some cases. Since it's actively being developed, there's hope for the future, but nothing I'm aware of that I can do right now. So unless I get a new lead I'm thinking I'll let the Mono stuff go and circle back to the box86 library hackery. At some point I'll document this somewhere, but for now I just have the info in the launch script for each game.

By the way, I found a hidden goldmine in a Humble Bundle game called Momodora: Reverie Under the Moonlight. The game is HUGE, but that's because for some weird reason they included what looks like an entire set of i368-linux-gnu libraries. Previously, I was hunting for these libs online in the debian distros, but when I finally got to this game I was astonished to find all (?) of them there. I've been tempted to install them as I need them in a similar way you do with libstdc++.so.6 and libgcc_s.so.1 so they are there for future games that might need them, but I also want to be able to package up this stuff eventually on a per game basis (at least for the free games, and maybe even for some commercial games with the caveat that someone would need to supply the missing commercial files). So for now I've just been duplicating the files as needed.

 

[ptitSeb]

So I spoke too soon about Fez. I got it to show the splash screens, and the main menu. But when I try to actually start the game, it crashes. Unfortunately, neither the output I'm logging from the game, or the game's own log file in ~/.local/share/FEZ have any errors or warnings. The last thing the game logs is the level successfully loading and then the log stops. The game itself just exits. No more Mojoshader errors, or indeed, errors of any kind that I'm aware of, but clearly something is wrong somewhere! :-( I've seen a similar thing on a few other games, which get farther than before. And some games seem to run, but are just not playable on the Gameshell due to screen resolution or the control scheme (mouse).

The error is probably OpenGL based. FEZ use Instancing, maybe you should disable that in options screen. You can also try to run it with gl4es (I assume you also have an GLES driver with the Lima driver) ?

On a positive note, I'm feeling more comfortable now working with the library hackery required to get games working under box86. I got a few more games working by taking x86 libraries from elsewhere and forcing a preload and emulation rather than using the native library that box86 wanted to use by default. Up until now, I've just let box86 do what it wanted to do, and was happy when it worked. But now I'm learning to appreciate the finer control you've built in. I realize the native version would run faster, but I think some games were tripping up because the native library was missing something, and I just set it aside and tried another game. I plan to go back through the "broken" ones and see if I can force them to work with library hackery and parameters. ;-)

Yep the goal is to have most stuff Native indeed... But I'm not there yet. When you found obvious case were using an emulated lib fix a game, don't hesistate to tell me so I can try to fix the native version (if possible). Sometimes, it's because the game use older version, and wrapping is not really possible. I had this on LittleInferno, where the libvorbis used was much older than what is on all distribution now, and I needed to force use the emulated one for this...

I've also found some legit dynarec opcode "missing" errors. So I'll send those your way soon, but I figured I'd bundle them up rather than send you a bunch of stuff separately. Hopefully there are patterns and some that occur more frequently.

Ok, cool. Put also the game/software that needs it if possible, so I can try to tests the implemented opcode (if I can).

In other news, it seems the Lima-based GL support on Gameshell is missing some GL opcode that are required for some games. I recently got this: "undefined symbol: glGenFramebuffersOES". I tried using the libraries I built using your guide, but that didn't seem to change anything. So I'm guessing the current GL support on Gameshell is lacking, and that might be tripping me up in some cases. Since it's actively being developed, there's hope for the future, but nothing I'm aware of that I can do right now. So unless I get a new lead I'm thinking I'll let the Mono stuff go and circle back to the box86 library hackery. At some point I'll document this somewhere, but for now I just have the info in the launch script for each game.

Well glGenFramebuffersOES is a GLES 1.1 symbol, not a Desktop OpenGL, so it's not surprising you don't have it. It's not even a GLES 2.0 symbol. I can add the symbol in gl4es if needed (it may be already there, I need to check)...

By the way, I found a hidden goldmine in a Humble Bundle game called Momodora: Reverie Under the Moonlight. The game is HUGE, but that's because for some weird reason they included what looks like an entire set of i368-linux-gnu libraries. Previously, I was hunting for these libs online in the debian distros, but when I finally got to this game I was astonished to find all (?) of them there. I've been tempted to install them as I need them in a similar way you do with libstdc++.so.6 and libgcc_s.so.1 so they are there for future games that might need them, but I also want to be able to package up this stuff eventually on a per game basis (at least for the free games, and maybe even for some commercial games with the caveat that someone would need to supply the missing commercial files). So for now I've just been duplicating the files as needed.

Well, another "gold mine" of libs is ... steam. While steam is not working yet on box86, it already install itself correctly, and with steam, you get the "steam-runtime" full of libs. Maybe there are the same in Momodora, I have checked the content yet?

 

[adcockm]

I haven't taken the time to mess with Fez more -- I'm not sure if there is a GLES driver on Lima.

I created a spreadsheet that I'm still filling out. I included the names and sources of games, a status indicator, and a dump of (what I think is?) relevant log information. I purposely skipped any lines that were native, and I also tried to remove output from the games themselves. I also highlighted dynarec issues when I saw them:

I think you're probably right about the steam libs -- Momodora seems to be including them too. I haven't tried to install Steam itself yet.

Let me know if I'm missing anything that would be helpful for the spreadsheet. I'm hoping it will be useful to help you track down and decide on which dynarec issues to tackle next, but I'm also using it as a sort of compatibility list for Gameshell. Given the restrictions on the platform (especially 320x240 display), I'm thinking some of the games I marked with "issues" might run fine on another platform. If it seems like it was only a screen resolution issue, I marked it that way. Also, just because a game is marked working doesn't mean it's full speed. But again, that might have to do with the device I'm testing on. Some of the partial logs are quite long, so I made the rows a fixed height just to make it usable.

Also, these logs were probably produced with a version of box86 that was a few updates behind the latest. I've been trying to keep up, but I tested a bunch of games and saved their logs, and I know you've made updates since.

EDIT: Oh wow, I didn't realize the spreadsheet would be embedded here. Hopefully that works ok for you. I expected it to just be the link I shared! Oh, and this embedded version messed up the fixed height rows. :-(

Here's just the link: box86 compatibility

 

[ptitSeb]

Wow @adcockm , impressive!

Lots of data here, and sometimes, different result that I have on the Pandora.

I don't have all the games you list, but many of them. How do you prefer we interact? On this board or directly on spreadsheet?

 

[adcockm]

I can check both. Also, I just realized the spreadsheet is read-only by default. It looks like I could do a couple of things... I could either make it editable by anyone with the link I already posted (which is probably a bad idea?), or I could add your email address to it and it would send you an invite link to edit. It probably makes more sense for you to be able to edit the sheet too. I wasn't sure which things you were specifically looking for in the logs, but mentions of dynarec seemed like important ones to flag. Mostly I just figured it was way too much stuff to post here in the forum, and it would be easier to deal with in the spreadsheet.

Turns out the search feature is quite handy since it searches for text in any cell and highlights them when found. I did a search earlier for "dynarec" and found one more row that mentioned it stopped in the log which I hadn't flagged in that other column (so I added it). I also noticed you recently did an update to box86 related to libjpeg, and search lets me highlight just the games that referenced it. I'll try to check those out again with the latest box86 build soon. I imagine it will be handy for other things you might be looking for in the log dumps.

At least some of the games are freely available, like the Locomalito, Farbs, and a few of the Gamemaker games. I think at least one of the Lexaloffle games is free too. (I got all those in a Lexaloffle Humble Bundle with Voxatron.) But feel free to point me to games you'd like me to test if there are updates that might affect them. A good chunk of these logs came from tests I ran around January 22nd or 23rd, so I know they missed some recent fixes.

And yes, I was also shocked to see how many games I've bought through Humble Bundle over the years! :-o On a positive note, they will come in handy for testing. And I've already found a few that didn't interest me much on my laptop that are more fun on the Gameshell. I always liked SuperHexagon, but it's really great with the Gameshell controls. Still frustrating though!

 

[ptitSeb]

SuperHexagon is both nice and frustrating, for sure (and the music certainly help) !

In the mean time, I added 0F 2B opcode to both interpretor and dynarec. Funny things is that opcode was not only missing in the dynarec part, but in fact, it was never executed (on my tests at least).. That how dynarec works, it tries to convert an intere block, continue past conditionnal jump... But some conditionnal jump are always the same, and some part never executed...

Well, I noticed a few stuff:
First: you should get a native build of libpng12. I know it's not in most reo anymore, but using emulated version is a waste of cpu cycle. Same for libjpeg.so.8 (libjpegturbo is think). I still have issues o that last one with some error handling, but it should work for most stuff.

You should try to build gl4es. It's easy, and using BOX86_LIBGL env. var., you can point to to the libGL.so.1 built from gl4es and use it without any system change. That can provide an alternative OpenGL driver incase your mesa one have issue (it can happens, I have to use gl4es for some games on RPi4, even with Mesa driver).
For example: TokiTori. I have made it work on the Pandora, but only if I force OpenGL 1.5 (using LIBGL_ES=1 to have GLES1.1 backend used). Using OpenGL 2.0, it use some stuff not supported on gl4es and I get a crash when the game start.

When mark status as "Issue", I would like some more details on the issue.
For example, that Neko puzzle from lexaloffle. I tried it (fixed the missing dynarec opcode), and on the Pandora, it just work fine. I sse no issue, so I'm wondering.

The spreadsheet may need a git sha1 or something like that, to know what version of box86 was used for testing (or I should try to print that on box86 side too).

For email and stuff, why not. We can use private Message here for that.

 

[ptitSeb]

Also, I'm surprised FTL is marked as non-working. I tried it like yesterday, as part as some quick regression testing, and it was working fine, unless the version has been updated recently. So I just checked on GoG, and I see there is version 1.6.12 now. I think I tested on 1.6.9.. I'll update my version and re-check...

 

[ptitSeb]

So, I downloaded that version. Because the Pandora doesn't have things like systemd, I used this https://www.kernel.org/doc/Documentation/admin-guide/binfmt-misc.rst to be able to run x86 binary automaticaly (works fine, but the change is not permanent and needs to be redone at every reboot). So I launched the GoG Installer.


And install it somewhere (without enabling the shortcut or menu)...


After that, I went to the install folder, cd to game/data and directly launched FTL.x86 from there, with gl4es and using GLES2 backend...


And the game booted correctly.


So... working for me

 

[ptitSeb]

A more stuff:


Robin Hood is running. That's the demo and I don't know how to play it, but it does run, and the speed seems ok.

Also using ompadss SDL1.2 driver, Loki's version of Heroes of Might and Magic 3 also runs. There is still something wrong because I can only run on the Pandora. I cannot get it tu run correctly on the Pyra or an RPi4., I get dead-lock / crash. So probably something about mutex / thread is still a bit wrong somewhere.

I checked quickly Neko Puzzle also, and it's working perfectly on the Pandora. I need to check the licence of this one...

I also got some success with crimsonland. The gameplay was fullspeed, but got some difficulties with the wrapping of libjpeg...

And I'm still working on gtk wrapping. I use "Potatoman seek to the roof" as ginea pig for now. It's a flash game. It's almost loading. Almost... But not yet.

 

[Askarus]

Do you have access to Anno 1602?
I remember playing that one as a kid with my brother a lot.
Being able to play it on the Pyra would be a nice experience

It needs Wine, so it may not work now I think.
But as a future goal it would be a nice game I think.

 

[adcockm]

First: you should get a native build of libpng12. I know it's not in most reo anymore, but using emulated version is a waste of cpu cycle. Same for libjpeg.so.8 (libjpegturbo is think).

What would be the best/safest way to do that? For the x86 libs, I was less picky. I'm running Debian Buster on the Gameshell -- would there be any issues just grabbing this one from jessie? I poked around and didn't see any armhf versions of libjpeg8 though. There are versions at 6.2 and at 9, but the only one for 8 looks like arm64 only. The turbo versions seem to be at 6.2. If I just grab the individual files, will I also need to figure out and grab dependencies for them too? I'm just curious what's the best and easiest way to get them.

I did build gl4es, back when I wastrying to get mono games to work. It's still in my monolibs directory along with some other stuff. I haven't had it in the path for my box86 testing though. I haven't done a git pull and rebuilt gl4es either, and it looks like you're pretty active on that project too. Is that something I should try to keep built and in sync with box86? Are there certain OpenGL errors that it can fix? Or should I just try to use it with BOX86_LIBGL and possibly the LIBGL_ES=1 whenever I see errors that seem to be related to OpenGL?

I'm going to start working back through the spreadsheet, and I added a new commit column that will point to the version of box86 that I used. I also decided to just dump the full log file -- it's easier and that way you have the full context, plus it's all searchable from the main spreadsheet so it should be easier to find repeats of specific messages that way, even if it's just to identify all Gamemaker games or whatever. I'll also try to be more descriptive in the status. I'll also move Gameshell specific issues to a separate column, since things like the resolution may not be a problem on devices with larger displays. I don't remember what was wrong with the Neko puzzle -- I know it was mostly playable, but there was something.

Also, I'm surprised FTL is marked as non-working.

I have the Humble Bundle version, and mine has never worked so far. I've never seen a splash screen or a menu screen and just get a black screen. It may be the display resolution on the Gameshell. Perhaps the screen isn't black, but I'm only seeing the 320x240 top left corner, which is black?

Here's what my FTL install looks like. It's pretty flat, and I don't think the licenses directory is needed but I didn't bother to delete it.

My shell script is simple too:

#!/bin/bash
export BOX86_DYNAREC_LOG=1
./box86 FTL.x86 > log.txt

Oddly, Humble Bundle lists both versions of FTL, but the download is identical. So I'm assuming it's the "Advanced Edition".

I see you got Crimsonland working too! I'll try that one again too. If there are specific games in the list you want me to try again sooner than later, let me know. Otherwise I'll just work through them as time allows, and in the order I like.

By the way, with the recent build, Pixeljunk Monsters Ultimate now gets past the main menu screen and seems fully playable. The menus are close to full speed when navigating, but the gameplay is quite slow. I didn't see any in-game options to turn down the effects or anything, so I'm afraid it might never be full speed on the Gameshell. Might be good on the Pandora though! (And perhaps the png/jpeg issue is slowing me down. I also noticed that ROM Check Fail is running faster. It's not quite full speed, but it's better than before. It seems to mostly slow down when there are lots of enemies/shots on the screen. I haven't updated any of these in the spreadsheet, but I'll do that soon.

 

[ptitSeb]

I have seen the new columns @adcockm in the spreadsheet, good.

Now, I looked at some stuffs in it, randomly. And I see, for "Baba Is You" for example, that you seems to be running on Software Mesa (in the log: "Renderer: llvmpipe (LLVM 7.0, 128 bits) - VMware, Inc. - "). That would explain why it is slow. Try with gl4es.. Use SDL_VIDEO_GL_DRIVER=/PATH/TO/libGL.so.1 it would be better than BOX86_LIBGL. I think it will fix some issues.
And yes, you should keep gl4es up-to-date along with box86. Most of the time, I update gl4es because I found something not working on a game that runs with box86. That why both project are active (well, box86 gets the more love for now, but I still have many things to do in gl4es too).

For FTL, this seems very similar to the one I have, so it should work. Try with gl4es, maybe that will be enough. Anyway, don't expect it to be "usable" on the Gameshell. In fact, the text and GUI is already not really usable on the Pandora with it's 800x480... So on 320x240... Still, it's good as a "technological demo".

For png12, yeah, version from older distrib should be good enough.

For libjpeg, I can probably do a fallback to 6.2 if 8 is not there, I think the ABI is the same.

 

[ptitSeb]

Do you have access to Anno 1602?
I remember playing that one as a kid with my brother a lot.
Being able to play it on the Pyra would be a nice experience

It needs Wine, so it may not work now I think.
But as a future goal it would be a nice game I think.

Anno 1602, I have to check, not sure. But yeah, Wine is not supported for now, and I'm unsure I'll work on WineBox.