[DOSBox] official thread

quicksilver

Has anyone managed to get dosbox-x up and running on a pi 4? Very curious if it would be possible to run some windows games using it...

Lolonois

@nemo93 and other dosbox-staging users here:

Recently their build process has been changed to meson.
I adapted the dosbox-staging.sh scriptmodule in the Wiki of dosbox-staging.

@mitu what is the process/are the quality gates to get the script as experimental into RetroPie-Setup repo?

Cheers

mitu

@mitu what is the process/are the quality gates to get the script as experimental into RetroPie-Setup repo?

You can submit a PR, IMHO it would be preferable to take into account the available dependencies (newer fluidsynth libraries are not available in the distro) and an optimal configuration needed for each platform (i.e. has anyone tested this on a Pi3). The other Dosbox packages have also a starting script which start timidity for MIDI support, the starting script can maybe leverage that.

I can certainly review it, I think @BuZz already tested it and may have the basis for a new scriptmodule for dosbox-staging.

I see there's a special branch used for building in the Wiki script, are the changes now in the master or stable branch ? What is the upstream maintainers' take on the packaging - is it preferable to ship a release version or build from master/main ?

nemo93

@Lolonois thanks for the update! Much appreciated. I do confirm script does work 100%. There might be some (small) adjustments to be made but it's more than ok.

@mitu
some testing still required but the current version of Staging (master branch) might be a nice addition to Retropie. Staging does now come with full built-in GM and MT32 support, SDL2 and many other quality of life improvements. For those not willing to go the "libretro" route then Staging could be a very fine alternative for their Pis.

To your other points: Fluidsynth (GM) and Munt (MT32/CM32) support is built-in meaning no dependencies required. Devs were willing to support only the latest libraries version hence why these are built-in. The default configuration is roughly the same as other forks. Devs are testing on Pi3 and other+@Lolonois+myself on Pi4. My starting script is a very thinned-down version compared to "SVN" given I don't rely on Timidity but solely on Fluidsynth and Munt for MIDI playback.
=> Does Timidity come as a mandatory requirement here?

If you or @BuZz already have a scriptmodule (or a PR) for that fork please let me know and I'll be glad to assist.

The branch to go for is definitely master. The special branch you refer to comes with specific parameters and optim especially intended for Pi4. That branch is not ready yet to be merged into master. I'd say it's preferable to build from master but I don't want to step on anyone's shoes here and question will be asked to maintainers directly.

mitu

@nemo93 said in [DOSbox] official thread:

To your other points: Fluidsynth (GM) and Munt (MT32/CM32) support is built-in meaning no dependencies required. Devs were willing to support only the latest libraries version hence why these are built-in. The default configuration is roughly the same as other forks. Devs are testing on Pi3 and other+@Lolonois+myself on Pi4. My starting script is a very thinned-down version compared to "SVN" given I don't rely on Timidity but solely on Fluidsynth and Munt for MIDI playback.
=> Does Timidity come as a mandatory requirement here?

No, Timidity is not mandatory, but we might need some soundfonts installed (and then configured). The .conf that comes with Dosbox right now has the MIDI port configured for Timidity+ALSA, should be replaced/configured with the staging internal MIDI support instead.

The branch to go for is definitely master. The special branch you refer to comes with specific parameters and optim especially intended for Pi4. That branch is not ready yet to be merged into master. I'd say it's preferable to build from master but I don't want to step on anyone's shoes here and question will be asked to maintainers directly.

There are pros and cons to using master vs a release tag.
My preference would be to lock on a release version for a RetroPie scriptmodule. It makes it easier to track new features and the (unavoidable) bug reports would be easier to triage and diagnose when reported against a specific branch or version.

On the other hand, tracking master means new additions (and bugfixes) are easier to test with a simple 'update from source' in RetroPie.

Thanks for chiming in.

nemo93

@mitu thanks to you.

The above makes total sense. After a quick chat with one of the maintainers it might be better to indeed offer users with 2 options. One would be to get a specific tag/release binary whenever the "Install from Binary" is chosen. The other would get user to compile the latest master whenever "Install from Source" is picked up. I believe it's something already in place for other "cores" but I haven't checked recently. Would that be an acceptable solution?

mitu

@nemo93 Usually a scriptmodule wouldn't use different versions of the upstream project depending on binary vs. source installs. The binaries are just source installs packages stored on the RetroPie's server that can be installed from the setup script.

We have something similar for EmulationStation. It has a different package for the master branch (emulationstation-dev), while the regular emulationstation package builds from the stable branch.

Since we already have 4 Dosbox related packages in RetroPie (upstream, a SDL2 fork, a quasi-abandoned Libretro fork and the Dosbox Pure Libretro core), adding another 2 more Dosbox packages would be a bit much.

nemo93

@mitu Thanks again for answering my many questions. Let's do as follows:

stick to master branch only. Staging is rock-solid and I haven't got a single issue with it for many many months. Few issues I got are games-related. Also better from a maintenance standpoint. Not sure how you promote an emulator from "experimental" to "optional" though?
decide of a default config. To prevent any issues and to provide best experience to new users the default config file is pivotal. I trust I've nailed it after countless testing sessions (pi3 and pi4) and I'm quite happy with the one from the wiki. With Staging the most important is to ensure the cycles = parameter is set to a value (eg. 25000) not leaving it on auto.
=> I recall there might be some Retropie command to pass to the scriptmodule in order to tweak a conf file after it has been generated. This to ensure some values are being properly set. EDIT: should be the iniConfig + iniSet functions.
decide if a soundfont (fluid?) should be considered a dependency. Configuration of anything MIDI-related (General MIDI via Fluidsynth and MT-32 via Munt) is actually quite simple. You just need to set which synthetizer you'd like to go with and that's all. No need to fiddle with ports or Timidity. All you need is a soudfont (typically .sf2 file) and/or mt32 roms. The former is available from multiple sources online (or from your GNU/Linux distro) where the latter is trickier given mt32 roms are not free.

I'll submit a PR in the coming days if you agree so we'll be able to discuss further on github. It will be roughly the same as from the wiki, I just made a few more tweaks. Any questions please let me know.

Note: I totally agree regarding the multiple DOSBox forks available, it's important to keep number to a reasonable level. I'd just don't want to comment too much on that as I'm partial but perhaps the SDL2 fork you're referring to (from DuganChen) could be dropped at some point as Staging does bring similar features (+more). Staging is in active development.

mitu

@nemo93 said in [DOSbox] official thread:

I'll submit a PR in the coming days if you agree so we'll be able to discuss further on github. It will be roughly the same as from the wiki, I just made a few more tweaks. Any questions please let me know.

Sure, you can go ahead and submit it. A few notes on your existing script:

a new scriptmodule has to declare a new variable pointing to the repository (rp_module_repo ) and gitPullOrClone will automatically use it. This a very recent change in the build scripts - take a look at how dosbox-sdl2 is configured.
No libs copied to /usr/local/lib. If you need something that's not in the distro (i.e. libfluidsynth), copy it to the install folder ($md_inst) and add a .sh wrapper that extends LD_LIBRARY_PATH before running the binary to pick it.
the inst function should just list the output files and they'll be copied to to $md_inst. No need to manually copy files.
You should include some additional files besides the binary, I like to include a README and/or the licensing info present in the distro.

=> I recall there might be some Retropie command to pass to the scriptmodule in order to tweak a conf file after it has been generated. This to ensure some values are being properly set. EDIT: should be the iniConfig + iniSet functions.

Yes, but be aware that iniSet sets the value only if it's missing from the file - this is intentional to not override any user set option.

nemo93

@mitu thanks again. Script edited to take all above points into account. Works very fine now on my setup. Also PR just submitted. Happy to discuss further. Thanks to all maintainers, testers and to @Lolonois for giving me a boost :-)

On another note the next stable release of Staging is around the corner and should be tagged 0.77. Some features have already been merged to master branch. In (very) short many improvements have and are still being made to MIDI playback (including lower latency via dedicated thread) and build system migrated over to Meson. A proper announcement will be sent over once everything is ready.

There's also a new DOSBOX-X release. As always plenty of additions and improvements added. On the Libretro front DOSBox Pure keeps receiving updates as well. I'm afraid I have no time to push further my testing on that "core" hence any feedback appreciated.

Lolonois

Ah great, thanks for pushing the dosbox-staging scriptmodule forward quickly @nemo93 @mitu @BuZz :)

jamrom2

@lolonois Hiya... yes my attempt to build from source crashed on the Meson error. how can I upgrade to the required 51 from 49.2?

Thanks!

update: I found this... but I'm running a Pi3B+. Does it matter? I just did an image of my build, so I'm ok to mess around with my build to test.

https://www.reddit.com/r/RetroPie/comments/egjqw2/how_to_manually_compile_newest_mesa_drivers_for/

mitu

@jamrom2 said in [DOSbox] official thread:

how can I upgrade to the required 51 from 49.2?

Are you using a recent Raspberry Pi OS (Buster) release on your Pi ?

jamrom2

@mitu good question... I'm using the latest build of Retropie... 4.7.1. That's about all I know about what's running the background.

So ... I'd like to say yes, but I honestly don't know.

Can I run a command to tell me?

mitu

@jamrom2 The information is shown when you start the RetroPie-Setup script

jamrom2

@mitu lol... oh.. that one...

Yes, it's Buster

mitu

@jamrom2 Make sure your OS and packages are. up-to-date. What's the output of:

apt policy meson

It should show something like:

     0.52.1-1~bpo10+1 500
        500 http://archive.raspberrypi.org/debian buster/main armhf Packages
     0.49.2-1 500
        500 http://raspbian.raspberrypi.org/raspbian buster/main armhf Packages

jamrom2

@mitu
Looks like 52.1 needs to be installed

meson 1.jpg

jamrom2

@mitu does this sound right? Or is there another command to get it done.

https://mesonbuild.com/Quick-guide.html

Lolonois

@jamrom2 sudo apt-get install meson, will also pull in ninja-build and python3 (if absent).