VOGONS

Common searches


DOSBox vs forks and patches

Topic actions

First post, by jal

User metadata
Rank Oldbie
Rank
Oldbie

I sincerely doubt it. DOSBox has been in stasis for a long time now, and the debugger hasn't been updated in decades. Would be nice to have a modern debugger like in most emulators, but I wouldn't hold your breath...

Last edited by DosFreak on 2020-10-16, 11:50. Edited 2 times in total.

Reply 1 of 31, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
jal wrote on 2020-10-09, 09:12:

DOSBox has been in stasis for a long time now, and the debugger hasn't been updated in decades.

7 commits affecting the debugger in the past 12 months, including 2 in the past 30 days.
104 commits overall in the past 12 months.
Maybe take a look at the project's activity before declaring it dead?

Reply 3 of 31, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
jal wrote on 2020-10-09, 11:51:

You are right, though I was referring to the released versions, not the repository.

But releases is not how you determine the death of a project... what's your agenda here?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 4 of 31, by jal

User metadata
Rank Oldbie
Rank
Oldbie
Dominus wrote on 2020-10-09, 15:43:

But releases is not how you determine the death of a project... what's your agenda here?

Not sure if I agree. For the ordinary users, it may well be. Glad to see there's still life and love for this project though, and let's end this meta-discussion here lest we invoke the wrath of a moderator 😀.

JAL

Reply 5 of 31, by xcomcmdr

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2020-10-09, 09:30:
7 commits affecting the debugger in the past 12 months, including 2 in the past 30 days. 104 commits overall in the past 12 mont […]
Show full quote
jal wrote on 2020-10-09, 09:12:

DOSBox has been in stasis for a long time now, and the debugger hasn't been updated in decades.

7 commits affecting the debugger in the past 12 months, including 2 in the past 30 days.
104 commits overall in the past 12 months.
Maybe take a look at the project's activity before declaring it dead?

OpenOffice has a lot of commits too. Yet, the LibreOffice project sent this letter to them. Commits don't mean much.

DOSBox hasn't had a major release in 10 years. That's not a good sign for any OO project. Besides, it also still rely on SDL1 (which is unmaintained) and the ton of problems it brings.
A lot of useful patchs have been ignored for years (for example: 3DFX emu/wrapper compat', savestates). Sure, those two are massive, but one can't say that ALL of them are maintenance dead-ends, right ?

If it wasn't mostly dead, a ton of DOSBox forks would not exist.

I'll take DOSBox-staging instead, even if they don't like that project for some reason. It's just better. And it FINALLY brings some much needed improvements, and I'm not talking only about the code here (git and github issues is so much nicer to use than SVN and forums, for a start).

DOSBox-X is also very much worth a try.

Dominus wrote on 2020-10-09, 15:43:
jal wrote on 2020-10-09, 11:51:

You are right, though I was referring to the released versions, not the repository.

But releases is not how you determine the death of a project... what's your agenda here?

None I'd guess ... ? Why do people need to have an agenda to state the obvious ?

Last edited by xcomcmdr on 2020-10-16, 09:15. Edited 1 time in total.

Reply 6 of 31, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

Those forks aren't basing their code on the last official release though, are they? Plenty of the "improvements" that they boast about actually come directly from DOSBox SVN... like actual game fixes or better emulated hardware behavior... calling it "dead" when it's actually the driving force behind improving the main emulation features is a bit on the nose.

Reply 8 of 31, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator

You are falling for the false narrative and as many others you seem to think there is an either or only.
Yes, there are many things that the forks picked up that are useful and wanted by many.
Yet, staging relies heavily on main. Everything that is about actually dos compatibility and speed in the cores comes from main. It's not like Dosbox-x that took a hard turn away from main back then, instead they pick up each new commit from SVN.
And the comparison to OOo and Libre: where do the overwhelming changes between Dosbox 0.74 and the staging release come from?

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 9 of 31, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

Anything that can be done with direct3d or pixel perfect output, can be done more cleanly and portably with opengl shaders; which SVN implemented.
The SDL2 implementations offered so far have all had drawbacks and suffer roughly the same amount of new issues as what they claim is fixed by moving from SDL1. And at the end of the day it doesn't improve the actual emulation at all, meaning you're still stuck playing the same selection of games that worked before and any that didn't work still remain broken.

Reply 10 of 31, by xcomcmdr

User metadata
Rank Member
Rank
Member
Dominus wrote:

Yet, staging relies heavily on main.

I didn't say otherwise.I'm aware of that.

Dominus wrote:

You are falling for the false narrative and as many others you seem to think there is an either or only.

No... ?

I'll just believe the narrative that mainline DOSBox is not dead when I see a new major release.

Commits don't mean much.

Dominus wrote:

And the comparison to OOo and Libre: where do the overwhelming changes between Dosbox 0.74 and the staging release come from?

Please read the dosbox-staging README first : https://github.com/dosbox-staging/dosbox-staging
So you are saying that DOSBox mainline finally ditched SDL1, implemented Pixel Perfect rendering, added Nuked OPL, added direct3d output, resizable window ?
That's DOSBox-X PC-98 emulation features and menu GUI all come from SVN ?
Seriously ?

Last edited by xcomcmdr on 2020-10-16, 09:05. Edited 1 time in total.

Reply 11 of 31, by Dominus

User metadata
Rank DOSBox Moderator
Rank
DOSBox Moderator
xcomcmdr wrote on 2020-10-16, 07:37:
Please read the dosbox-staging README first : https://github.com/dosbox-staging/dosbox-staging So you are saying that DOSBox mai […]
Show full quote
Dominus wrote:

And the comparison to OOo and Libre: where do the overwhelming changes between Dosbox 0.74 and the staging release come from?

Please read the dosbox-staging README first : https://github.com/dosbox-staging/dosbox-staging
So you are saying that DOSBox mainline finally ditched SDL1, implemented Pixel Perfect rendering, added Nuked OPL, added direct3d output, resizable window ?
That's DOSBox-X PC-98 emulation features and menu GUI all come from SVN ?
Seriously ?

No, I didn't say either of these things (and I didn't mention DOSBox-x, did I?). The overwhelming changes between 0.74 code and staging come from SVN. And everything else you mention comes from patches collected here on Vogons (except maybe resizable window, which I think is something that SDL2 makes quite easy to add). And, except NukedOPL, all these are changes that don't affect the actual goal of DOSBox, emulating DOS for gaming. Everything related to the actual emulation comes from SVN and it still does.
(again, I'm excluding DOSBox-x which took a turn away from SVN quite a while ago and has different goals somewhat and was almost always intended as a hard fork and never as merging its changes into SVN)

Windows 3.1x guide for DOSBox
60 seconds guide to DOSBox

Reply 12 of 31, by xcomcmdr

User metadata
Rank Member
Rank
Member

Yes, and I can't understand why nuked (for example) isn't in mainline.

One of the reasons I gave up on mainline releases after 10 years of waiting.

(and I can compile SVN myself, that's not the problem)

Reply 13 of 31, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Moved posts from debug thread. Some posts may not have made it over so no conspiracy theories please.

Please leave dosbox-staging discussion to a minimum. One of the individuals associated with dosbox-staging is banned here so wouldn't be fair to discuss without the others opinions. If you wish to discuss dosbox-staging then post on the dosbox-staging (or whatever it's going to be called) site.

I'm at work so don't have time to review this thread but the existence of "forks" is a good thing and have existed since dosbox was created (or pretty close to) and dosbox should not and never will include every patch ever created.

DOSBox Compilation Guides
DosBox Feature Request Thread
PC Game Compatibility List
How To Ask Questions The Smart Way
Running DRM games offline

Reply 14 of 31, by xcomcmdr

User metadata
Rank Member
Rank
Member
DosFreak wrote:

and dosbox should not and never will include every patch ever created.

Of course not. But why not Nuked OPL ?
It improves OPL emulation so much, it's really more faithful. Also, it does not seem to be massive patch / a maintenance overload.

For this patch at least, I don't get it.

Reply 15 of 31, by Jorpho

User metadata
Rank l33t++
Rank
l33t++
xcomcmdr wrote on 2020-10-16, 05:59:

DOSBox hasn't had a major release in 10 years.

What about DOSBox 0.74-2 and 0.74-3? Y'know, the releases front-and-center at www.dosbox.com ?

Yes, those arguably aren't "major releases", but for something as ubiquitous as DOSBox, isn't it a whole lot better not to issue a major release that might break compatibility with other software? Seems to me there are plenty of open-source projects that have caused considerable grief by storming on ahead for no good reason without due consideration for their userbase.

Reply 17 of 31, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

jmarsh,

Regarding your recent GUS DMA fix for Quake, I've asked the DOSBox-X team about it here.

https://github.com/joncampbell123/dosbox-x/issues/1961

I'm not sure if you looked at the DOSBox-X and Staging DMA implementations before going your own way, but am curious if you have comments / critiques on those.

Likewise, if your implementation goes beyond Quake compatibility (ie: perhaps you implemented it based on some documentation and therefore could be the most correct implementation).

Just want to see if we can collectively find an optimal implementation.

Reply 18 of 31, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

I originally wrote that patch over 18 months ago. Afair the only part relevant to making Quake (and Q2dos) produce audio was fixing one bit in a register that represents different things depending on if it's being read vs. being written. The DMA implementation wasn't touched.