Sorry too lazy to tell but not too lazy to reply.

wd wrote:

Sorry too lazy to tell but not too lazy to reply.

Haha, you got me 😀.

JAL

No, it has never been. I see no reason why it shouldn't along with the PS/1 audio emulation and the Covox if that is ever done.

Then add it to your source tree!

Explaining why things are rejected would help people. Looking at what's been included leads people to believe unique hardware is in the purview, so something like this being rejected seems arbitrary. Is there a set plan or aims for DOSBox? About the only thing I'm sure of would be 100% compatibility and a desire to run on many platforms(sort of, as that has one asking why the d3d patch hasn't been included.)

I don't speak for anyone but me, and I am not privy to what and when stuff is approved, but from all I have seen, priority is currently given to fixing things that prevents games from running correctly.

A lot of new stuff is going on with the video support - EGA, VGA, SVGA. I think it was prompted by some platform game (Kelllog something?) that displayed incorrect colours.

There are changes being added that fixes problems with games not installing, running or saving properly. Fixes to the file-system and/or CD-ROM stuff.

There is stuff being changed in the CPU emulation - again problems that causes some games (and 1-2 demos?) from running.

The PS/1 audio card and this Innovation card is (I think?) not something that prevents a game from running, because said games do work with some of the other audio solutions..

And yes, cross-platform support is important too.

Some extra info / guidelines for feature requests:

DOSBox Feature Request Thread

The absolute #1 priority is Game Compatibility. Not Wordstar/Wordperfect or some custom app that you need to print or connect to your host via serial. All suggestions should keep in mind the goal for increasing DosBox GAME compatibility.

Minimax, you've managed to write a lot without addressing what was asked, and unless you've seen an explanation, really only those behind the wheel, wd, et al, can explain their reasoning. Fixing bugs is an obvious goal, as is going for compatibility, as I had pointed out. The ps/1 audio card and innovation are like other hardware that have been included, as I also noted, of which dosbox likewise didn't need in order to run. One way to frame it would be for a new maintainer that could commit patches; they would need to know the guidelines for accepting/rejecting changes. If one were to go off of DOSBox commit history, things like the d3d, ps/1 audio and innovation patches would be commited.

There's no doubt that that this patch may be commited but analysis of the code/testing/need for it to be in DOSBox have to all be done before it is committed. Wd's response is typical since usually people are as follows:

Impatient users:
"Here's this great new feature! WHY ISN'T IT IMPLEMENTED IN DOSBOX YET!!?? WTF IS TAKING YOU SO LONG YOU LAZY ****** ******?!"

DOSBox developers

"If you need it compile it yourself and be happy".
"Wait, some time in the future it may or may not be implemented.".

How many people are going to benefit from this patch?
Answer: Not many.

How many people would benefit from compatibility fixed in DOSBox?
Answer: Alot.

The above is only one among many reasons why it takes awhile before a patch to be commited.

If you were to look at the DOSBox changelog you'd see how much of it is compatibility increases and how little of it is extras that aren't as important overall as compatibility. The extra features that are included have most of the time been tested thoroughly (after alot of testing) before being commited.

Again, Things aren't just thrown in just because someone things it's a neato idea. ALOT of thought is put into it.....possibly too much thought but that's how DOSBox development has been done for the past 6 years and here we still are so it seems to work.

>DOSBox developers

Developers that aren't the DOSBox developers(tm) are also left in the dark. Changes that come from me are all over the DOSBox source, but I'm not a "DOSBox developer" and I'm in the dark.

>How many people are going to benefit from this patch?

Not many benefit from patches that have been commited, pvga1a for example.

>How many people would benefit from compatibility fixed in DOSBox?

It's not a case of either or.

Being the instigator of this , my opinion is that the compatibility issues of this patch are rather minimal. This patch is a feature no different than the emulation of any other sound card. No game likely to have used it requires it to run. If sound is needed, the PC Speaker would do.

Any compatibility issues would lie within the SID emulation code or how it interacted with DOSBox. How the card operated is known, it is a modular, virtually output only device that could not affect the remainder of the system. In the most extreme case, the only bad consequence should be wrong sound.

Portability is a bigger concern. Who knows whether this reSID code, from which the Innovation patch arises, would work on the other systems that DOSBox works on?

I agree that these cards, Innovation, PS/1 and Covox are marginal devices that are not the optimal sound devices for any known game.

my opinion is that the compatibility issues of this patch are rather minimal.

Well then add it to your source tree.

wd wrote:

Well then add it to your source tree.

It's not about adding something to anyone's personal source tree, it's about adding stuff to the official DOSBox tree. And, like commented on here and before in various other threads, it's usually a bit vague what is and what isn't included in DOSBox the Official Release(TM). There's PS1 audio, the Innovation SID thing, 4 colour mode CGA composite mode enhancements, and more, that have never made it to DOSBox for reasons unknown to all but the official maintainers.

JAL

Before you all get angry at wd. The decision whether and when to add something is taken most of the time by me.

the 4 colour mode cga stuff ? I think you refer to 16 colour composite stuff. Which is present since a long time.There is an even better version out there. But that is hard to add to dosbox in a way that it is compatible with our scalers and still being fast enough to run at 70 hz and doesn't offer imho enough improvements to justify this work.

No he's talking about those two games which have a non-detectable composite
mode that needs a simple switch and probably some larger amount of changes
to the current composite emulation.
But those people just talked about how useful it is, and that it's utterly needed
for world peace and stuff, never seen a single line of code for that.

That talk is cluttered over a 70-pages thread btw.

If a theoretical new maintainer were added, what would be his guidelines for accepting/rejecting patches?

maintainer for what?

A CVS maintainer that had commit privileges. He would have to have some guidelines for accepting or rejecting patches.

There are no guidelines besides the omnipotence of Qbix/Harekiet.

Doesn't matter if it's personal preference, the question would still be what are they?