DOSBox Staging 0.79 update

[nemo93]

Full changelog at this location: https://dosbox-staging.github.io/v0-79-0/

TL;DR: many improvements on the audio front where the SB16 will now sound exactly as it's supposed to, compressor to prevent clipping, etc. Inclusion of a nice mouse driver for Windows 3.1. Performance improvement for low-spec device (eg. RPi) and other graphical improvements (CGA, shaders, etc). Localization improvements and many others.

Script updated to include new required files and better default values for RPi devices.

• libspeexdsp-dev has been added as a new dependency.
• New required files (shaders, keyboards, translations, etc) from the resources dir are copied over the install dir.
• bump from "exp" to "opt".

[cmitu]

@nemo93 thanks for the updated script. I've left a few comments on it, looks fine otherwise.

One question about the default config - is openglnb recommended now instead of texturenb ? Haven't got a chance to test this setting on a RPI3, I know it works fine on a RPI4.

I'm ok with bumping it from exp to opt.

[nemo93]

@cmitu thanks a lot for your reviews and comments. I've pushed an update to reflect the changes. Also used the opportunity to promote Staging to "opt". If that's an issue please tell me.

Regarding openglnb vs texturenb the truth is that maintainers will drop surface/texture* in the future. Or at least rework them. Therefore all optimizations and efforts have been put to ensure opengl* is running fine on as many devices/configs as possible. This has been tested on both RPI3/4 with official Retropie images and OS. If you or any user face a regression on RPi3 this will be thoroughly investigated.

Thanks again!

[cmitu]

I've finally managed to build and run on a Pi3 and it works fine (with the default config).

One issue I've encountered during building from source is that ninja likes to max out the # of jobs to 6 (despite the man ninja promising that the default is #ofCPUs). This has a very high chance of maxing out the memory and crashing the compiler due to insufficient RAM. I wasn't able to complete a build until I've either added more memory or changed the build command to:

meson compile -j${__jobs} -C build

@nemo93 did you have any similar issues during building on a Pi3 ? Or did you use the Pi4 for 'cross-compiling' ?

[nemo93]

@nemo93 did you have any similar issues during building on a Pi3 ? Or did you use the Pi4 for 'cross-compiling' ?

Another good call. Well I'm the one testing on RPi4 hence no issue while building on that hardware. After checking with the core team member who tests on RPi3, it's definitely known that building on RPi3 takes much longer. Quote: "The big killer on the pi3 is the software scalar which uses a ton of macro-expansions; I remember that file alone takes about 6 minutes to compile w/ -O3 on the pi3, and will soak up a lot of memory." I've edited the script accordingly thanks to your input.

There's a PR which will have meson install to copy all of the resources files over the install dir. I'll have to edit the script once it's in.

[cmitu]

@nemo93 almost there :).

I've tested more the openglnb option on a Pi3 and it's not working correctly (on RetroPie). My guess is that testing on the Pi3 was done with a current RaspiOS (based on Debian bullseye), while RetroPie still uses the 'legacy' buster version. The difference is:

• bullseye uses the Mesa VC4 driver which supports both OpenGL 2.1 and GLES 2.0 on Pi3
• buster uses the proprietary Broadcom drivers which support only GLES 2.0 on Pi3.

Since dosbox-staging seems to be relying on OpenGL support for shaders and the opengl[nb|pp] outputs, they won't work properly in RetroPie on the Pi3. On my 1080p display, openglnb shows a tiny unscaled screen in the upper-left corner and the log shows there's no GL support detected:

2022-09-21 16:17:10.156 | SDL: version 2.0.10 initialized (RPI video and alsa audio)
2022-09-21 16:17:10.174 | CONFIG: Loaded primary conf file /home/pi/.config/dosbox/dosbox-staging.conf
2022-09-21 16:17:10.196 | RENDER: Using GLSL shader 'sharp'
2022-09-21 16:17:10.198 | DISPLAY: Initialized 1024x768 window-mode using Nearest-neighbour scaling on 1080p display-0
2022-09-21 16:17:10.226 | OPENGL: Vendor: unknown
2022-09-21 16:17:10.226 | OPENGL: Version: 0.0.0
2022-09-21 16:17:10.226 | OPENGL: GLSL version: unknown
2022-09-21 16:17:10.227 | OPENGL: Pixel buffer object: missing
2022-09-21 16:17:10.227 | OPENGL: NPOT textures: not supported
...

My suggestion is to replace the openglnb default for output with

if isPlatform "kms"; then
   iniSet "output" "openglnb"
else
   iniSet "output" "texturenb"
fi

and this will take care of future OS upgrades in RetroPie, while keeping current (buster) users unaffected.

Thanks so much for the support, sorry for nitpicking.

[joolswills]

Thanks for your work on this @nemo93 @cmitu

[nemo93]

@cmitu please keep on nitpicking! This is quite useful and helps to improve Staging. Thanks a lot for that. I've added your condition based on Pi model. I was unsure about the best style hence shout if not fine. Also this PR is not ready yet to be merged in as the PR improving the "resources dir" handling is still in review. I'll give you a nudge once it's there.

@joolswills anytime. It's a breeze thanks to @cmitu excellent testing and feedback.

[cmitu]

@nemo93 thank you for the changes, they're fine. Looks fine now, I suppose - as you said - the build changes for the resources installation have to land in a stable release, in order for us to take advantage of that. I've built the current main and the resources are copied correctly. Is there any intention to have the linked PR (now merged) also included in a future 0.79.1 ?

[nemo93]

Thanks again for all testing and feedback. The upcoming 0.79.1 is expected to land end of this week/quite soon. I'll update that thread as well as OP with updated changelog once it's there.

[nemo93]

@cmitu 0.79.1 has been released. We should be good now. I've updated the OP to reflect a bit more the changes. As a bonus there are plenty of "mapperfiles" added for those using a xbox-compatible controller. This means users will be able to play DOS games with just a controller which is definitely Retropie-friendly 😉

Thanks again for the time, testing and feedback.

[cmitu]

@nemo93 that was fast :). Re-tested again the installations and it's ok now, no more hiccups on the Pi3. Should be ready to merge (nudge @joolswills).

This means users will be able to play DOS games with just a controller which is definitely Retropie-friendly 😉

Hah, from a cursory look it seems the mappings have the Start + Select set to exit the emulator ? If yes, that's neat.

[nemo93]

Hah, from a cursory look it seems the mappings have the Start + Select set to exit the emulator ? If yes, that's neat.

That's right. Objective was to mimick the Retropie/Retroarch combo.

[nemo93]

Anything else I should do/you're expecting from me? Thanks!

[cmitu]

@nemo93 no, it's fine. @joolswills I think this is ready to be merged.

[joolswills]

Thanks everyone.

[joolswills]

This new version failed to build on the Raspberry Pi 1 due to the speexdsp meson wrap defaulting to enabling simd (neon). See https://github.com/RetroPie/RetroPie-Setup/pull/3590

[priiduneemre]

Just a heads up: this doesn't work OOTB on Ubuntu 18.04. Tested on an ODROID XU4, but should be the same for Raspberry Pi 3/4.

The newest version of meson available in the offical repos for 18.04 is 0.45.1, from March of 2018. I solved it by installing 0.61.5 manually via sudo -H pip3 install meson. Don't know the best solution here script-wise, just wanted to point that out.

The error, specifically:

meson.build:150:16: ERROR: lexer
os_family_name = {
                ^
...
meson: error: unrecognized arguments: -j3 -C build

Not sure if the latest meson for 20.04 supports given syntax/params; didn't have a chance to check.

[priiduneemre]

Just to add to my comment above, I also had to disable OpenGL support via:

-  local params=(-Dprefix="$md_inst" -Ddatadir="resources")
+  local params=(-Dprefix="$md_inst" -Ddatadir="resources" -Duse_opengl="false")

After that, the scriptmodule built fine on ODROID XU4 w/ Ubuntu 18.04.

I suspect the OpenGL issue is an ODROID XU4-specific one (the vendor files are wonky, maybe? no idea). Could not find an obvious way to get it to work with OpenGL enabled. At least it builds without it, though.

• Full logs for Meson issue: see here.
• Full logs for OpenGL issue: see here.

Regarding the Meson issue: looks like it probably wouldn't build on 20.04 either, since the BUILD.md for dosbox-staging says Meson >= 0.56, but the latest repo version for 20.04 is 0.53.2.

Finally, sorry for the thread necromancy. I will stop now :).