My most wanted features for dosbox now are things that were attempted by other people, and never ever get merged.
First the mt32 patch that scummvm has no problem using, and dosbox doesn't (were the roland lawyers apparently baseless threats so effective?)
Then glide wrappers - making some early 3d games look great.
Then savestates.

I know i can compile and patch it myself, but things that don't get merged eventually drift into unusability.

Serious Callers Only wrote:

were the roland lawyers apparently baseless threats so effective?

They weren't baseless at all. The only reason Roland had to back down was because of a technicality. They couldn't produce the appropriate documents when required, but you can bet that when they find them, they'll be sure to crack down on any emulation projects once again. The DOSBox devs are playing it safe by making sure that there is no potential for attracting unwanted attention from Roland.

Serious Callers Only wrote:

Then savestates.

There is no working implementation of this. Yes, somebody recently attempted a proof of concept, but it is far from complete and, if not done properly, it won't just "not work" but can actively destroy data. There's no way that'll end up in core DOSBox without those decidedly non-trivial things being sorted out first.

There is no working implementation of this. Yes, somebody recently attempted a proof of concept, but it is far from complete and, if not done properly, it won't just "not work" but can actively destroy data. There's no way that'll end up in core DOSBox without those decidedly non-trivial things being sorted out first.

It worked just fine.

It worked just fine.

Doubt that given that it doesn't care about any real interfacing state like files,
or any function recursion that can't be resolved by just loading some vars.

But please don't discuss "savestates, mt32, glide" in this thread just because
somebody thinks they are the same for whatever reason.

Kippesoep wrote:

Serious Callers Only wrote:

were the roland lawyers apparently baseless threats so effective?

They weren't baseless at all. The only reason Roland had to back down was because of a technicality. They couldn't produce the appropriate documents when required, but you can bet that when they find them, they'll be sure to crack down on any emulation projects once again.

That's why they were baseless. Regardless, is there a reason why it can't be dynamically linked against the mt32 dll? Just require that people wanting to use the mt32 device install the munt project themselves. Done.

BTW the mt32 patch on sourceforge doesn't apply cleanly to trunk.
(did patch -p1 < dosbox-mt32.diff from trunk).

if people install munt as midi device, then dosbox can use it. It might be possible that you weren't aware of this.
Any more derailing of this thread will result in its closure.

That's why they were baseless.

Just because they couldn't come up with the right documents doesn't mean their accusations were baseless.

Regardless, is there a reason why it can't be dynamically linked against the mt32 dll? Just require that people wanting to use the mt32 device install the munt project themselves. Done.

get a clue... You can run munt with dosbox already without anything needed to be done by dosbox devs...

Oh yes. "Get a clue".
I have a clue - i just don't like having to setup a daemon that will probably start on a different port that what dosbox expects.

Or even, having to start a daemon for something i only use in dosbox.
Passive aggressive much? Anyway i will start a thread to ask about the mt32 patch.

Passive aggressive much?

nope, not much passive

Hey with a bit of tweaking we have 2+ unrelated threads now!