VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 580 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
Qbix wrote:

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

I think the axis limit isn't the problem here, it's rather that DOSBox is trying to adress non existent hardware if you map but unplug the second controller.

Vanilla SVN behaves the same, btw. Mapping the second controller and not having it plugged in crashes the unpatched build as well. I tried it with two Logitech F710 in Xinput mode.
UPDATE: Official DOSBox 0.74.-2 crashes, too. So definitely not a problem caused by the patch.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 583 of 1550, by Qbix

User metadata
Rank DOSBox Author
Rank
DOSBox Author

It would be a bit of a waste.. i hardly use the one controller that I already have... But it is indeed a possibility to find a cheap second one 😀

Water flows down the stream
How to ask questions the smart way!

Reply 584 of 1550, by spammenon

User metadata
Rank Newbie
Rank
Newbie
Qbix wrote:

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

I did think the patch could cause some trouble, but I'm continuing to use it so at least player 1 can use the D-Pad.

Yesterplay80 wrote:

I think the axis limit isn't the problem here, it's rather that DOSBox is trying to adress non existent hardware if you map but unplug the second controller.

Vanilla SVN behaves the same, btw. Mapping the second controller and not having it plugged in crashes the unpatched build as well. I tried it with two Logitech F710 in Xinput mode.
UPDATE: Official DOSBox 0.74.-2 crashes, too. So definitely not a problem caused by the patch.

In my experience, the crashes seem isolated to a 2nd gamepad's d-pad remaining mapped when disconnected (on starting DOSBox ECE) and nothing else. The other buttons and axes being mapped is fine and does not cause crashes. With Vanilla DOSBox, the d-pads don't work anyway (in 2axis mode).

Thank you both for your replies.

Reply 585 of 1550, by Choum

User metadata
Rank Newbie
Rank
Newbie

Hello all,

Does the gravis ultrasound emulation is limited to mono output only.
When I try games sound setup settings like tie fighter, dark force etc.. the digital sound test is always mono with gravis ultrasound unlike Sb16 which is in stereo ouput.

Is it a limitation from the dosbox emulation or a bad setting on my side ?

I use GUS 4.11 drivers, megaem and PPL161 drivers.

Reply 586 of 1550, by Choum

User metadata
Rank Newbie
Rank
Newbie

In fact this is an issue already in the official dosbox.

Dosbox-X fork have already fixed this problem, will you add such fix into ECE too ?

"- Gravis Ultrasound panning register fixes. Mainline DOSBox seems to have a buggy implementation that ends up locking all audio to center no matter what value is written. I fixed that code in this version. DOS programs that rely on stereo sound should actually play in stereo now through DOSBox."

Reply 587 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie
Choum wrote:

Dosbox-X fork have already fixed this problem, will you add such fix into ECE too ?

As long as there's no applicable patch file, I'm afraid there's nothing I can do, as 'm no developer myself.

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 588 of 1550, by Choum

User metadata
Rank Newbie
Rank
Newbie

Edit : I was able to reproduce the mono/stereo bug on tie fighter even on dosbox-x if I set true this setting :

gus fixed render rate=true

If set, Gravis Ultrasound audio output is rendered at a fixed sample rate specified by 'gusrate'. This can provide better quality than real hardware, if desired. Else, Gravis Ultrasound emulation will change the sample rate of it's output according to the number of active channels, just like real hardware.
Note: DOSBox-X defaults to 'false', while mainline DOSBox SVN is currently hardcoded to render as if this setting is 'true'.

SO it look like the previous setting I found was not the present.

Reply 589 of 1550, by Choum

User metadata
Rank Newbie
Rank
Newbie

IS there a list of prerequesite component to compile ECE source (or a ready to go mingw zip) ?
I suppose it will need more lib than the official dosbox.

I would like to try to change the hardcoded render to see the result.

Reply 590 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

Apart from those needed for vanilla DOSBox (see the Wiki) you only need mt32emufrom MUNT and Fluidsynth, on WIndows I still use Fluidsynth 1.16 because it's such a PITA to get a newer one compiled. There's your list. 😀

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 591 of 1550, by gorzka

User metadata
Rank Newbie
Rank
Newbie

Hello,

when I try to compiling this under Linux I become this error:

In file included from midi_mt32.h:7,
from midi.cpp:77:
./mt32emu/mt32emu.h:47:2: Fehler: #error Incompatible setting MT32EMU_API_TYPE=3
#error Incompatible setting MT32EMU_API_TYPE=3
^~~~~
In file included from midi.cpp:77:
midi_mt32.h:10:2: Fehler: #error Incompatible mt32emu library version
#error Incompatible mt32emu library version
^~~~~
make[3]: *** [Makefile:369: midi.o] Fehler 1
make[3]: Verzeichnis „/home/gorzka/Downloads/DOSBox ECE r4194 (Linux source)/src/gui“ wird verlassen
make[2]: *** [Makefile:450: all-recursive] Fehler 1
make[2]: Verzeichnis „/home/gorzka/Downloads/DOSBox ECE r4194 (Linux source)/src“ wird verlassen
make[1]: *** [Makefile:395: all-recursive] Fehler 1
make[1]: Verzeichnis „/home/gorzka/Downloads/DOSBox ECE r4194 (Linux source)“ wird verlassen
make: *** [Makefile:336: all] Fehler 2

The mt32emu library is not in the Source code.

Reply 592 of 1550, by _Rob

User metadata
Rank Member
Rank
Member
gorzka wrote:
Hello, […]
Show full quote

Hello,

when I try to compiling this under Linux I become this error:

In file included from midi_mt32.h:7,
from midi.cpp:77:
./mt32emu/mt32emu.h:47:2: Fehler: #error Incompatible setting MT32EMU_API_TYPE=3
#error Incompatible setting MT32EMU_API_TYPE=3
^~~~~
In file included from midi.cpp:77:
midi_mt32.h:10:2: Fehler: #error Incompatible mt32emu library version
#error Incompatible mt32emu library version
^~~~~
make[3]: *** [Makefile:369: midi.o] Fehler 1
make[3]: Verzeichnis „/home/gorzka/Downloads/DOSBox ECE r4194 (Linux source)/src/gui“ wird verlassen
make[2]: *** [Makefile:450: all-recursive] Fehler 1
make[2]: Verzeichnis „/home/gorzka/Downloads/DOSBox ECE r4194 (Linux source)/src“ wird verlassen
make[1]: *** [Makefile:395: all-recursive] Fehler 1
make[1]: Verzeichnis „/home/gorzka/Downloads/DOSBox ECE r4194 (Linux source)“ wird verlassen
make: *** [Makefile:336: all] Fehler 2

The mt32emu library is not in the Source code.

I compiled a 64bit version of DOSBox ECE r4194 without problems on Fedora 29, once I installed the mt32 munt packages. I have libmt32emu-2.3.0-1.x86_64 and libmt32emu-devel-2.3.0-1.x86_64 RPMs installed from the munt website.

Reply 594 of 1550, by Yesterplay80

User metadata
Rank Oldbie
Rank
Oldbie

I ran into this problem initially as well: Re: Munt Reloaded - Development

Turned out you have set the following parameter to false when building mt32emu with CMAKE:

libmt32emu_REQUIRE_ANSI

Not related, bu you have to enable both the C and the C++ interaface as well, so set these here to true:

libmt32emu_C_INTERFACE
libmt32emu_CPP_INTERFACE

My full-featured DOSBox SVN builds for Windows & Linux: Vanilla DOSBox and DOSBox ECE (Google Drive Mirror)

Reply 595 of 1550, by Roger Wilco

User metadata
Rank Newbie
Rank
Newbie

Helloes,

I tried both versions, the ECE version and the normal SVN on Linux Debian 9 right now, downloaded from the Yesterplay80 blog.

I am getting an error...
./dosbox: error while loading shared libraries: libSDL_sound-1.0.so.1: cannot open shared object file: No such file or directory.

...although the file is there, with locate:
/usr/lib/x86_64-linux-gnu/libSDL_sound-1.0.so.1

What am I missing?
Normal Dosbox is installed via apt and works.

Reply 596 of 1550, by krcroft

User metadata
Rank Oldbie
Rank
Oldbie

DOSBox ECE contains a patch that removes link-dependence on SDL Sound and related libraries (ogg, vorbis, flac, mp3, midi, etc.. )

For example, when compiled on my system, these are the dependencies:

ldd /usr/local/bin/dosbox
linux-vdso.so.1 (0x00007ffc208bf000)
libasound.so.2 => /usr/lib/x86_64-linux-gnu/libasound.so.2 (0x00007f4ea9fcf000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f4ea9db0000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f4ea9bac000)
libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007f4ea9874000)
libGL.so.1 => /usr/lib/x86_64-linux-gnu/libGL.so.1 (0x00007f4ea95e8000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f4ea924a000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f4ea8e59000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4ead7f0000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f4ea8c51000)
libxcb.so.1 => /usr/lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f4ea8a29000)
libGLX.so.0 => /usr/lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f4ea87f8000)
libGLdispatch.so.0 => /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f4ea8542000)
libXau.so.6 => /usr/lib/x86_64-linux-gnu/libXau.so.6 (0x00007f4ea833e000)
libXdmcp.so.6 => /usr/lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f4ea8138000)
libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f4ea7f23000)

If you can compile ECE, I recommend trying to eliminate the unnecessary library dependencies. Otherwise it seems that other libraries are linking in libSDL_sound-1.0.so.1 as a dependency.

You can see your library's dependencies with this simply loop:

for lib in $(ldd /usr/local/bin/dosbox | awk '{ print $3 }'); do echo "$lib"; ldd "$lib"; echo ''; done 

Reply 598 of 1550, by pantercat

User metadata
Rank Newbie
Rank
Newbie

Maybe you've downloaded the binary instead of the source?

DOSBox ECE rXXXX (Linux).7z is 32-bit. If your system is 64-bit and you do not want ie install multiarch, download DOSBox ECE rXXXX (Linux source).7z && extract && compile.

./configure && ./autogen.sh && make

You will have the binary in the src directory.

Reply 599 of 1550, by _Rob

User metadata
Rank Member
Rank
Member
Roger Wilco wrote:
Helloes, […]
Show full quote

Helloes,

I tried both versions, the ECE version and the normal SVN on Linux Debian 9 right now, downloaded from the Yesterplay80 blog.

I am getting an error...
./dosbox: error while loading shared libraries: libSDL_sound-1.0.so.1: cannot open shared object file: No such file or directory.

...although the file is there, with locate:
/usr/lib/x86_64-linux-gnu/libSDL_sound-1.0.so.1

What am I missing?
Normal Dosbox is installed via apt and works.

As others have hinted at, it seems you installed the 64bit version of the SDL libraries, which do not work with the 32bit version of DOSBox.

So, either install the 32bit version of the SDL libraries (you can have both 32 and 64bit versions installed simultaneously), or compile yourself a 64bit version of DOSBox.