[DOSBox] official thread

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).

jamrom2

@lolonois thank you. It's compiling now.

jamrom2

@lolonois stopped here... been over an hour. Is this a problem? Am I missing something else?

Update: never mind... I forgot it's better to run the compiling scripts in the unit and not remotely. It blew through the build in 10 min. All good.

jamrom2

@nemo93 I have a question about this Staging version... and I'm sure I'll get the Idiot of the Year award for it.. lol.

I have the SDL2, Pure, and now Staging versions all loaded. Plus the lr-dosxbox as well... but that's no where near the performance of the other three.

So what is the difference between the three versions? Staging seems to be the best, but I'm not seeing any difference on games like NHL 96, and stuff in that era. I realize my little Pi3b+ should probably be upgraded to a 4 for better overall speed and such. But I was curious as to what makes these versions different.

Also, I'd like to run some shaders for the CRT look of the late 80's. How do I do that with these?

Thanks for all the work on Staging... it's very good.

nemo93

@jamrom2 it's always better to ask questions, to learn new stuff and to try to understand what's going on. Keep shooting questions, there is a lot of knowledge around that forum with plenty of wise fellows.

I haven't done any new testing recently with lr-dosbox but when I did I got poor performance on pi3/pi4. If I'm not mistaken this is more or less a straightforward port of "SVN" and I'm not even sure this libretro core is still being maintained. There's @RealNC 's libretro core as well which brings many features and of course "Pure" but I haven't tested it yet. All those cores benefit from RetroArch quality-of-life improvements like an easy-to-use GUI, controllers mapping, etc at the cost of a slight overhead which can decrease performance a bit on some lower-end devices like our beloved Raspberry Pi. Especially on some of the most demanding games (the 3D ones like Azrael's Tears, Quake, etc). That's why I prefer to stick to the "standalone" versions of DOSbox for now.

"SDL2" is a "standalone" version based on "Dugan Chen" 's fork. It's a great fork bringing lots of improvements the most important being SDL2 support which prevents tearing for instance. The only issue is that this fork is no longer maintained (last commit from Jan 2020). Staging is also a "standalone" fork which brings many features and improvements. On top of that the 2 maintainers (all credits to them) have done an incredible work of modernizing the whole codebase. This is no small task and they keep merging patches from "SVN" and adding features on a very regular basis.

The fact you don't see any difference in 3D games is mostly due to the limited power available on a Pi. Also even if there are differences in features etc all forks above do share the same foundation which is the "SVN" code base. A game might run - slightly - better on a specific fork but don't expect huge differences.

Upgrading to a Pi4 will help 3D games to run better given the performance boost from the CPU but it won't be perfect. Keep in mind that it was very uncommon for DOS games to run at 60fps back in the days. Running a game at constant 30fps was amazing back then :-)

For shaders, I'm not 100% sure but DOSBox does use a specific format hence you can't rely on Retroarch's ones for instance. Some shaders have been ported though, you can find them at that page.