lukeman3000 wrote:

Out of curiosity, why make Win32 the default setting instead of "default" aka the default system midi playback device? Is Win32 normally the default setting for this parameter?

Exactly, in vanilla DOSBox Win32 is the only and therefor the default midi device under Windows OSes. So whether you set the corresponding option to "default" or "win32" doesn't matter, as it is the same.

lukeman3000 wrote:

Furthermore, what defines the default midi playback device if this parameter is set to default instead of win32?

The order in which the different devices are listed in the source code:

1/* Include different midi drivers, lowest ones get checked first for default */
2#ifdef C_FLUIDSYNTH
3#include "midi_fluidsynth.h"
4#endif
5#include "midi_mt32.h"
6static MidiHandler_mt32 &Midi_mt32 = MidiHandler_mt32::GetInstance()
7#if defined(MACOSX)
8#include "midi_coremidi.h"
9#include "midi_coreaudio.h"
10#elif defined (WIN32)
11#include "midi_win32.h"
12#else
13#include "midi_oss.h"
14#endif
15#if defined (HAVE_ALSA)
16#include "midi_alsa.h"
17#endif

lukeman3000 wrote:

This may be a little off-topic, but should mididevice always be set to win32 (if using Windows) regardless of if I'm using Sound Canvas VA or Munt, unless I want to use the built-in MT-32 emulation of ECE, in which case I choose "mt32"?

Yes, absolutely, if you want to use any external midi synthesizer that you installed in Windows, you have to choose "win32" as midi device in DOSBox and select the one you want to use with "midiconfig=x", where x is the name, part of the name or the number shown when calling "mixer /listmidi".

Thanks, though I'm still a bit confused -- when the default midi playback device is set to "default" - will it automacitlly choose win32 if you're running on Windows, period? How does "default" know what playback device is actually default? Sorry for being dense.

lukeman3000 wrote:

Thanks, though I'm still a bit confused -- when the default midi playback device is set to "default" - will it automacitlly choose win32 if you're running on Windows, period?

Yes.

lukeman3000 wrote:

How does "default" know what playback device is actually default?

Look at the code I posted again, especially the comment in the first line, that explains it: During compilation of the source code and building the binaries, the last device in the list is automatically set as default device for its OS. Since "win32" is the last one for Windows, it becomes default.

Thanks for the detailed explanation - makes sense.

So in actuality, the only two options I'll probably ever switch between are win32 (for any external synthesizer), and mt-32 (for built-in Munt emulation).

Assuming that I'm using Windows and also assuming I don't particularly care to use fluidsynth (since I have SCVA).

@YP80,
How did you "make" libpng-1.6.18? It has an error when making, no matter what I tried.
It complains about VERSION something.
I follow the building guide exactly.

James-F wrote:

@YP80, How did you "make" libpng-1.6.18? It has an error when making, no matter what I tried. It complains about VERSION someth […]
Show full quote

@YP80,
How did you "make" libpng-1.6.18? It has an error when making, no matter what I tried.
It complains about VERSION something.
I follow the building guide exactly.

To be honest, I don't remember any errors when compiling libpng 1.6.18. Which version of zlib do you have installed? I always keep that and libpng up to date (currently libpng is version 1.6.29 and zlib is 1.2.11)

Same error with the new libs, can't 'make' libpng.
What's going on here?

1TESTER@Desky-i7 ~/libpng-1.6.29
2$ make
3rm -f pnglibconf.c pnglibconf.tf[45]
4gawk -f ./scripts/options.awk out=pnglibconf.tf4 version=search\
5            ./pngconf.h ./scripts/pnglibconf.dfa\
6            ./pngusr.dfa  1>&2
7gawk -f ./scripts/options.awk out=pnglibconf.tf5 pnglibconf.tf4 1>&2
8rm pnglibconf.tf4
9mv pnglibconf.tf5 pnglibconf.c
10rm -f pnglibconf.out pnglibconf.tf[12]
11test -d scripts || mkdir scripts || test -d scripts
12gcc -E -DHAVE_CONFIG_H -I. \
13             -DPNGLIB_LIBNAME='PNG16_0' -DPNGLIB_VERSION='1.6.29' -DSYMBOL_PREFI
14X='' -DPNG_NO_USE_READ_MACROS -DPNG_BUILDING_SYMBOL_TABLE  pnglibconf.c > pnglib
15conf.tf1
16gawk -f "./scripts/dfn.awk" out="pnglibconf.tf2" pnglibconf.tf1 1>&2
17rm -f pnglibconf.tf1
18mv pnglibconf.tf2 pnglibconf.out
19rm -f pnglibconf.h
20cp pnglibconf.out pnglibconf.h
21make  all-am
22make[1]: Entering directory `/home/TESTER/libpng-1.6.29'
23:>pngprefix.h
24depbase=`echo png.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
25        /bin/sh ./libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
26 -g -O2 -MT png.lo -MD -MP -MF $depbase.Tpo -c -o png.lo png.c &&\
27        mv -f $depbase.Tpo $depbase.Plo
28libtool: compile:  gcc -DHAVE_CONFIG_H -I. -g -O2 -MT png.lo -MD -MP -MF .deps/p
29ng.Tpo -c png.c -o png.o
30In file included from pngpriv.h:70:0,
31                 from png.c:14:
32pnglibconf.h:202:54: error: expected identifier or '(' before '-' token
33                                                 0
34                                                      ^
35In file included from png.h:366:0,
36                 from pngpriv.h:375,
37                 from png.c:14:
38pngconf.h:522:9: error: unknown type name 'ptrdiff_t'
39 typedef ptrdiff_t png_ptrdiff_t;
40         ^
41In file included from png.c:14:0:
42pngpriv.h:897:21: error: operator '!=' has no left operand
43 #if PNG_ZLIB_VERNUM != 0 && PNG_ZLIB_VERNUM != ZLIB_VERNUM
44                     ^
45make[1]: *** [png.lo] Error 1
46make[1]: Leaving directory `/home/TESTER/libpng-1.6.29'
47make: *** [all] Error 2

@James-F, you too have been bitten by the infamous pnglibconf.h bug.

Just edit the pnglibconf.h file in the libpng folder and remove the extra tabs/new lines between certain define parameters and its values. Then run make as usual. Please don't ask why.

Thanks.
There is no pnglibconf.h in libpng-1.6.29, but there is "pnglibconf.h.prebuilt" in libpng-1.6.29\Scripts.
Also, "extra tabs/new lines between certain define parameters and its values" is unclear to me at all. 😀

James-F wrote:

Thanks.
There is no pnglibconf.h in libpng-1.6.29, but there is "pnglibconf.h.prebuilt" in libpng-1.6.29\Scripts.

Sorry, there was a mistake in my previous post as it was sometime back, when the bug bit me.

Assuming that you are following 'Building DOSBox with MinGW' wiki, please follow the sequence below:
a) From within libpng-1.6.29 directory, you should have already executed the command " ./configure --disable-shared --prefix=/mingw "
b) Now run 'make' and you will get the usual error.
c) Then check the libpng-1.6.29 directory and you will find the elusive pnglibconf.h file.

James-F wrote:

Also, "extra tabs/new lines between certain define parameters and its values" is unclear to me at all. 😀

Once you open the pnglibconf.h, you will see lots of #defines. Some of these #define statements (around 5 or so in my case) will look odd at first glance(mainly towards the end of the file). Normally there will be just a single space between a define parameter and its value. The few abnormal ones will have a huge gap between the #define parameter and its value.
For e.g.,

Normal case:
#define PNG_ZBUF_SIZE 8192

Abnormal case:
#define PNG_ZLIB_VERNUM
0x1280)
Delete the extra tabs/spaces in all the abnormal cases and you should be good to go. Again run 'make' and if there are no errors, execute 'make install'. If you are still getting errors, please upload your config log and make output log.

Perhaps there might be a better way to correct the error at the source itself(generating proper pnglibconf.h) without the need of a manual edit, but, Ignorance is bliss in my case, in this case.

I made myself a patch fixing this bug in libpng: Re: Dosbox SVN r4007 + savestates Build
It's a shame it still isn't fixed after all those months.

Thanks gandhig and YP80!
Fixed the libpng bug and patched for savestates.
Savestates is a nice addition for games that don't have cheats.

You are welcome, James-F. Glad to be of help to a regular contributor in this forum.

Yesterplay80 wrote:

willow wrote:

Since dosbox daum is dead, I would like to know if Dosbox ECE own glide patch or not?

Actually, it has kekko's 3Dfx patch integrated, which wraps all Glide calls to OpenGL ones, so you don't even need an external wrapper: VIDEO - 3dfx voodoo emulation (SDL1)

UPDATE: Linux binaries (still shared, though) are online as well!

I was wondering how you get Glide to work in DOSBox ECE. I am trying to get Redguard to work, but it gives me the error "Fatal error: unable to load DLL." I am able to get it to work in ykhwong's build. Am I missing some files? I tried moving the glide dlls to the DOSBox directory, but that didn't work. Any help would be appreciated.

Speaking of Redguard, which is the latest and greatest Glide patch, and does it apply cleanly to upstream? I'm getting annoyed with how 'glide emulation' was rumored to be in its way upstream about 3 years ago and zilch on the svn during all that time. Might as well put it in my little automated build if its stable because god knows, i'd be waiting another 5 years.

I don't know which is the latest and greatest, afaik they're all some years old, I use kekkos patch because it doesn't require an external wrapper and applies to the vanilla SVN cleanly.

About Redguard: I don't have that game and can't try it out myself. But aren't DLLs a Windows only thing?

Yesterplay80, there seems to be a problem with the latest version of my patch on OSX. Can you please confirm that your build includes the latest version (alpha 12)? I am trying to determine whether the problem is somehow related to the OS.

Yesterplay80 wrote:

About Redguard: I don't have that game and can't try it out myself. But aren't DLLs a Windows only thing?

I was thinking that the game needed the glide dlls in order to work like they do in ykhwong's build. I just placed them in the DOSBox or Redguard directory. Otherwise, I'm not sure how glide is supposed to work in DOSBox ECE. I have output=opengl and voodoo=auto. Is there anything else that I am missing to enable glide?

Ant_222 wrote:

Yesterplay80, there seems to be a problem with the latest version of my patch on OSX. Can you please confirm that your build includes the latest version (alpha 12)? I am trying to determine whether the problem is somehow related to the OS.

I just redownloaded your patch and compared the "time stamps" with the patch file I use: They're all identical, so it must be the latest alpha 12 I use.

bsmith1702 wrote:

[I was thinking that the game needed the glide dlls in order to work like they do in ykhwong's build. I just placed them in the DOSBox or Redguard directory. Otherwise, I'm not sure how glide is supposed to work in DOSBox ECE. I have output=opengl and voodoo=auto. Is there anything else that I am missing to enable glide?

All the games I tried out so far worked without any DLLs, since all the wrapping is done internally in DOSBox. Did you try to start the game without any additional DLLs? BTW.: According to the reviews on GOG, where they sell the 3Dfx-accelerated version, the game runs so slow with 3Dfx that it's almost unplayable.

Hi,

I'm currently using DOSBox 0.74 on my Windows ME retro setup. Newest version of Dosbox ECE (or the vanilla SVN) does not run due to the SDL.DLL is expecting what I guess is minimum of NT5.1 environment due to when it's compiled it's not really targeting win9x anymore.

Anyhow, if I use the DOSBox ECE (or vanilla SVN) and replace the newer SDL.DLL with the older 0.74 SDL.DLL it works fine, no error messages. So far so good, and as far as I can see, pixel-perfect, MT32 emulator works fine which is the important thing for me but what am I missing out on when using an older SDL.DLL with DOSBox ECE (or current DOSbox SVN)?

Thanks!

EDIT: Main question: Is the magic stuff mainly happening in the .exe or in the SDL.DLL?
EDIT: This is with KernelEx installed. Please see later posts for relevance.