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

Quoting: Purple Library GuyI 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.

Quoting: ripper@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!

Quoting: voyageurHopefully 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

Quoting: legluondunetI 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 ?

Quoting: GuestDOSBox 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.

Quoting: dreamer_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.

Quoting: axredneckIs 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 :)