dosbox-staging, a 'soft' forking of DOSBox to work on advanced features has a first release

Installed from AUR, it replaces regular DOSBox.

How does it compare to DOSbox-ECE?


Last edited by Curupira on 6 May 2020 at 2:29 pm UTC

How does it compare to DOSbox-ECE?

ECE is not really a fork, but rather a collection of important patches (for users it does not matter, but it means ECE cannot improve on code inherited from SVN - unlike dosbox-staging, which is "proper" open-source project).

Out of patches distributed via ECE:

- We include pixel-perfect mode (this feature was removed from ECE; code author is dosbox-staging maintainer)
- We include a better version of CD-DA work (author is also dosbox-staging maintainer)
- Integrated NukedOPL already
- Scalers 4x and higher are not needed any more since glshader=sharp is integrated now
- We provide a number of features not available in SVN nor ECE (see changelog), most importantly moved on to SDL2

What we're missing from ECE:

- FluidSynth integration (we'll work on this for next stable release)
- MT-32 integration (in plans)
- 3dfx emulation (work is slowly starting)
- "Improved" PC speaker emulation - we won't integrate this, this work is unfinished, borderline broken

Other patches distributed by ECE are really trivial changes, we'll integrate them sooner or later ;)

Overall ECE is an extremely important project, as it kept alive these important out-of-tree patches for years - we're taking them, cleaning up, improving, and properly integrating into dosbox-staging code (one by one).

This new project looks very good! A lot of new modern features for Dosbox!

Hopefully this will better coordinate all the efforts from different DOSBOX variants into a single branch, and perhaps a prebuilt deb release for lazy Ubuntu folks like me?

I use this at the moment and has MT-32 support via munt.
https://code.launchpad.net/~i30817/+archive/ubuntu/dosbox-patched

How does it compare to DOSbox-ECE?

ECE is not really a fork, but rather a collection of important patches (for users it does not matter, but it means ECE cannot improve on code inherited from SVN - unlike dosbox-staging, which is "proper" open-source project).

I was wondering, and then seeing you here clearly involved gives me a hint that the answer is fairly positive--so, what's the relationship between this and Boxtron?

@dreamer_, what are the chances of eventually merging your changes to the original dosbox? Or merging those two projects? Is dosbox development completely dead - so dead, that it can't be even revived? Can you share some background regarding this? I'm extremely happy for your project, because I long felt that dosbox was missing user friendly features (like window resizing). But of course it would be even better if you could the same change in the original project instead of starting a new one.

Great, I was waiting for XDG base dir support in DosBox for a long time. Switch to SDL 2 is also a major plus.


Last edited by Shmerl on 6 May 2020 at 4:51 pm UTC

@dreamer_, what are the chances of eventually merging your changes to the original dosbox? Or merging those two projects? Is dosbox development completely dead - so dead, that it can't be even revived? Can you share some background regarding this? I'm extremely happy for your project, because I long felt that dosbox was missing user friendly features (like window resizing). But of course it would be even better if you could the same change in the original project instead of starting a new one.

>..what are the chances of eventually merging your changes..
The chances are nil. There is a lot of bad blood between the staging developers and dosbox developers.

oh this is really cool, thanks a lot dreamer_ and colleagues!
Out of curiosity, is it known why the original project somehow got "stuck" in time?


Last edited by jens on 6 May 2020 at 6:56 pm UTC

I was wondering, and then seeing you here clearly involved gives me a hint that the answer is fairly positive--so, what's the relationship between this and Boxtron?

They are really close - dosbox-staging started when I found bugs in DOSBox, that I couldn't work around in Boxtron. I plan to bring those two projects closer, but very likely they will stay as 2 projects (we'll see). dosbox-staging is much bigger with many more contributors at this point.

@dreamer_, what are the chances of eventually merging your changes to the original dosbox? Or merging those two projects? Is dosbox development completely dead - so dead, that it can't be even revived? Can you share some background regarding this? I'm extremely happy for your project, because I long felt that dosbox was missing user friendly features (like window resizing). But of course it would be even better if you could the same change in the original project instead of starting a new one.

I agree - the best outcome would be if all the improvements landed upstream and fork could be avoided. I spent a lot of effort (and grew few more grey hairs) trying to avoid creation of the fork (while wanting to get some work actually done), but failed at that :( You can find context in this /r/emulation thread.

At the moment chances of merging the projects are close to 0, but maybe in few dosbox-staging releases, when everything will cool-down, we could pick up the topic again. But this time the upstream would need to show initiative - and willingness to restructure their workflow.

But I need to be clear here: DOSBox SVN project is not dead. They are doing their own thing, on their own terms and schedule.

I've been bundling this as my dosbox-of-choice for my snapped games for a while. It is a huge improvement over the upstream project, most significantly from the switch to sdl2. All the issues with broken multiple monitor setups and resolution switching have resolved. It is a real pity that forks have become necessary to support modern requirements but I suppose it means we still have the older project to support older hardware, where there isn't sdl2 support.

Really nice! Thanks for the article, dosbox with SDL2, x86-64 dynamic and dynrec cores, resizable windows, XDG base directory, ...
It compiles fine on Gentoo, testing an ebuild in my overlay before adding it to main tree soon.

Hopefully MT-32 and 3dfx integration will be there soon!

Hopefully MT-32 and 3dfx integration will be there soon!

Due to popular demand, FluidSynth 2.x integration is in front of those two in the queue, but we'll get to it :) People who want to follow (or contribute):
- MT-32 work is tracked here: #257
- 3dfx emulation work is tracked here: #339

I tested several of my dos games and I observed a performance boost and less graphic tearing (SDL 2 positive effects?). But we still need a vsync feature to avoid completely graphic tearings. I saw they are working on it.


Last edited by legluondunet on 7 May 2020 at 12:34 pm UTC

I tested several of my dos games and I observed a performance boost and less graphic tearing (SDL 2 gains?). But we still need a vsync feature to avoid completely graphic tearings. I saw they are working on it.

Yeah. We decided to disable the user's ability to change vsync setting for now - turning it on causes severe problems (mostly because emulator code is targetting output of CRT refresh rate - usually 70FPS). If someone is feeling adventurous, then vsync can be forced via OpenGL (using e.g. MangoHud), but the results are likely going to be terrible.

We're going to work on this again, but old "simple" implementation inherited from SDL2 patch is not robust enough, more effort is required.

Is it better/worse than dosbox-x ?

DOSBox SVN is definitely not dead. But as a member of the DOSBox Beta Testing team, I can tell you that a new release isn't coming anytime soon. Almost a year ago now they put out a 0.75 beta build and those efforts seem to have fizzled out. I'm still using it as my go to DOSBox version however. Sadly it contains a lot of private non-published patches, so we have been asked not to share it.

Oh good lord. So they have some useful patches, and they don't feel like making an actual release, but in the mean time they want to avoid distributing what they've got for fear that if they did they'd have to abide by the GPL and let other people use the useful things. Every detail I hear about the old DOSBox types seems to confirm the impression that they're dysfunctional and self-absorbed.

I agree - the best outcome would be if all the improvements landed upstream and fork could be avoided. I spent a lot of effort (and grew few more grey hairs) trying to avoid creation of the fork (while wanting to get some work actually done), but failed at that :( You can find context in this /r/emulation thread.

That was a very long, interesting and often sad read. Thanks for linking that. I always assumed DOSBox upstream was simply dead because people left, and not that it was such an inaccessible environment, ignoring and discouraging important community contributions. I hope the right people will flock to your new, community-embracing fork, and DOSBox ecosystem will get revitalized through it. It the project endures and clearly works better on modern systems, with better user experience, I'm sure eventually companies like GOG will use it instead of the original. And Linux distributions might default to it as well, same as what happened to OpenOffice vs LibreOffice or defaulting to wine-staging instead of wine (at least in Fedora; but vanilla wine seems to have been improving a lot recently in this regard). Perhaps DOSBox SVN authors might then recognize the importance of the community and join efforts again, however unlikely it seems now. Thank you for your persistence and energy, I love what you're doing.

Is it better/worse than dosbox-x ?

Neither.

DOSBox-X and dosbox-staging are two, non-competing projects with different goals. If your use case requires perfect hardware emulation (there are many such use-cases!), then DOSBox-X is the way to go; many people use DOSBox-X for gaming and there's nothing wrong with that either. dosbox-staging is for people, who want to play DOS games without a hassle; our goals are stated here :)

Stars indicate, that both projects will cooperate by sharing expertise and patches (but our code diverged a lot, so projects are unlikely to merge). Hope this clears things out :)