[DOSBox] official thread

quicksilver

@nemo93 do you have a working build script for dosbox-staging? I was able to compile it on my pi4 but performance was absolutely terrible, which makes me think that I did something wrong.

nemo93

hey @quicksilver! I'm on a pi3B+ (still) and I do nothing magic to build "Staging". I tested with 2 methods both described in the doc:

the recommended way:

$ git clone https://github.com/dosbox-staging/dosbox-staging.git
$ cd dosbox-staging
$ ./scripts/build.sh -c gcc -t release -m lto

the "good old way":

$ git clone https://github.com/dosbox-staging/dosbox-staging.git
$ cd dosbox-staging
$ ./autogen.sh
$ ./configure (./configure --help for a list of available options)
$ make -j2

You can enable/disable some features if needed by passing a list of arguments at the ./configure step. Also I consider you have dependencies already installed. To be sure you have all necessary packages:

sudo apt install libsdl2-2.0-0 libsdl2-net-2.0-0 libopusfile0

or

sudo apt install -y $(./scripts/list-build-dependencies.sh -m apt -c clang)

On a PI3B+ (stock) I really have decent performance in most games. Even Tomb Raider (when it works) runs at 15-20fps at medium settings. Rayman is fullspeed with no tearing. Same thing with many other "2D" games.

You could give a try to the DOS/32A extender to see if it makes a difference. Everything you need is described here and a compatibility list can be found at this location.

Which steps have you been through to compile yours? Also what game(s) are you testing with?
Hope this helps!

quicksilver

@nemo93 thanks for the reply, im trying this on my pi 4 to see if performance is better than dosbox-svn that is included with retropie. Because of the way the display drivers work on the pi 4, performance for dosbox has actually decreased compared to the pi 3. Haven't had any performance issues with dosbox-svn on my pi 3 (minus the tearing issues).

nemo93

hey @quicksilver! I was willing to give you a nudge provided there were some improvements lately on the pi4 front with "dosbox-staging". I've updated wiki to share some hints especially for pi4 etc. I'd appreciate if you could give another try please? In short, you need to compile against the latest master and ensure you fine-tune each game mostly by setting a fixed amount of cycles. Failing to do so will have the game(s) run in "slideshow" mode. Still not perfect but I do have at least the same perf level as on pi3.

quicksilver

@nemo93 Im not sure I have as great a need for this as I once did. I have dosbox-svn running with great performance on my pi 4 now (much better than my pi 3). If there is a automated build script for this I would be happy to try it out but for now im pretty content with dosbox-svn.

VictimRLSH

@quicksilver Box86 is giving great performance for x86 Linux, and I finally got Bochs going (not easy) as well. Bochs is still a bit slow with Win98 and XP, but you CAN install things into the virtual machines and then grab any assets you need from those installs.

shaun57

Hoping one of you DOSBox experts might be able to help..

I'm struggling to get any of my flight sims (F-117A, F19 etc) to recognise my Thrustmaster USB joystick when it's configured as JS1.
The problem is that I really need my arcade cabinet controller PCB to be JS0 for other systems, and when I plug in the Thrustmaster after the PI is booted it is assigned as JS1.

I've tried the joysticktype "axis4_2" option in the .conf file which is documented as "supports one joystick, second joystick used" and, according to runcommand.log, that does indeed pass the Thrustmaster (JS1) to DOSBox, but when the game is launched the joystick is still inaccessable.

I can get round this by using auto or axis4 and plugging in the Thrustmaster USB BEFORE I boot the PI, in which case it's assigned as JS0 and then works perfectly in the games.

Am I missing something ?

If I'm not then the ideal solution for me would be if I could temporarily swap the controller PCB and Thrustmaster JS values (JS0->JS1 and JS1->JS0) in the .sh or .conf file and then revert back when the game exits. I'm no Linux expert though so no idea if that's possible ?

quicksilver

@shaun57 maybe this would help? https://github.com/meleu/RetroPie-joystick-selection

shaun57

@quicksilver thanks I'll have a look at that

quicksilver

Though on closer look that may be only for retroarch emulators...

VictimRLSH

@quicksilver said in [DOSbox] official thread:

Though on closer look that may be only for retroarch emulators...

Wasn't there an experimental libreto core for dosbox?

quicksilver

@VictimRLSH performance is very poor last I tried it out, even on the pi 4.

VictimRLSH

@quicksilver said in [DOSbox] official thread:

@VictimRLSH performance is very poor last I tried it out, even on the pi 4.

I've noticed that DOSbox on the Pi 4 is a let down in general and in many cases worse than a 3B+. Once I get more skilled in compiling and learn a few more tricks and I can try recompiling it to see if I get better performance than what has been packaged. I've noticed with Bochs it works a bit better if you compile it yourself instead of just install the package from the repository. Bochs is too slow to run games at all really, BUT is a great way to get a Windows game installed so you can mine the assets for ports.

quicksilver

@VictimRLSH I have another thread around here somewhere with a method to improve dosbox performance on the pi 4. Once you make the proper changes, performance is better than on a pi 3. I'll try to find the thread and post the link when I have a sec.

nemo93

Quick update given dosbox-staging keeps on adding features amidst other improvements. The upcoming 0.76.0 release will bring major GUS (Gravis UltraSound) improvements as well as other audio refinements.

0.75.1 is only a small release squashing few bugs (see release note) as well as other small changes:

Add support for binding more controller axes
64-bit Windows builds
Log base memory address (for Cheat Engine)

Also on the pi3/pi4 front especially, there's a dedicated branch with a scheduler-like addition allowing to unleash the number of allowed cycles on a stock pi4 for instance. Games like Fade to Black runs at full speed at higher resolution. Many other games run at fullspeed (or close to that) now.

ecto

@nemo93 Wow I've read through your contributions to the pi4 build, the wiki and the release notes. This really sounds like a big step! Thanks for your dedication!
I've been an avid DOS gamer in the 90s, so my Retropie was always equipped with a great library of DOS games and custom made startup scrips for MIDI output selection etc...

I was a little bummed with the performance of the pi4 in this regard until @quicksilver's workaround (btw. thanks for that, too)! Now it seems SDL1 and dispmanx should work again as they should (see How to keep 4/3 aspect ratio in Daphne games ?)

I haven't tried it yet due to time restrictions, but what would you all think: should I update to Staging or stay on SVN for the time being?
I think Staging sounds too good to be true, but I fear I have to rework quite a bit (although my startup script should work with Staging, as it just generates a conf on the fly which is passed over to dosbox). I fear that I have to edit all these conf files for the cycles count by hand...

Also, can Staging be installed though the retropie-setup script or do I have to do it by hand?

Thanks and happy gaming!

nemo93

hi @ecto ! I'd say for the time being it's safe to stick with SVN. The many improvements on "staging" have not all been merged into the master branch and some are still being tested (like the Pi speed/cycles improvements). Also fluidsynth has just been implemented and for now it's not really easy to use with Retropie. So if you got some General Midi games they might not work out-of-the-box.But it's getting closer...

I'm using staging for more than 6 months now and it's my default choice since then for anything DOS. My testbed is made of roughly 250 games (from early CGA stuff up to the more complex 3D games) and I'm not the only one testing. Meaning we'll have quite some tailored conf files to share for various devices and for many games. I already did share some in the wiki but I do hope to share even more in the future.

Like with many things we need to be a bit more patient as this version of DOSbox is likely to become a "must have" at some point (this is my expection at least!). For that reason there's still no script bundled with the retropie-setup but I have one ready that I could share if you want.

Once staging will be ready I'll raise a PR for it to be included into Retropie if that makes sense (I'd like to not have too many DOSbox forks or people might get confused).

ecto

@nemo93 Thanks for this very informative reply! I'll stick with svn with the patched sdl1 library for the time being!

Btw. I'm using a mix of munt and fluidsynth for midi under dosbox, as not everything plays nice with fluidsynth. ;)

nemo93

Another quality update from the DOSBox Staging folks who come with a 0.76.0 release. Feel free to check the release note) for list of changes. Few highlights below:

More Gravis UltraSound emulation improvements
new built-in GLSL shaders
Built-in MIDI support via FluidSynth (2.x)
Audio pop and click prevention
...

I'd say the compatibility, performance and quality of life improvements have me stick to that fork. For those interested to give a try there's a script to have it integrated with Retropie on the Wiki (no support provided at this stage). MT-32 integration is lacking but it's being looked after as well as many other interesting topics.

ecto

@nemo93 This sounds really exciting! I have a few questions though, before I start the tranition:

as MT32 is not integrated, is it posible to use Munt externally (the way through an Alsa port)?
how are the cpu cycle settings now working out? Does every game need a separate setting?
This is minor: does Staging behave the same way as Dosbox when started through the command line with extra overriding config files? I'm using a custom starting script, but changing that should be no problem...
Cheers!