DOSBox ECE (for Windows)

Developer's Forum, for discussion of bugs, code, and other developmental aspects of DOSBox.

Re: DOSBox ECE (for Windows)

Postby emendelson » 2018-1-30 @ 17:07

OK, building Munt with Cmake in VS 2017, I got as far as this:
Code: Select all
Could NOT find libsoxr
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Could NOT find libsamplerate
Configuring 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
Oldbie
 
Posts: 744
Joined: 2010-2-14 @ 02:00

Re: DOSBox ECE (for Windows)

Postby Yesterplay80 » 2018-1-30 @ 18:37

emendelson wrote:OK, building Munt with Cmake in VS 2017, I got as far as this:
Code: Select all
Could NOT find libsoxr
Could NOT find PkgConfig (missing: PKG_CONFIG_EXECUTABLE)
Could 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. :)
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 317
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (for Windows)

Postby emendelson » 2018-1-30 @ 23:11

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:

Code: Select all
c:\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/Forum ... =vcgeneral
Attachments
Capture.PNG
Last edited by emendelson on 2018-1-31 @ 03:21, edited 1 time in total.
emendelson
Oldbie
 
Posts: 744
Joined: 2010-2-14 @ 02:00

Re: DOSBox ECE (for Windows)

Postby emendelson » 2018-1-31 @ 01:16

EDIT: Obsolete content removed.
Last edited by emendelson on 2018-1-31 @ 21:22, edited 2 times in total.
emendelson
Oldbie
 
Posts: 744
Joined: 2010-2-14 @ 02:00

Re: DOSBox ECE (for Windows)

Postby emendelson » 2018-1-31 @ 21:22

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:
Code: Select all
1>..\src\hardware\opl.cpp(484): error C3861: 'memset': identifier not found
    1>..\src\hardware\opl.cpp(485): error C3861: 'memset': identifier not found
    1>..\src\hardware\opl.cpp(486): error C3861: 'memset': identifier not found
    1>..\src\hardware\opl.cpp(972): error C3861: 'memset': identifier not found

by adding this to opl.cpp:
Code: Select all
#include <cstring>


Next, not knowing what I was doing, but just throwing code into the editor until something worked, I worked around this error:
Code: Select all
c:\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):

Code: Select all
char ssStartUpdate( Bit8u **pixels, Bitu *pitch )
    {
       sdl.SurfaceInfo.StartUpdate(pixels, pitch);  return ssStartUpdate(pixels, pitch);
    }


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:
Code: Select all
CONFIG:Loading primary settings from config file C:\Users\Edward\AppData\Local\DOSBox\dosbox-SVN.conf
MIDI: Opened device:win32
PC speaker output buffer length: 145
mixer callback wants too many samples from pc speaker emulator: 1103
mixer callback wants too many samples from pc speaker emulator: 957
mixer callback wants too many samples from pc speaker emulator: 812
mixer callback wants too many samples from pc speaker emulator: 667
mixer callback wants too many samples from pc speaker emulator: 522
mixer callback wants too many samples from pc speaker emulator: 377
mixer callback wants too many samples from pc speaker emulator: 232
Available area: 1904x1038
Color data offset: 0
Scaling: 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...
emendelson
Oldbie
 
Posts: 744
Joined: 2010-2-14 @ 02:00

Re: DOSBox ECE (for Windows)

Postby emendelson » 2018-2-01 @ 03:28

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
Oldbie
 
Posts: 744
Joined: 2010-2-14 @ 02:00

Re: DOSBox ECE (for Windows)

Postby Yesterplay80 » 2018-2-01 @ 13:44

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. :wink:

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:

Code: Select all
checking for new_fluid_synth in -lfluidsynth... yes
checking fluidsynth.h usability... yes
checking fluidsynth.h presence... yes
checking for fluidsynth.h... yes
checking 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:

Code: Select all
./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.
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 317
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (for Windows)

Postby emendelson » 2018-2-01 @ 13:51

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. :wink:


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!
emendelson
Oldbie
 
Posts: 744
Joined: 2010-2-14 @ 02:00

Re: DOSBox ECE (for Windows)

Postby DosFreak » 2018-2-01 @ 14:21

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
viewtopic.php?f=31&t=55706&p=636941&hilit=compilation#p636941
User avatar
DosFreak
l33t++
 
Posts: 9756
Joined: 2002-6-30 @ 16:35
Location: Your Head

Re: DOSBox ECE (for Windows)

Postby zirkoni » 2018-2-01 @ 14:40

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?
Code: Select all
char ssStartUpdate( Bit8u **pixels, Bitu *pitch )
    {
       sdl.SurfaceInfo.StartUpdate(pixels, pitch);  return ssStartUpdate(pixels, pitch);
    }


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:
Code: Select all
char ssStartUpdate( Bit8u **pixels, Bitu *pitch )
{   return sdl.SurfaceInfo.StartUpdate( pixels, pitch );  }
User avatar
zirkoni
Member
 
Posts: 161
Joined: 2014-7-17 @ 08:54

Re: DOSBox ECE (for Windows)

Postby emendelson » 2018-2-01 @ 14:51

zirkoni wrote:Try this instead:
Code: Select all
char ssStartUpdate( Bit8u **pixels, Bitu *pitch )
{   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!
emendelson
Oldbie
 
Posts: 744
Joined: 2010-2-14 @ 02:00

Re: DOSBox ECE (for Windows)

Postby emendelson » 2018-2-01 @ 21:24

Yesterplay80 wrote: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:

Code: Select all
checking for new_fluid_synth in -lfluidsynth... yes
checking fluidsynth.h usability... yes
checking fluidsynth.h presence... yes
checking for fluidsynth.h... yes
checking 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:

Code: Select all
./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!
emendelson
Oldbie
 
Posts: 744
Joined: 2010-2-14 @ 02:00

Re: DOSBox ECE (for Windows)

Postby marzsyndrome » 2018-2-01 @ 22:57

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.
marzsyndrome
Newbie
 
Posts: 54
Joined: 2007-3-28 @ 14:33

Re: DOSBox ECE (for Windows)

Postby Yesterplay80 » 2018-2-02 @ 09:31

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?
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 317
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (for Windows)

Postby emendelson » 2018-2-02 @ 12:02

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...!
emendelson
Oldbie
 
Posts: 744
Joined: 2010-2-14 @ 02:00

Re: DOSBox ECE (for Windows)

Postby Morten79 » 2018-2-04 @ 02:06

Hi Yesterplay80 and thanks for making this great DOSBox build :happy: 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:

Fate_setup_ECE_r4004.png
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

Fate_setup_ECE_r4072.png

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.
Morten79
Newbie
 
Posts: 2
Joined: 2017-8-12 @ 15:10

Re: DOSBox ECE (for Windows)

Postby Yesterplay80 » 2018-2-05 @ 16:46

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?
My full-featured DOSBox SVN builds (without debugger) for Windows: Vanilla DOSBox and DOSBox ECE (Enhanced Community Edition)
User avatar
Yesterplay80
Member
 
Posts: 317
Joined: 2016-2-23 @ 11:02
Location: Germany

Re: DOSBox ECE (for Windows)

Postby Morten79 » 2018-2-05 @ 18:23

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.
Morten79
Newbie
 
Posts: 2
Joined: 2017-8-12 @ 15:10

Re: DOSBox ECE (for Windows)

Postby gdjacobs » 2018-2-05 @ 19:46

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?
User avatar
gdjacobs
l33t++
 
Posts: 5330
Joined: 2015-11-03 @ 05:51
Location: The Great White North

Re: DOSBox ECE (for Windows)

Postby ripsaw8080 » 2018-2-05 @ 21:33

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.
User avatar
ripsaw8080
DOSBox Author
 
Posts: 4198
Joined: 2006-4-25 @ 23:24

PreviousNext

Return to DOSBox Development

Who is online

Users browsing this forum: No registered users and 2 guests