[DOSBox] official thread

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.

jamrom2

@nemo93 Thanks for the detailed reply. From all the testing I've done so far, Staging seems to be the better of them all, with SDL2 right behind it and truthfully, almost impossible to see any difference between them. They both run really well.

I've tested games like Aces of the Deep, Aces over Europe, Team Yankee, Duke Nuk'em 3D. They run good in core based DosBox but get really beat-up in Libretro based Dosbox. Sound issues, frame jumps, etc.

I think the extras like overlays and shaders will just have to wait. I understand the reasons, it's emulation and not native hardware, so it's expected to take performance hits when you turn on all the extras.

I was going to install lr-dosbox-core, but I don't see a step-by step install for it... unless I missed it. It's fine, because if there is no performance gain over the other libretro cores, I won't use it anyway.

I'll stick with Staging and play around with adding in a shader for the CRT effect. I'll see how it effects performance and decide from there.

Thanks again for the great response. I agree... the knowledge is incredible and we all learn by asking. It's a great community!

BTW... mitsu actually sent me that link for the shaders... I just haven't played with it. Now that I'm decided on my DOSbox direction, I'll mess around like I mentioned.

ecto

It's time for another status report from me ;)
I have now made the change to full kms and while I had some problems with sound, which I now reverted back to bcm, I'm happy to have made this step.

Now, on to my favourite topic: dosbox.
I once again trieddosbox-stagingwith the new build script from @nemo93's repository. That all went well, thanks for that!
It's nice to have the build-in MT32 emulation and the possibility to use shaders (zfast_crt especially) is a really great development. But sadly I still have some problems with different games (everything tested with 35000 cycles):

Ultima VII with MT32: The music in the start screen crackles, when the titles fade in. When I tried it with my external munt demon it just works. Even with shaders (nice!). Maybe running munt externally keeps it off of the cpu dosbox is running on? Idk. I coudn't find options for MT32 emulation, like a higher buffersize or enabling dedicated thread for it.
Wing Commander IV: (or maybe it's the svga resolution) doesn't like dosbox-staging, I guess. Crackling sound everywhere, and somewhat slow video output. I tried different outputs (gl, gles, software) and machines (vesa_nolfb, svga_s3), but it made no difference. It got better when I randosboxwithXINIT, but then my keyboard and controller wouldn't work at all.

I hadn't time to test more, but as it seems, I will still stay withSVNon higher resolution games. But using the shaders on those low-resolution games together with pixel-perfect scaling is a great feature. I will test more games in the weeks to come!

PS. have I made everything right: the shaders only work when output=openglppis set?

jamrom2

@ecto How did you get the shaders to work. I've been playing around with this... but not 100% focused on it.

I'd like to try it as well.

I think between the two versoins (SVN and Staging) there are some really good options. What games did you try?

ecto

@jamrom2 I used output=openglpp and glshader =/path/to/shader.glsl. Shaders can be found here or you use the build-in ones.

I have lots of games (The MSDOS-era is where I grew up in). For starters I would recommend the Origin games (Ultima, System Shock, Wing Commander, Strike Commander, Privateer, Crusader). Other great games are Fallout, Pro Pinball games, Dungeon Keeper and Heroes of Might and Magic to name a few. Very good are also the first Alone in the Dark games.
There's also Lucasarts, but those adventures are probably best played with ScummVM.

Overall SVN seems to have the better performance (at least for me and especially at higher resolutions), but staginglooks soooo much better. It's no easy call.

jamrom2

@ecto can I pick your brain on this one a little...

I am using Staging.

I adjusted the dosbox-staging.conf file located in /opt/retropie/configs.hdmi/pc to match what you have in the [SDL] and [render] areas.

output = openglpp

I then placed the shader (I used zfast_crt.glsl) in the opt/retropie/emulators/dosbox-staging folder and adjusted the statement in [render] to this...

glshader = /opt/retropie/emulators/dosbox-staging/zfast_crt.glsl

Nothing shows... so I am definately missing something in the config file. Seems simple enough, but I think I'm writing the location wrong.

Thanks!

ecto

@jamrom2

Here are the important (?) parts of my dosbox-staging.conf

[sdl]
fullscreen       = true
display          = 0
fullresolution   = desktop
windowresolution = default
output           = openglpp
texture_renderer = opengl

[dosbox]
language          = 
machine           = vesa_nolfb
captures          = capture
memsize           = 16
startup_verbosity = high

[render]
frameskip          = 0
aspect             = true
monochrome_palette = white
scaler             = none
glshader           = /opt/retropie/emulators/dosbox-staging/zfast_crt.glsl

Maybe that helps ;)

nemo93

@ecto thanks for reporting back. Very useful. Whenever there's sound crackling that means you have either not enough cycles or too many. On either Pi3 or Pi4 I consider the maximum number of cycles you can set to be 35.000 (it's possible to go beyond that point on Pi4 using a specific dev branch). To me setting 35.000 should be done only for the most demanding games and usually this is where sound will start crackling. Also SVGA will require more processing power than VGA so try the latter in case of issue. As a rule try to stay under 35.000 whenever you can.

In Staging MT32/Fluidsynth should run on their own thread automatically. Decision has been made to hide as much options as possible from users in order to expose only the most relevant ones in the conf. To keep things tidy and efficient.

Ultima VII: I'm a bit surprised you had to go up to 35.000 cycles. Can you try with far less than that? I'm using 10.000 cycles here and it looks ok. Anything in the range from 9000 to 11.000 cycles should be good for more recent Ultima's. It's fine to disable EMS as well.
Wing Commander IV: required a beast back in the days especially if you wanted to play in "hi-res" mode which is SVGA. This one should require more than 35.000 cycles to run smooth. Apparently it should be fine in the range 50-60.000 cycles. A bit too high even on a Pi4. Try VGA instead to see if this runs better and don't go above 30.000 cycles.

@jamrom2 I believe @ecto provided everything :-) Just keep in mind you can set options/functionalities on a per-game basis. You need to rely on an opengl output for shaders to work.

ecto

@nemo93
You are right, with Ultima VII, I didn't need 35000 cycles there. I've settled for 16000, which is more than enough (it doesn't hurt to let the Avatar run a little faster). ;)

But very good news: I think I just had a small breaktrough! In all (?) VGA (320x200) games that had some sort of sound crackling before, I completely got rid of it by setting

[mixer]
blocksize = 512
prebuffer = 200

This is a bit counter intuitive (according to the documentation), but it works. Also, for most of those games, the sweet spot of cpu cycles is (as you said) more around 20000 than around 30000.

Now I still have to find out, why SVGA (640x480) games are so much worse on stagingas in comparison to SVN, where those run fluently! I tried different ones (Wing Commander 3+4, The Settlers 1+2, Terminal Velocity, Dungeon Keeper...) and there is always crackling sound even with my new settings from above. The crackling gets really bad, as soon as I move my mouse, so maybe there is a connection?

jamrom2

@ecto I'm not sure what I'm doing wrong with this, but no matter what I put in those SDL settings, I get either box in the middle of the screen as big as a birthday card, or I get a box in the lower left-hand screen the size of a business card.

Is there a full write-up on making all this work? I must be missing a step somewhere.

ecto

@jamrom2 The one in the top left corner of the screen sound like SVNSDL 1 scaling maybe. I think the easiest way for proper scaling is to follow these instructions.

@nemo93 Do you know if it is possible to run dosbox-stagingwith XINIT:? I tried that before, but I had no keyboard/mouse input. But the performance looked ok on first glimpse.

nemo93

@ecto said in [DOSbox] official thread:

XINIT

I don't know unfortunately. I'm only using the base Retropie image without any tweaks or extras like a desktop env. Your issue remind me of an "interesting" problem discovered not long ago which has DOSbox to query like crazy the event queue (read here for more details). It should be merged soon in master and will bring lag improvement as well - hopefully on low-spec devices too! You could already try to compile the branch kc/synchronize-polling-1 if you can't wait.

@jamrom2 first can you try the settings available from the wiki page please? Especially those about the "default config file". If you're relying on a standard Retropie + Pi4 those settings should work out-of-the-box for you with no display issue.

ecto

@nemo93 Thanks for the tip! I'll try that one out (I am compiling as I type)

But here is another interesting discovery I made just now: I started stagingwith the XINIT:command, and -as expected- the keyboard doesn't work. BUT I was able to use the mouse! So I checked some SVGA games (Wing commander 3+4, X-Com3, Settlers) and there was no sound crackling or laggyness at all! So if just the keyboard would work, that would be the best dosbox experience, I think?
I will report back in a few minutes after testing kc/synchronize-polling-1

EDIT
Nope, still crackling audio on mouse-movement (I only tested X-Com3 and WC4).

jamrom2

@nemo93 Hello... sorry to be a PIA with this... but a lot of this just doesn't make sense.

So here is what I did/have so far.

I removed all other instances of Dosbox (lr-, SDL, Pure) and reloaded only DosBox and Staging.
I looked at the instructions and checked my +Start DOSBox-Staging.sh files located in /home/pi/RetroPie/roms/pc and checked that on the first line it specifies..

if present
/home/pi/.config/dosbox/dosbox-staging.conf
will be used as primary config

I then created the required dosbox-staging.conf file and place in the in location specified above. In that file, I places all the parameters listed in the pull-down of the "default config file" section.
Now I switched over to my games... I still use .sh files to point to my game roms. Not sure if that's correct anymore because that is what used to be required to run Dosbox games. No where does it says how to setup the games to run, other than requiring individual *.config files. Having said that....
I will use Aces Over Europe (aoe) as my example... in my folder ./roms/pc resides all my .sh files. so aoe.sh is as follows... minus the "bin/bash" command at the top.

/opt/retropie/emulators/dosbox/bin/dosbox -conf "/home/pi/RetroPie/roms/dos/aoe/aoe.conf"

This tells me that dosbox is running the game, not dosbox-staging. No where does it say anything about pointing to dosbox-staging other than what is mentioned in my first step mentioned above.
6. I then open the ./roms/dos/aoe/aoe.conf file which is only has the following... my joystick mapper file location, the midi and autoexec to run the game.

[sdl]
mapperfile=/home/pi/RetroPie/roms/dos/aoe/aoe.map

[midi]
mpu401 = intelligent
mididevice = mt32

[autoexec]
mount c /home/pi/RetroPie/roms/dos
C:
CD aoe
AOE.COM
EXIT

Ok.. now I start the game and in the runcommand launch choose dosbox-staging? It points to DosBox SVN. I switch to DosBox, it points to Dosbox SVN.

So where in all this, aside from the statement in +Start DOSBox-Staging.sh, does Staging actually get called to start running. Why do I even need Dosbox loaded.

I don't like coming to someone with a laundry list of problems. I can offer this as a solution. I'd like to write-up clear instructions on how to get Staging working, for laymen like me... some of this stuff is a little verbose and technical. So if you help me getting it running, I'll do a step by step Staging build process... including shaders.

Thank you.

almost forgot... if I change the aoe.sh file to read.. /opt/retropie/emulators/dosbox-staging/dosbox -conf "/home/pi/RetroPie/roms/dos/aoe/aoe.conf"

Dosbox-staging runs... but I get the small box in the lower left corner, no shaders.

ecto

@nemo93 OK, I have great news regarding XINIT:

There seems to be a bug in staging. It seems that the keyboard doesn't work as long as it is running in fullscreen mode (either with fullscreen = true or when pressing alt-enter to enter fullscreen when running in windowed mode).

I have now the settings

[sdl]
fullscreen=false
windowresolution=1920x1080

in dosbox-staging.conf and it's really running great with xinit. No lag, no crackling, no tearing and full speed even with shaders! SVGA games like WC 3+4, Settlers or XCom3 are very much playable! YESSS!!

Now the only problem in windowed mode is that the screen is flushed to the top and the left. Using output=openglnbscales the output vertically, so it's "only" flushed to the left,so it's not perfect yet.

I think I will post the issue with the non-working keyboard in fullscreen mode on the github project page. Maybe something can be done about that. The problem doesn't exist in SVN.

PS:
I think I can even get the Crusader games running! :D But there are still some adjustments to cycles needed.

EDIT
I just submitted a bug-report to the git project page. Let's see what comes from that.

jamrom2

after roughly 4 hours of playing around with this... I'm slightly better than I was before.

I removed all known traces of anything DOSbox related to all versions. Went back and reinstalled Staging from source. Checked that I had the correct dosbox-staging.conf placed in the .config\dosbox folder.

Installed XINIT as suggested and updated my emulators.cfg to reflect the new choice.. and removed all others. So all I have is Staging as the choice for DOS.

dosbox-staging = "XINIT:bash /home/pi/RetroPie/roms/pc/+Start\ DOSBox-Staging.sh %ROM%"
default = "dosbox-staging"

Reduced the aoe.conf to nothing but the joystick mapping and autoexec paramters...

Finally... In the main dosbox-staging config file. I have the following for the more important display parameters...

[sdl]
fullscreen = false
display = 0
fullresolution = default
windowresolution = 1920x1080
output = openglpp
texture_renderer = opengl
capture_mouse = onstart middlerelease
sensitivity = 100
waitonerror = true
priority = higher,normal
screensaver = auto

[dosbox]
language =
machine = vesa_nolfb
captures = capture
memsize = 16
startup_verbosity = high

[render]
frameskip = 0
aspect = true
monochrome_palette = white
scaler = none
glshader = /opt/retropie/emulators/dosbox-staging/zfast_crt.glsl

All I get now when I run a game is the middle of the screen is the game, shrunken to maybe 1/4 the size.

I'm at a total loss of analytical skill at this one.

ecto

@jamrom2 Try output=openglnb. This will scale the picture at least to the full height of your screen. Using stagung with XINIT isn't working correctly atm...

nemo93

@ecto thanks again for reporting and for providing detailed feedback. Much appreciated and I see the bug you discovered is already fixed and about to be merged in. Your "feeling" about using XINIT proved to be very interesting. For now it's a bit too specific (+ you are on KMS) but I'll keep my eyes peeled. Feel free to keep on testing. At some point we may add a XINIT section to the wiki for those who want to give it a try. On my end though I'd prefer Staging to deliver best results on the console without any extra as it's the way Retropie does operate. I do have very good perf on my Pi4 with almost any games I've tested so far. It just requires some patience to be able to fine-tune the games conf files.

Speaking of conf files... @jamrom2 you're next :-) Don't worry about asking questions and seeking for help. That's what this forum and this thread are all about. Let me ask you to start over again and play by the book. It's fine for you to have already one (or several) of other DOSbox flavors installed (either SVN or any of "libretro" cores). Then follow the guide from the wiki to the letter. It will have you adding a new script which will compile Staging and create the required files for you. Read the guide to the end as it will show you how to tell Retropie to use Staging as the default emulator by editing <Retropie>/configs/pc/emulators.cfg.

At this point you should have a Staging binary, a default conf file under <Retropie>/configs/pc/dosbox-staging.conf and a launch script under <Retropie>/roms/pc/+Start DOSBox-Staging.sh. Do not touch that launch script and do not modify that default conf file.

All that's required from now on is one .conf file per game to tell Staging what to do - place these .conf file(s) in roms/pc. Under Retropie/EmulationStation/Pegasus, to run a game you'll have to simply point to that .conf file.

NOTE: even if .sh are indeed supported and other methods will allow you to run games, I do recommend the following simple approach: a default conf file + one .conf per game. That's all. The default conf file comes with default settings which will allow most games to run ok-ish and the game .conf file is there to overload (or to enforce) specific parameters allowing the game to run better/smoother. As a user you just need to edit that game .conf file located under your <Retropie>/roms/pc/ directory.

Let's use DOOM as an example. Because DOOM is awesome. Just create a doom.conf under <Retropie>/roms/pc/ directory and copy/paste the below:

[cpu]
cycles = 30000

[midi]
mpu401     = intelligent
mididevice = fluidsynth

[autoexec]
mount c /home/pi/RetroPie/roms/pc/games
C:
CD DOOM
DOOM.EXE
EXIT

Change the line mount c /home/pi/RetroPie/roms/pc/games according to your system and where you have copied over the DOOM files. That's it. Now from your frontend any time you'll run doom.conf automatically Staging will launch it with the above parameters. Should the game does have issue, all you need to do is to edit that very doom.conf file. Nothing else.

Hope this helps.

jamrom2

@nemo93 Thanks Nemo

I went through all of this from scratch to make sure I have it all covered properly.

Observations:

According to the first line of the installed +dosbox-staging wrapper file, the placement of the dosbox-staging.conf calls for it being in ./conf./dosbox Anywhere else I put it failed.
The games do not display in full-screen no matter what until I add in "XINIT:" to the bash statement of emulators.cfg file in /opt/retropie/configs.hdmi/pc
When I got it running... it was woefully slow, regardless if the shader was on or off.
I like the one config for main, and other configs per game. That's a really good idea.
The .sh method would work as well, and it does, as long as you edit it to remove the setting you don't need, and keep the autoexec area.
After all this, and getting it running... I fell back to regular DosBox as it seems there is still work needing to be done. I have a Pi3b+ so most likely I'm restricted on the performance this needs to run right.

Thanks,

Jam