Thanks; just checked out that link. It looks like the pixel perfect implementation in ECE may still be superior in at least some ways. In which case, is ECE version r4301 still the most stable and feature-complete release containing ant's pixel perfect patch?
If you look back in this thread, there's a big to-do when Ant's patch was broken and they say what the last version with it is.
* ECE no longer has ant's pixel-perfect support, but it can be added?
* Does the latest version of DOSBox (0.74-3) have ant's pixel-perfect?
* Is r4301 still the latest version of ECE that is the most feature-complete and stable? (presuming it includes pixel perfect as well?)
* Lastly, and this may be extending beyond the scope of this thread - does ScummVM now support some kind of pixel-perfect scaling? And furthermore, if so, what reasons might there be to continue playing games with DOSBox as opposed to ScummVM from a practical/functional point of view? I like DOSBox; I'm just wondering what differences (noticeable by the user) there are in the gaming experience between the two, at this point in time.
12020-03-29: 2 3 2.4.0 released. 4 5 * In addition to already existing options intended to improve 6 audio output quality in contrast to somewhat degrading emulation 7 accuracy, the two more quirks of LA-32 are now configurable. 8 NicePanning enlarges the allowed value range for the pan setting, 9 providing for smoother panning. 10 NicePartialMixing disables occasional counter-phase mixing of partials 11 making the timbres that contain closely sounding partials be 12 mixed in a more predictable way. 13 * Improved emulation of the pitch overflow quirks of the MT-32 GEN0 14 by disabling the upper-bound check that is only applied during the base 15 pitch calculations by modern units. Specifically, this fixes the "starfall" 16 timbre playing at wrong pitch in the WILLY BEAMISH intro when using 17 ROMs of the MT-32 GEN0 (discovered by eddieduff at Sourceforge). 18 * Fixed compilation errors when setting various preprocessor definitions 19 intended for debugging. 20 * Converted compiler definition MT32EMU_REDUCE_REVERB_MEMORY to a runtime 21 configuration option. This allows the client to ensure that reverb mode 22 changes are safe for rendering in a realtime thread. 23 * Improved the implementation of the internal MIDI event queue. Notably, 24 added a new storage mechanism for the payload of SysEx events that 25 does not require memory allocations while pushing events to the queue.
I remember munt being cpu heavy making it being a separate process a good thing. Has it become efficient enough to live in the same process with little impact or added as a separate thread?
I remember munt being cpu heavy making it being a separate process a good thing. Has it become efficient enough to live in the same process with little impact or added as a separate thread?
Games that actually support MT-32 are old enough as to not place any serious demand on cycle count. So unless you have a very slow CPU, having Munt in the same process, or even same thread as the dosbox emulation thread, has never been an issue.
If you're on a very slow CPU (I'm thinking of like 2GHz CPUs fron the 2000's), then stand-alone Munt is better, yes.
If you're on a very slow CPU (I'm thinking of like 2GHz CPUs fron the 2000's), then stand-alone Munt is better, yes.
Just for reference, I use mt32emuqt with a debian varient on a Raspberry Pi, and it's absolutely no problem on a RPi3 or above. I think they say the CPU is equivalent to a 2GHz Pentium 4, very broadly speaking.
If you're on a very slow CPU (I'm thinking of like 2GHz CPUs fron the 2000's), then stand-alone Munt is better, yes.
Just for reference, I use mt32emuqt with a debian varient on a Raspberry Pi, and it's absolutely no problem on a RPi3 or above. I think they say the CPU is equivalent to a 2GHz Pentium 4, very broadly speaking.
As I'm sure you know, dosbox-ece for Linux is currently compiled against libfluidsynth.so.1. However the upcoming Fedora 33 instead ships with libfluidsynth.so.2 and as such dosbox-ece no longer works. The user will get something like:
1dosbox: error while loading shared libraries: libfluidsynth.so.1: cannot open shared object file: No such file or directory
Fedora offers no compat library either for backward compatibility with libfluidsynth.so.1
Presumably other Linux distributions will also be switching to v2 in the near future.
I ran into this same problem with dosbox-x. However with a simple re-compile against libfluidsynth.so.2, dosbox-x was working again.
Also, in the logs of dosbox-x I get the following messages:
We use the term "stand-alone munt" to refer to running mt32emuqt or mt32emualsadrv or mt32emuwin32drv and then configuring dosbox to output to that through a MIDI port.
"Built-in munt" on the other hand refers to using a patched version of dosbox (like dosbox-ece) that can directly emulate the MT-32 itself rather than offload that work to another process or driver through a MIDI port.
Both work, but on very old and/or very weak multi-core CPUs, using a stand-alone version of munt can be preferable.
We use the term "stand-alone munt" to refer to running mt32emuqt or mt32emualsadrv or mt32emuwin32drv and then configuring dosbox to output to that through a MIDI port.
"Built-in munt" on the other hand refers to using a patched version of dosbox (like dosbox-ece) that can directly emulate the MT-32 itself rather than offload that work to another process or driver through a MIDI port.
Both work, but on very old and/or very weak multi-core CPUs, using a stand-alone version of munt can be preferable.
Ok. Thanks for the clarification. I didn't realize that there was anything functionally different about the "baked-in" munts. I thought ECE or other were just packaging munt with their distro.
