VOGONS


DOSBox ECE (for Windows & Linux)

Topic actions

Reply 1460 of 1508, by morphinejh

User metadata
Rank Newbie
Rank
Newbie
Yesterplay80 wrote on 2022-06-06, 19:00:

ECE still uses Fluidsynth 1.16, because the patch I use doesn't work with never versions, so it might as well be that the current options are still correct and working. Could someone try that out maybe?

I did a quick compile of fluidsynth 1.1.6 (circa 2012) and DosboxECE r4477. It didn't throw any errors as is.

I then did a quick test by changing
fluid_settings_setint(settings, "audio.periods", atoi(section->Get_string("fluid.periods")));
to
fluid_settings_setnum(settings, "audio.periods", atoi(section->Get_string("fluid.periods")));

...and also did not get any errors.

More thorough testing could be performed, but it seems either function works in the older version, and the newer version enforces you call setint for integers and setnum for floats.

Reply 1461 of 1508, by LukasThyWalls

User metadata
Rank Newbie
Rank
Newbie

Hi.

I was trying to do something i read here it was asked before here, about the Linux build in Yesterplay/DOSBox ECE website being the 32 bit build, and the issues to make it work in a 64 bit Linux OS (KUbuntu 22.04 in my case). I tried to do what has been explained before here, but i think now it is even harder to do because missing libraries in the distribution.

First, it has missing libSDL-1.2.so.0:

DOSBox ECE/bin$ ./dosbox
./dosbox: error while loading shared libraries: libSDL-1.2.so.0: cannot open shared object file: No such file or directory

But, as explained in this thread, you can install the 32 bit library directly with apt

sudo apt install libsdl1.2debian:i386

Second, it has missing libpng12.so.0:

DOSBox ECE/bin$ ./dosbox
./dosbox: error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory

The issue is there isn't libpng12 libraries in ubuntu repositories since 16.10, there are the libpng16:

DOSBox ECE/bin$ apt search libpng12 Ordenando... Hecho Buscar en todo el texto... Hecho DOSBox ECE/bin$ apt search libpng16 Ord […]
Show full quote

DOSBox ECE/bin$ apt search libpng12
Ordenando... Hecho
Buscar en todo el texto... Hecho

DOSBox ECE/bin$ apt search libpng16
Ordenando... Hecho
Buscar en todo el texto... Hecho
libpng16-16/jammy,now 1.6.37-3build5 amd64 [instalado, automático]
PNG library - runtime (version 1.6)

There is a PPA with libpng12 https://launchpad.net/~linuxuprising/+archive … ubuntu/libpng12, but it have libpng12 versions until 21.10 (for now at least), and not for 22.04.

So, the only option is to compile the libraries, and in that case, maybe is better to compile DOSBox ECE itself also, although i would prefer to use the 32 bit version because i also read here the 32 bit have a better performance and compatibility than the 64 bit version (i know you can do that, but it is more complications, at least for a low/mid linux user).

That make me to the point, why to have the compiled 32 bit DOSBox ECE to download if it have these issues to make it work in a contemporary Linux OS, the reason to have it is to use easily extracting it and launch, installing the required libraries, but actually it can't be done. I don't know if it can be compiled with other dependencies that can be satisfied more easily now or scrap the linux build directly.

Thanks!

Reply 1462 of 1508, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
LukasThyWalls wrote on 2022-06-08, 08:32:

i would prefer to use the 32 bit version because i also read here the 32 bit have a better performance and compatibility than the 64 bit version

This hasn't been true for a couple of years.

Reply 1463 of 1508, by realnc

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote on 2022-06-08, 11:05:
LukasThyWalls wrote on 2022-06-08, 08:32:

i would prefer to use the 32 bit version because i also read here the 32 bit have a better performance and compatibility than the 64 bit version

This hasn't been true for a couple of years.

When running ./configure on an x86-64 machine, config.h has:

/* Define to 1 to use x86/x64 dynamic cpu core */
#define C_DYNAMIC_X86 1

/* Define to 1 to use recompiling cpu core. Can not be used together with the
dynamic-x86 core */
/* #undef C_DYNREC */

On x86, C_DYNREC is available. Doesn't that mean x86 is faster?

Edit:
Never mind. Above is not true. C_DYNREC is off by default on x86 as well. C_DYNAMIC_X86 is the faster core and is available for both x86 and x86-64.

Reply 1464 of 1508, by morphinejh

User metadata
Rank Newbie
Rank
Newbie
LukasThyWalls wrote on 2022-06-08, 08:32:

So, the only option is to compile the libraries, and in that case, maybe is better to compile DOSBox ECE itself also, although i would prefer to use the 32 bit version because i also read here the 32 bit have a better performance and compatibility than the 64 bit version (i know you can do that, but it is more complications, at least for a low/mid linux user).

As previously stated, I don't think the 32-bit version is any better. The only test I've actually ran is on non-x86 hardware; and the Raspberry PI 4 runs it faster on 64-bit than on 32-bit. But any recently modern 64-bit hardware can run it with no problems on the x86-64 architectures.

LukasThyWalls wrote on 2022-06-08, 08:32:

That make me to the point, why to have the compiled 32 bit DOSBox ECE to download if it have these issues to make it work in a contemporary Linux OS, the reason to have it is to use easily extracting it and launch, installing the required libraries, but actually it can't be done. I don't know if it can be compiled with other dependencies that can be satisfied more easily now or scrap the linux build directly.

This is a good point. Compiling for 32-bit on modern hardware is probably not a good direction. And I can say compiling it for 64-bit hardware has taken little modifications:
- the recent fluidsynth API changes (which still compile but give an error at runtime)
- and some API change in autotools that still work but give deprecation warnings.

Other than that, not very bad getting a clean compile on new 64-bit Linux OSes with the default repositories from the sources Yesterplay80 has posted. Only exception is munt which is compiled separately on any Linux distro I've used.

Reply 1465 of 1508, by LukasThyWalls

User metadata
Rank Newbie
Rank
Newbie
jmarsh wrote on 2022-06-08, 11:05:
LukasThyWalls wrote on 2022-06-08, 08:32:

i would prefer to use the 32 bit version because i also read here the 32 bit have a better performance and compatibility than the 64 bit version

This hasn't been true for a couple of years.

Thanks @jmarsh, @realnc and @morphinjh, that's one of the topics i want to bring to this because that's why i read in this same thread but it was messages from 2019, i think. Maybe @Yesterplay80 think otherwise, because then i don't understand why he is still building the 32 bit build at his website with those issues with the dependencies (maybe he don't know), so that's why i asking if it's not better to build the 64 bit build at this point or not building any one for Linux, at least until there is no issues whatsoever and it easier to maintain.

EDIT: I just compiled DOSBox ECE 64 bits and seems to work, so i'm going to do a recap (by memory) because for sure there are things i did that are not needed and some that later i realized that can be much better done:

* I extracted the source of dosbox-0.74-3 and copied above the files from the source of DOSBox ECE r4477 (maybe i should use the DOSBox SVN, but i thought that later). EDIT: You need to use dos2unix in autogen.sh to change the text format first! dosunix autogen.sh. Also use chmod +x autogen.sh to make it executable.

* Install some dependencies: sudo apt install libsdl1.2-dev libx11-dev libxkbfile-dev libxext-dev libncurses5-dev libavcodec-dev libswscale-dev libavformat-dev automake build-essential (maybe i'm missing something and other are not really needed). EDIT: Also suggested sudo apt install libfluidsynth3 libfluidsynth-dev libsdl-net1.2 libsdl-net1.2-dev

* During compiling, i had the mt32emu/mt32emu.h missing error. To put that file in the system i went to https://sourceforge.net/projects/munt/files/m … inux/deb/amd64/ and downloaded and installed libmt32emu-2.6.1.deb and libmt32emu-dev-2.6.1.deb (Both are from the most recent stable version, 2.6.2, and also i had to install them with dpkg because QApt seems to have some issues with them about checking dependencies). EDIT: It works with this, but you can use the last source. Some advice can be found below here.

* Also during compiling, i had the sdk2_glide.h missing error (and later related sdk2_3dfx.h, sdk2_glidesys.h, sdk2_sst1vid.h, sdk2_glideutl.h). For this i downloaded OpenGlide master branch https://github.com/voyageur/openglide and do ./bootstrap && ./configure && make && sudo make install, and copying sdk2_glide.h, sdk2_3dfx.h, sdk2_glidesys.h, sdk2_sst1vid.h and sdk2_glideutl.h from the OpenGlide master Source to the include folder in DOSBox ECE Source.

* In the DOSBox source folder: First ./autogen.sh (remember using dos2unix ./autogen.sh first), and then ./configure (EDIT: Suggested ./configure CFLAGS="-O3" CXXFLAGS="-O3" or ./configure CFLAGS="-Ofast" CXXFLAGS="-Ofast") and make.

* Once there is a dosbox executable in the src folder, use strip dosbox from there to shrink the size (from >20MB to <4MB).

With that, i have a linux 64 bit dosbox ECE executable, in KUbuntu 22.04, which one i tested with some games.

Any advice will be appreciated! Thanks!

EDIT: Suggestions by @morphinejh. Thanks!

Last edited by LukasThyWalls on 2022-06-11, 19:39. Edited 3 times in total.

Reply 1466 of 1508, by morphinejh

User metadata
Rank Newbie
Rank
Newbie

Great job!

My few comments:

LukasThyWalls wrote on 2022-06-09, 17:19:

* I extracted the source of dosbox-0.74-3 and copied above the files from the source of DOSBox ECE r4477 (maybe i should use the DOSBox SVN, but i thought that later).

I'm not sure what this means. The source for DosboxECE should be all you need.

LukasThyWalls wrote on 2022-06-09, 17:19:

* Install some dependencies: sudo apt install libsdl1.2-dev libx11-dev libxkbfile-dev libxext-dev libncurses5-dev libavcodec-dev libswscale-dev libavformat-dev automake build-essential (maybe i'm missing something and other are not really needed).

Suggested additional libraries

  • libfluidsynth3 , libfluidsynth-dev; these were missing so your compile may have been build without sound font capabilities for midi tunes.
  • libsdl-net1.2, libsdl-net1.2-dev; for network play and such if desired.

Suggested additional compile option (not vital, but may boost performance if needed):

  • ./configure CFLAGS="-O3" CXXFLAGS="-O3"
    OR
  • ./configure CFLAGS="-Ofast" CXXFLAGS="-Ofast"

Also this topic for a deep dive: DOSBox Compilation Guides

LukasThyWalls wrote on 2022-06-09, 17:19:

* During compiling, i had the mt32emu/mt32emu.h missing error. To put that file in the system i went to https://sourceforge.net/projects/munt/files/m … inux/deb/amd64/ and downloaded and installed libmt32emu-2.6.1.deb and libmt32emu-dev-2.6.1.deb (Both are from the most recent stable version, 2.6.2, and also i had to install them with dpkg because QApt seems to have some issues with them about checking dependencies).

Absolute newest version is 2.6.3, but you'll have to compile from source. It's very easy considering what you have already done. And you only need the libmt32emu package to get DosboxECE working. This is not a necessity compared to 2.6.1...
https://github.com/munt/munt

Reply 1468 of 1508, by morphinejh

User metadata
Rank Newbie
Rank
Newbie

@Yesterplay80, @supin

Yesterplay80 wrote on 2022-06-04, 00:39:
supin wrote on 2022-06-02, 16:32:

Hello.
You have an error in your code src/gui/midi_fluidsynth.h

Even though that wasn't the cause of MIDI playback not working (see above) I appreciate pointing this error out, thank you very much! That should be fixed as well.

I believe there is an error with this code. I didn't realize until I was comparing r4479 to r4477. The code in that post is doing a direct comparison between two character arrays (const char*) using ==. This is undefined behavior as it is really just comparing the value of two pointers and not the string itself. If they were C++ string types it would work, but they appear to be simple character arrays.

It is defined on line 289 of: include/setup.h
const char* Get_string(std::string const& _propname) const;

The correct way to do the comparison would be using the strcmp() function like this:

		if (strcmp(section->Get_string("reverb.active"),"yes") != 0) {
fluid_settings_setint(settings, "synth.reverb.active", 0);
} else {
fluid_settings_setint(settings, "synth.reverb.active", 1);
}

if (strcmp(section->Get_string("chorus.active"),"yes") != 0) {
fluid_settings_setint(settings, "synth.chorus.active", 0);
} else {
fluid_settings_setint(settings, "synth.chorus.active", 1);
}

Every C-string comparison should use that function. It returns 0[zero] if they match. You can find the entire file I use here:
https://github.com/morphinejh/dosboxece-opl/b … di_fluidsynth.h

The file I use has been adapted for the new fluidsynth API so it may differ slightly from what DosboxECE uses in its source, but the the string compare function is correct for any comparison.

EDIT: Adding original post for reference.

supin wrote on 2022-06-02, 16:32:
[…]
Show full quote
                fluid_settings_setint(settings, "audio.periods", atoi(section->Get_string("fluid.periods")));
fluid_settings_setint(settings, "audio.period-size", atoi(section->Get_string("fluid.periodsize")));
if (section->Get_string("fluid.reverb")=="yes")
fluid_settings_setint(settings, "synth.reverb.active", 1);
else
fluid_settings_setint(settings, "synth.reverb.active", 0);
if (section->Get_string("fluid.chorus")=="yes")
fluid_settings_setint(settings, "synth.chorus.active", 1);
else
fluid_settings_setint(settings, "synth.chorus.active", 0);

Reply 1469 of 1508, by Ringding

User metadata
Rank Member
Rank
Member

The thing about the string comparisons seems to be correct.

morphinejh, I looked at your repo and noticed that there are a few header files that seem out of place and I don’t know where they are coming from (include/sdk2_*).

Reply 1470 of 1508, by morphinejh

User metadata
Rank Newbie
Rank
Newbie
Ringding wrote on 2022-06-11, 07:46:

The thing about the string comparisons seems to be correct.

morphinejh, I looked at your repo and noticed that there are a few header files that seem out of place and I don’t know where they are coming from (include/sdk2_*).

Good question, this is for the openglide support that was recently reintroduced. I'm using the source from here, unedited, which is why it is included.

https://github.com/voyageur/openglide

EDIT: Also re-added the reference to the Readme.md on github so other know where its coming from too.

Reply 1471 of 1508, by LukasThyWalls

User metadata
Rank Newbie
Rank
Newbie
morphinejh wrote on 2022-06-10, 23:35:
LukasThyWalls wrote on 2022-06-09, 17:19:

* I extracted the source of dosbox-0.74-3 and copied above the files from the source of DOSBox ECE r4477 (maybe i should use the DOSBox SVN, but i thought that later).

I'm not sure what this means. The source for DosboxECE should be all you need.

For sure is something about me being a noob, but with DOSBox 0.74.3 Source, i only need to do ./configure && make, and with only the DOSBox ECE Source:

DOSBox ECE r4479 (source)$ chmod +x autogen.sh DOSBox ECE r4479 (source)$ ./autogen.sh bash: ./autogen.sh: /bin/sh^M: intérprete […]
Show full quote

DOSBox ECE r4479 (source)$ chmod +x autogen.sh
DOSBox ECE r4479 (source)$ ./autogen.sh
bash: ./autogen.sh: /bin/sh^M: intérprete erróneo: No existe el archivo o el directorio

DOSBox ECE r4479 (source)$ ./configure
bash: ./configure: No existe el archivo o el directorio

DOSBox ECE r4479 (source)$ make
make: *** No se especificó ningún objetivo y no se encontró ningún makefile. Alto.

And with the DOSBox ECE Source copied above the DOSBox Source, only with ./configure && make works and generates a DOSBox ECE executable. I know it's weird, but it's what it worked for me.

EDIT:
I found the issue, autogen.sh is in DOS text format (i suppose the endline characters), so you need to use dos2unix to change it and it works!

morphinejh wrote on 2022-06-10, 23:35:
LukasThyWalls wrote on 2022-06-09, 17:19:

* During compiling, i had the mt32emu/mt32emu.h missing error. To put that file in the system i went to https://sourceforge.net/projects/munt/files/m … inux/deb/amd64/ and downloaded and installed libmt32emu-2.6.1.deb and libmt32emu-dev-2.6.1.deb (Both are from the most recent stable version, 2.6.2, and also i had to install them with dpkg because QApt seems to have some issues with them about checking dependencies).

Absolute newest version is 2.6.3, but you'll have to compile from source. It's very easy considering what you have already done. And you only need the libmt32emu package to get DosboxECE working. This is not a necessity compared to 2.6.1...
https://github.com/munt/munt

Yes, i was trying to make as easiest i can for a normal user, because i tried to compiled it but you need more dependencies what i need to figure out (just need cmake, qt5-qmake qtbase5-dev, or qmake6 qt6-base-dev, or all to forget the issues), and then cmake && make and sudo make install.

Reply 1472 of 1508, by Crysli

User metadata
Rank Newbie
Rank
Newbie

Not sure if I have to post this here or in the PC speaker patch thread..
I found that in F-15 Strike Eagle II and F-117A the speech played when you start/complete a mission is corrupted and I think it's caused by that patch.
Sounds perfectly on vanilla DOSBox.

Reply 1473 of 1508, by realnc

User metadata
Rank Oldbie
Rank
Oldbie

I'm setting up automated builds for Linux binaries as AppImages that contain all needed, uncommon libraries. I've uploaded a test build for x86-64 here:

https://github.com/realnc/dosbox-ece/releases … ag/latest_build

It should run on any Linux distro that's at least as recent as Ubuntu 16.04. That's over 6 years old now, so hopefully it means it runs virtually everywhere. If this works for people, I'll set up the github repo that does these builds for x86, arm32 and arm64 (should work on Raspberry Pi) as well.

To use this, simply mark it executable (chmod +x DOSBox_ECE-test-x86_64.AppImage) and run it. On Ubuntu 22.04 or other very recent Linux distros, you need to install libfuse2 (sudo apt-get libfuse2). This annoyance will hopefully be fixed in the future. The AppImage devs are working on it.

You can rename it to just "dosbox" if you want. The full filename is really just to distinguish the downloads. The ".AppImage" file extension is only useful if you've installed special AppImage support for your desktop.

If you want to see what's in the AppImage, simply run it with --appimage-extract as argument. This will extract the contents into a directory called "squashfs-root".

Last edited by realnc on 2022-08-21, 11:24. Edited 3 times in total.

Reply 1475 of 1508, by realnc

User metadata
Rank Oldbie
Rank
Oldbie
jmarsh wrote on 2022-06-13, 00:03:

Wouldn't linking with static libraries be easier?

To do that you'd need to manually build all the libraries first. With this approach, you just bundle the libraries provided by Ubuntu 16.04. I might still do that (I already do manual static library builds for dosbox-core.) But for now, let's just see how well it works in general. Switching to static libs can then happen one lib at a time.

Reply 1476 of 1508, by realnc

User metadata
Rank Oldbie
Rank
Oldbie

Alright, it's now up (https://github.com/realnc/dosbox-ece). Builds for x86 and ARM, both 32-bit and 64-bit are here:

https://github.com/realnc/dosbox-ece/releases … ag/latest_build

The builds are performed on CircleCI (because they offer ARM build machines, not just x86.) The official Ubuntu 16.04 docker images are used for the build. The workflow file can be found in https://github.com/realnc/dosbox-ece/blob/mas … leci/config.yml.

Ideally, this repo should not be mine, but should be moved to Yesterplay80's github account. But if you're not familiar with any of this, I'll try and push new versions of ECE as soon as I can. If you want to link to the downloads from https://yesterplay.net/dosboxece, the above URL should always work.

Reply 1478 of 1508, by morphinejh

User metadata
Rank Newbie
Rank
Newbie
realnc wrote on 2022-06-13, 00:58:

Alright, it's now up (https://github.com/realnc/dosbox-ece). Builds for x86 and ARM, both 32-bit and 64-bit are here:

https://github.com/realnc/dosbox-ece/releases … ag/latest_build

I've tested the following with a few games and it seems to work great (i.e. the same) and with the same configuration file I already had.

  • dosbox-ece-x86_64.AppImage
  • dosbox-ece-aarch64.AppImage

Reply 1479 of 1508, by realnc

User metadata
Rank Oldbie
Rank
Oldbie
morphinejh wrote on 2022-06-13, 17:24:
I've tested the following with a few games and it seems to work great (i.e. the same) and with the same configuration file I alr […]
Show full quote

I've tested the following with a few games and it seems to work great (i.e. the same) and with the same configuration file I already had.

  • dosbox-ece-x86_64.AppImage
  • dosbox-ece-aarch64.AppImage

Thanks for testing!

There was a problem with the 32-bit builds. They would crash when using the dynamic CPU core because dosbox detects the wrong target CPU when building a 32-bit version on a 64-bit host.

This has been fixed in the x86 build. But the arm32 ("armhf") build unfortunately now lacks a dynamic CPU core. I will need to fix that.