OK, building Munt with Cmake in VS 2017, I got as far as this:

1Could NOT find libsoxr
2Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) 
3Could NOT find libsamplerate
4Configuring done

and I'm afraid that the rest is beyond my abilities at the moment. I'll keep working at it, but if anyone has VS 2015 or VS 2017 compiled code for Munt that they're willing to share, and that can be used for building ECE, I'll be grateful. But I expect the right answer is that I should figure out how to do this for myself...

emendelson wrote:

OK, building Munt with Cmake in VS 2017, I got as far as this: […]
Show full quote

OK, building Munt with Cmake in VS 2017, I got as far as this:

Copy code to clipboard

1Could NOT find libsoxr
2Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE) 
3Could NOT find libsamplerate

Those errors are fixed easily:
libsoxr and libsamplerate -> just activate option "libmt32emu_WITH_INTERNAL_RESAMPLER" in Cmake GUI
PkgConfig -> simply install it in your build environment, you can get it here: https://www.freedesktop.org/wiki/Software/pkg-config/
And make sure to set CMAKE_BUILD_TYPE to release, to activate libmt32emu_C_INTERFACE and to deactivate libmt32emu_REQUIRE_ANSI and libmt32emu_SHARED.

emendelson wrote:

But I expect the right answer is that I should figure out how to do this for myself...

It's definitely more satisfying and you can learn much more from fixing errors on your own. 😀

Yesterplay80 wrote:

It's definitely more satisfying and you can learn much more from fixing errors on your own. 😀

Yes, it is! I installed the VS 2017 build tools, and didn't need to install pkgconfig to succeed at this, following your instructions. In the hope that it helps someone else, here's a screen shot of my CMake setup after I made the changes you suggested.

When generating was done, I clicked Open Project, and the project opened in VS2017. I chose Build, and it worked.

Am I right to think that I need to take the "include" folder from the output and add it to my DOSBox-ECE project as an additional include folder? (I'm away from that machine at the moment.)

And is there anything I need to do to fix the remaining error that I got when I tried to build last time:

1c:\users\edward\desktop\dosboxece-source\src\gui\sdlmain.cpp(836): error C4716: 'ssStartUpdate': must return a value

Again, a thousand thanks for your patient help!

EDIT: And I tried this with no joy:

https://social.msdn.microsoft.com/Forums/vstu … forum=vcgeneral

EDIT: Obsolete content removed.

This replaces a batch of messages above (now deleted):

I finally managed to build DOSBox-ECE in VS 2017 (with a million linker warnings), but I had to make two changes in the code in order to build it at all, and the resulting build launches but immediately locks up after creating an all-black window. The changes I made were these:

First, my guess is that this is not a problem. I fixed these errors:

11>..\src\hardware\opl.cpp(484): error C3861: 'memset': identifier not found
2    1>..\src\hardware\opl.cpp(485): error C3861: 'memset': identifier not found
3    1>..\src\hardware\opl.cpp(486): error C3861: 'memset': identifier not found
4    1>..\src\hardware\opl.cpp(972): error C3861: 'memset': identifier not found

by adding this to opl.cpp:

1#include <cstring>

Next, not knowing what I was doing, but just throwing code into the editor until something worked, I worked around this error:

1c:\users\edward\desktop\dosboxece-source\src\gui\sdlmain.cpp(836): error C4716: 'ssStartUpdate': must return a value

by adding a return string here (which is clearly wrong, but I have no idea of what I should do instead):

1char ssStartUpdate( Bit8u **pixels, Bitu *pitch )
2    {
3       sdl.SurfaceInfo.StartUpdate(pixels, pitch);  return ssStartUpdate(pixels, pitch); 
4    }

Presumably this stupid mistake is why the build locks up, but I don't know how to fix the mistake.

This is the console output when I launch this build:

1CONFIG:Loading primary settings from config file C:\Users\Edward\AppData\Local\DOSBox\dosbox-SVN.conf
2MIDI: Opened device:win32
3PC speaker output buffer length: 145
4mixer callback wants too many samples from pc speaker emulator: 1103
5mixer callback wants too many samples from pc speaker emulator: 957
6mixer callback wants too many samples from pc speaker emulator: 812
7mixer callback wants too many samples from pc speaker emulator: 667
8mixer callback wants too many samples from pc speaker emulator: 522
9mixer callback wants too many samples from pc speaker emulator: 377
10mixer callback wants too many samples from pc speaker emulator: 232
11Available area: 1904x1038
12Color data offset: 0
13Scaling: 640x400 (1.20) --[2.0 x 2.0]--> 1280x800  (1.00)

Is it possible that the mixer callback issues are causing the lockup? Presumably it's my bad attempt to fix the SDLmain.cpp error.

Anyway, thanks to everyone who has tolerated my earlier messages about this...

Yesterplay80, you've already been enormously generous to everyone on this thread, but here's a request I hope you might consider:

Could you spell out what you do when building in MinGW that isn't already in the Wiki? I've decided to start over with MinGW, but am still trying to figure out what to do with munt - where to put the files that got built in mt32emu/include/mt32emu, what to add to configure, etc., etc? I realize that I'm asking you to do a lot of work, but I hope it's a good idea for your project if more people can experiment with the build. Thank you...

emendelson wrote:

Is it possible that the mixer callback issues are causing the lockup? Presumably it's my bad attempt to fix the SDLmain.cpp error.

The mixer callback errors are normal and probably not the cause of the lockups. Did you try your build on more than one computer? Maybe it works on another?
For starters, why not try building the vanilla SVN first? If this one works, you can start worrying about the further steps, if it doesn't, you don't even have to worry about them and try to get your MINGW environment right first.

emendelson wrote:

Could you spell out what you do when building in MinGW that isn't already in the Wiki?

I just start a script whenever a new version is released. 😉

OK, seriously: First you have to prepare your environment: In addition to the procedure explained in the wiki, of course you need to have working mt32emu and fluidsynth (and its pesky dependencies) libraries installed in your MINGW environment. With Fluidsynth I'm stuck at 1.16 at the moment, because with 1.19 DOSBox crashes every time when I close it (Maybe that's your problem?), mt32emu is the newest version (2.3.0). I also use updated versions of libpng (1.6.34) and zlib (1.2.11), but that shouldn't matter. If you set up MINGW correctly, the required files should get copied into your environment automatically when you use the "make install" command after creating the necessary files with CMAKE, if not you have to point it to the right directory, e.g. C:/MINGW with the parameter CMAKE_INSTALL_PREFIX.

Generally Fluidsynth is getting more and more a pain in the ass to compile under windows! 1.16 only compiled using an older version of GCC (I used 4.4.0), for 1.19 I had to use MSYS2 to get it compiled. Plus you need to make sure you have all the libraries it depends on, as they are are listed in this guide. I tried using other versions, that don't depend on all that crap, but those didn't work, neither did the newest one. I think it would require an updated patch for those. However, if you got everything right, the outpout of the ./configure command should show this:

1checking for new_fluid_synth in -lfluidsynth... yes
2checking fluidsynth.h usability... yes
3checking fluidsynth.h presence... yes
4checking for fluidsynth.h... yes
5checking for FluidSynth support... yes

Apart from that, the only thing I do different than how it's described in the wiki, is the configuration of the optimization. Instead of -O2 I use -O3, because it speeds up the pixel perfect rendering method "surfacepp", as Ant222 found out:

1./configure --enable-core-inline CFLAGS="-s [b]-O3[/b]" CXXFLAGS="-s [b]-O3[/b]" LDFLAGS="-static-libgcc -static-libstdc++ -s" LIBS="-lvorbisfile -lvorbis -logg"

Could you post the output of MINGW, when you try to build ECE? Especially the configuring part might be interesting.

Yes, I tried the build on two machines - Win10-64 (where I built it) and Win7-32. Same crash in both. Is it possible that my improvised fix in sdlmain.cpp is at fault here?

Yesterplay80 wrote:

emendelson wrote:

For starters, why not try building the vanilla SVN first? If this one works, you can start worrying about the further steps, if it doesn't, you don't even have to worry about them and try to get your MINGW environment right first.

emendelson wrote:

Could you spell out what you do when building in MinGW that isn't already in the Wiki?

I just start a script whenever a new version is released. 😉

I built vanilla SVN successfully a few months ago, following the wiki, so I hoped this wouldn't be too difficult. Thank you for those details - and I'll give it all a try and report back, probably this weekend. (I need a free block of time.)

One thing I need to sort out is that there's something wrong with my current Msys setup, I think - when I give the make command, a Windows cmd prompt opens - probably because I've got the path set up incorrectly. I'll work on this, because it's obviously important to get that fixed first. It seems to be why the munt files aren't getting installed correctly.

Again, thanks for these explanations!

My guide may or may not be helpful. VS and MINGW provided. Only vanilla for now tho since I've been busy and not much help with the guide except for one other person
Post 636941

emendelson wrote:

Yes, I tried the build on two machines - Win10-64 (where I built it) and Win7-32. Same crash in both. Is it possible that my improvised fix in sdlmain.cpp is at fault here?

This one?

1char ssStartUpdate( Bit8u **pixels, Bitu *pitch )
2    {
3       sdl.SurfaceInfo.StartUpdate(pixels, pitch);  return ssStartUpdate(pixels, pitch);
4    }

ssStartUpdate is called. ssStartUpdate calls itself. Then the 2nd ssStartUpdate calls itself. And this continues to infinity. Yeah, that looks like it might cause some problems.

Try this instead:

1char ssStartUpdate( Bit8u **pixels, Bitu *pitch )
2{	return sdl.SurfaceInfo.StartUpdate( pixels, pitch );  }

zirkoni wrote:

Try this instead: […]
Show full quote

Try this instead:

Copy code to clipboard

1char ssStartUpdate( Bit8u **pixels, Bitu *pitch )
2{	return sdl.SurfaceInfo.StartUpdate( pixels, pitch );  }

That fixed it! Thank you! As I said, my programming technique is to throw random bits of code at the screen without having any idea of whether or not they produce infinite loops or divide by zero or anything else. I'm aware that there are some limitations to that method...

Thank you again!

Yesterplay80 wrote:

OK, seriously: First you have to prepare your environment: In addition to the procedure explained in the wiki, of course you nee […]
Show full quote

OK, seriously: First you have to prepare your environment: In addition to the procedure explained in the wiki, of course you need to have working mt32emu and fluidsynth (and its pesky dependencies) libraries installed in your MINGW environment. With Fluidsynth I'm stuck at 1.16 at the moment, because with 1.19 DOSBox crashes every time when I close it (Maybe that's your problem?), mt32emu is the newest version (2.3.0). I also use updated versions of libpng (1.6.34) and zlib (1.2.11), but that shouldn't matter. If you set up MINGW correctly, the required files should get copied into your environment automatically when you use the "make install" command after creating the necessary files with CMAKE, if not you have to point it to the right directory, e.g. C:/MINGW with the parameter CMAKE_INSTALL_PREFIX.

Generally Fluidsynth is getting more and more a pain in the ass to compile under windows! 1.16 only compiled using an older version of GCC (I used 4.4.0), for 1.19 I had to use MSYS2 to get it compiled. Plus you need to make sure you have all the libraries it depends on, as they are are listed in this guide. I tried using other versions, that don't depend on all that crap, but those didn't work, neither did the newest one. I think it would require an updated patch for those. However, if you got everything right, the outpout of the ./configure command should show this:

Copy code to clipboard

1checking for new_fluid_synth in -lfluidsynth... yes
2checking fluidsynth.h usability... yes
3checking fluidsynth.h presence... yes
4checking for fluidsynth.h... yes
5checking for FluidSynth support... yes

Apart from that, the only thing I do different than how it's described in the wiki, is the configuration of the optimization. Instead of -O2 I use -O3, because it speeds up the pixel perfect rendering method "surfacepp", as Ant222 found out:

Copy code to clipboard

1./configure --enable-core-inline CFLAGS="-s [b]-O3[/b]" CXXFLAGS="-s [b]-O3[/b]" LDFLAGS="-static-libgcc -static-libstdc++ -s" LIBS="-lvorbisfile -lvorbis -logg"

Could you post the output of MINGW, when you try to build ECE? Especially the configuring part might be interesting.

To continue this: I finally realized that I wasn't having any problems with fluidsynth under Visual Studio, because VS uses config.h, not configure.ac to define what gets included, and there's no reference to fluidsynth in config.h. This means that anyone who wants a complete ECE build will have to go through those steps that you described. I'll take a deep breath and maybe try to do this, but it may be beyond my abilities.

Is there any chance you might consider making a build environment available (perhaps also for Visual C++), like the environment available for the DOSBox-X branch? It's obviously a lot of work to put that kind of thing together, but it might encourage other people to work on the code. I put together a VS environment for vanilla SVN, which I posted on another thread, so I have some idea of how much work goes into it. Meanwhile, if I get anywhere, I'll post the output from MinGW if I get that far. Thank you again!

Might as well ask, Yesterplay... is there any chance you could add the datestamp/timestamp support into ECE in the future? Kinda like the original dates/times to be kept on files during extraction where it was allowed on original DOS. It was/is a positive feature of Daum for me as well as in DOSBox-X.

emendelson wrote:

This means that anyone who wants a complete ECE build will have to go through those steps that you described.

Actually, anyone who wants a complete build can just download it, at least for Windows. What exactly are you trying to achive by compiling ECE yourself?

emendelson wrote:

Is there any chance you might consider making a build environment available (perhaps also for Visual C++), like the environment available for the DOSBox-X branch?

TBH, I don't want to mess around with Visual Studio any more, I installed it once and the whole thing seemed just bloated, it takes up gis of valuable hard drive capacity (my system is installed on a 250GB SSD). I might upload my whole MINGW environment though, you'd only have to set a PATH in your system environment and rename the user folder in it.

marzsyndrome wrote:

Might as well ask, Yesterplay... is there any chance you could add the datestamp/timestamp support into ECE in the future? Kinda like the original dates/times to be kept on files during extraction where it was allowed on original DOS. It was/is a positive feature of Daum for me as well as in DOSBox-X.

What would support for that bring? Do any games require or benefit from that?

Yesterplay80 wrote:

emendelson wrote:

This means that anyone who wants a complete ECE build will have to go through those steps that you described.

Actually, anyone who wants a complete build can just download it, at least for Windows. What exactly are you trying to achive by compiling ECE yourself?

I'd like to add some modifications that I've made to SVN for my own project - char9 fonts, some custom video modes that I use for text-based applications, a clipboard-paste feature taken from old dbDOS code. I've done this with SVN and Msys. But of course there's no reason for anyone else to do any work to make this possible. You'e done more than enough already...!

Hi Yesterplay80 and thanks for making this great DOSBox build 😀 It has been my favorite DOSBox build since Summer 2017.
I think I've discovered a minor palette bug in one of the common used text mode. The first image show the sound setup program running on your r4004 from LucasArts Fate of Atlantis:

This is how I believe it should look like. It's also how it looks in Vanilla DOSBox v0.74.

The picture below is from the same program/game but running your newest ECE build r4072. Running the setup program in this version makes all the text background black and I'm unable too make any selection because the selection cursor is also black on black background. I can confirm that this odd behavior also occur on all vanilla SVN builds made after Jan 2017 akaik. I've also tried too change the machine too ega, vgaonly etc. and the output - surface and ddraw - which the same result

Both screenshots was made with a fresh config file made from two clean portable versions.
I would be very happy too see this minor bug fixed if it is indeed a bug. It's likely too occur in similar situations, many games from this period used this kind of setup programs.

I don't have this game so I cannot confirm the issue, however, if it happens in vanilla DOSBox as well, maybe Qbix should have a look at it. Can anyone confirm this display error?

This display error don't happens in Stable Vanilla DOSBox v0.74, only in newer DOSBox SVN builds. It also occur in the Floppy version of Day Of Tentacle. Sadly you don't have this game but that's okay.

Sounds like it can be forwarded to Qbix. Can you confirm what the last stock SVN build you used was that didn't exhibit this bug?

Already reported. It's actually a bug in some LucasArts setup programs that happens in real DOS when you load ANSI.SYS, and SVN is currently emulating ANSI.SYS more accurately. Might revert to the old behavior, but still considering because the installers fixed by the accurate behavior will become broken again.

BTW, Yesterplay80 also has a vanilla SVN build, so it's a good idea to check any issue you come across with that build before posting in the ECE build thread.