VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 1120 of 1132, by 7F20

User metadata
Rank Newbie
Rank
Newbie
lukeman3000 wrote on 2020-09-03, 00:03:

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.

Reply 1121 of 1132, by KainXVIII

User metadata
Rank Member
Rank
Member
lukeman3000 wrote on 2020-09-03, 00:03:
KainXVIII wrote on 2020-09-02, 21:43:
lukeman3000 wrote on 2020-09-02, 21:21:
Hi guys; just looking for some clarification - […]
Show full quote

Hi guys; just looking for some clarification -

* 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.

Pixel-perfect support can be added through shaders https://github.com/tyrells/dosbox-svn-shaders
ScummVM is usually better and have pixel-perfect scaling, but some games are not 100% compatible (https://www.scummvm.org/compatibility/), so expect a bunch of bugs compared to pure dosbox emulation.

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 what ways?

Reply 1122 of 1132, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

New release: DOSBox ECE r4367, now with MUNTs mt32emu in version 2.4.0!
https://dosboxece.yesterplay.net/

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 1123 of 1132, by KainXVIII

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote on 2020-09-23, 07:14:

New release: DOSBox ECE r4367, now with MUNTs mt32emu in version 2.4.0!
https://dosboxece.yesterplay.net/

Huh, what's new in 2.4 version of munt? 👀

Reply 1124 of 1132, by _Rob

User metadata
Rank Member
Rank
Member
KainXVIII wrote on 2020-09-23, 14:54:
Yesterplay80 wrote on 2020-09-23, 07:14:

New release: DOSBox ECE r4367, now with MUNTs mt32emu in version 2.4.0!
https://dosboxece.yesterplay.net/

Huh, what's new in 2.4 version of munt? 👀

google...
https://github.com/munt/munt/blob/master/mt32emu/NEWS.txt

2020-03-29:

2.4.0 released.

* In addition to already existing options intended to improve
audio output quality in contrast to somewhat degrading emulation
accuracy, the two more quirks of LA-32 are now configurable.
NicePanning enlarges the allowed value range for the pan setting,
providing for smoother panning.
NicePartialMixing disables occasional counter-phase mixing of partials
making the timbres that contain closely sounding partials be
mixed in a more predictable way.
* Improved emulation of the pitch overflow quirks of the MT-32 GEN0
by disabling the upper-bound check that is only applied during the base
pitch calculations by modern units. Specifically, this fixes the "starfall"
timbre playing at wrong pitch in the WILLY BEAMISH intro when using
ROMs of the MT-32 GEN0 (discovered by eddieduff at Sourceforge).
* Fixed compilation errors when setting various preprocessor definitions
intended for debugging.
* Converted compiler definition MT32EMU_REDUCE_REVERB_MEMORY to a runtime
configuration option. This allows the client to ensure that reverb mode
changes are safe for rendering in a realtime thread.
* Improved the implementation of the internal MIDI event queue. Notably,
added a new storage mechanism for the payload of SysEx events that
does not require memory allocations while pushing events to the queue.

Reply 1125 of 1132, by KainXVIII

User metadata
Rank Member
Rank
Member
_Rob wrote on 2020-09-23, 15:39:
KainXVIII wrote on 2020-09-23, 14:54:
Yesterplay80 wrote on 2020-09-23, 07:14:

New release: DOSBox ECE r4367, now with MUNTs mt32emu in version 2.4.0!
https://dosboxece.yesterplay.net/

Huh, what's new in 2.4 version of munt? 👀

google...
https://github.com/munt/munt/blob/master/mt32emu/NEWS.txt

Interesting, i wonder why there are no 2.4.0 release on sourceforge page https://sourceforge.net/projects/munt/files/munt/

Reply 1126 of 1132, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
KainXVIII wrote on 2020-09-23, 16:11:

Interesting, i wonder why there are no 2.4.0 release on sourceforge page https://sourceforge.net/projects/munt/files/munt/

Because the project moved to GitHub: https://github.com/munt/munt

My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)

Reply 1127 of 1132, by KainXVIII

User metadata
Rank Member
Rank
Member
Yesterplay80 wrote on 2020-09-23, 20:05:
KainXVIII wrote on 2020-09-23, 16:11:

Interesting, i wonder why there are no 2.4.0 release on sourceforge page https://sourceforge.net/projects/munt/files/munt/

Because the project moved to GitHub: https://github.com/munt/munt

Thanks! But i can't find compiled version anymore (i mean installation files) 🤔

upd - found my answer

Sure thing, 2.4.0 is upcoming. I'm working on improvements in the UI application atm, and when it's done, the release will be rolled out.

Reply 1129 of 1132, by realnc

User metadata
Rank Member
Rank
Member
awgamer wrote on Yesterday, 03:56:

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.

Reply 1130 of 1132, by 7F20

User metadata
Rank Newbie
Rank
Newbie
realnc wrote on Yesterday, 15:33:

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.

Reply 1131 of 1132, by realnc

User metadata
Rank Member
Rank
Member
7F20 wrote on Yesterday, 18:03:
realnc wrote on Yesterday, 15:33:

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.

mt32emuqt is stand-alone munt.

Reply 1132 of 1132, by _Rob

User metadata
Rank Member
Rank
Member

@Yesterplay80 just a heads up.

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:

dosbox: 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:

fluidsynth: error: Unknown numeric setting 'audio.periods'
fluidsynth: error: Unknown numeric setting 'audio.period-size'
fluidsynth: error: Unknown string setting 'synth.reverb.active'
fluidsynth: error: Unknown string setting 'synth.chorus.active'

So it seems that some of the settings are no longer valid.