Is it possible to stack sound fonts? I was hoping to stack WeedsGM3.sf2 and weedsgm4_update.sf2. I gave it a few tries but it either is not possible or I'm doing it wrong.

Yes, depending on the synthesizer engine. This takes some careful planning to get the instrument and tone configuration you're looking for.

I was wondering if it can be done with DOSBox ECE's fluidsynth implementation. I mostly use Falcosoft MIDI player with various VST plugins and soundfonts. I can stack fonts in MIDIplayer but I was hoping for something internal, making it more portable.

I know FluidSynth can, but I'm not sure about how it's utilized in ECE.

I'm trying to compile ECE for Linux from the DOSBox ECE r4191 (Linux source) file on your website and I'm running into this error running make (autogen and configure worked fine)

1midi_mt32.h:7:10: fatal error: mt32emu/mt32emu.h: No such file or directory
2 #include <mt32emu/mt32emu.h>
3          ^~~~~~~~~~~~~~~~~~~
4compilation terminated.
5Makefile:360: recipe for target 'midi.o' failed
6make[3]: *** [midi.o] Error 1
7make[3]: Leaving directory '/home/jdh/Downloads/DOSBox ECE r4191 (Linux source)/src/gui'
8Makefile:444: recipe for target 'all-recursive' failed
9make[2]: *** [all-recursive] Error 1
10make[2]: Leaving directory '/home/jdh/Downloads/DOSBox ECE r4191 (Linux source)/src'
11Makefile:396: recipe for target 'all-recursive' failed
12make[1]: *** [all-recursive] Error 1
13make[1]: Leaving directory '/home/jdh/Downloads/DOSBox ECE r4191 (Linux source)'
14Makefile:337: recipe for target 'all' failed
15make: *** [all] Error 2

I have all of the dependencies listed in the INSTALL file. I think I might need munt but, otherwise have no clue.

You need Munt.

All sorted now. I installed scummvm which has munt as a dependency and make now runs with no issues. It is worth noting that while the executable will still run despite make failing, munt should probably be listed as a dependency in the INSTALL file and make should probably have a command line argument to disable it.

Nice build yesterplay, the scaling options were exactly what I was looking for.

Running DOSBox ECE on Linux. When I try to IMGMOUNT more then one image, I get a segfault.
I upgraded from a early January built to the latest (r4192), but it makes no difference.

command used:

1IMGMOUNT D cd1.cue cd2.cue -t iso

This works fine:

1IMGMOUNT D cd1.cue -t iso
2IMGMOUNT E cd2.cue -t iso

The only error I get when running DOSBox from the commandline is:

1segmentation fault (core dumped)

I tried it myself in my Linux VM here, with ISO and BIN+CUE images (composed of ISO and OGG files) and couldn't reproduce this error. Anyona else having this problem? Does that happen with all images or just with same one(s)?

Yesterplay80 wrote:

I tried it myself in my Linux VM here, with ISO and BIN+CUE images (composed of ISO and OGG files) and couldn't reproduce this error. Anyona else having this problem? Does that happen with all images or just with same one(s)?

Not sure what to say, I can replicate the issue with both CUE and ISO. This is on Fedora 29.

Here is an example of an imgmount with two ISOs, just before hitting enter:

Here is the terminal window with the segfault the above imgmount causes:

And to show that the same files can be mounted if using one ISO per drive:

I'm on Linux Mint, but I'm only running it in a VM, just so I can compile DOSBox ECE, I'm not using Linux productively.

Does this error occur only in DOSBox ECE or does it occur in vanilla DOSBox, too?

Yesterplay80 wrote:

I'm on Linux Mint, but I'm only running it in a VM, just so I can compile DOSBox ECE, I'm not using Linux productively.

Does this error occur only in DOSBox ECE or does it occur in vanilla DOSBox, too?

Good question.
I first installed dosbox-0.74.2-2.fc29.x86_64 from the fedora repository, and it works.

Of course, this is a 64bit dosbox build, while DOSBox ECE is 32bit... So I next uninstalled it, and installed the i686 build from the fedora repository, and tried it again. And again it worked fine.
So it must be some dependency difference between your Mint installation, and my Fedora installation that causes the segfault.

An additional datapoint, I just tried the new DOSBox ECE r4194 build and get the same error, but when I take your regular "DOSBox r4194 (Linux).7z" version, which identifies itself as "DOSBox SVN", it works!

I assume they are build on the same Mint virtual machine, and the same toolset?

I just downloaded the ECE Linux source package, and build it (64bit, as I don't have a 32bit build environment handy). And I can say it works!

As a side note, the configure command fails to check for munt headers, and so make failed, as I did not have the munt headers installed initially.
If you think it would help, I can get you the output of the configure or make commands.

Are these builds compatible with Windows XP 32bits? I’m getting an error with SDL.dll throwing me to the desktop.

Not entirely sure if this is the appropriate place to post this, but I'm having a bit of trouble using 2 XBox One controllers using DOSBox ECE r4194 (Windows 10 x64) and was hoping for a fix.

From all the testing I've done, it seems that if the any D-Pad keys on the 2nd controller are mapped in the key mapper and saved, DOSBox ECE will crash on starting up again if the 2nd controller is not connected. This happens regardless of the "joysticktype" value in your .conf file.

To put it another way, if any key on the D-Pad of the 2nd controller is mapped in the key mapper, DOSBox ECE will only work if both controllers are connected. I'm inclined to think that a tweak or two to cfoesh's fully bindable joystick patch would fix it.

As a compromise for now, I've removed any mappings corresponding to the D-Pad on the 2nd controller...it's better to have at least one D-Pad working rather than none hah.

Testing Golden Eagle w/ adlib audio I found that ECE appears to introduce a bug that is not replicated in the current SVN.

Essentially, adlib audio sounded very muffled, so I changed it to cms. This sounds much better when selecting adlib in the game, however it also introduces high pitched static in the ECE build (March 1st, 2019).

In both vanilla 0.74 and vanilla SVN, there is no static.

Do you have a build environment? If so, what about reversing the Nuked OPL3 patch to see if it's specific to that?

franky52 wrote:

Are these builds compatible with Windows XP 32bits? I’m getting an error with SDL.dll throwing me to the desktop.

AFAIK, it should work under XP, as well, so a more specific error description would be helpful.

spammenon wrote:

From all the testing I've done, it seems that if the any D-Pad keys on the 2nd controller are mapped in the key mapper and saved, DOSBox ECE will crash on starting up again if the 2nd controller is not connected. This happens regardless of the "joysticktype" value in your .conf file.

I'll try it once I get home this evening, though I don't have any Xbox One Controllers. Does it work if you map only one controller and start DOSBox ECE without any controller conected?

exofreeze wrote:

Essentially, adlib audio sounded very muffled, so I changed it to cms. This sounds much better when selecting adlib in the game, however it also introduces high pitched static in the ECE build (March 1st, 2019).

gdjacobs wrote:

Do you have a build environment? If so, what about reversing the Nuked OPL3 patch to see if it's specific to that?

DId you alter the oplrate value, too? I assume you're using Windows, so please try out this build without the NukedOPL emulator, just replace the exe with the one in here:

spammenon wrote:

Not entirely sure if this is the appropriate place to post this, but I'm having a bit of trouble using 2 XBox One controllers us […]
Show full quote

Not entirely sure if this is the appropriate place to post this, but I'm having a bit of trouble using 2 XBox One controllers using DOSBox ECE r4194 (Windows 10 x64) and was hoping for a fix.

From all the testing I've done, it seems that if the any D-Pad keys on the 2nd controller are mapped in the key mapper and saved, DOSBox ECE will crash on starting up again if the 2nd controller is not connected. This happens regardless of the "joysticktype" value in your .conf file.

To put it another way, if any key on the D-Pad of the 2nd controller is mapped in the key mapper, DOSBox ECE will only work if both controllers are connected. I'm inclined to think that a tweak or two to cfoesh's fully bindable joystick patch would fix it.

As a compromise for now, I've removed any mappings corresponding to the D-Pad on the 2nd controller...it's better to have at least one D-Pad working rather than none hah.

Try the non-patched build.
You might have discovered the reason for those limits to exist in the mapper.