Okay, I downloaded the whole 200+MB DirectX 9 SDK and copied the little ddraw.h file into a couple of relevant include folders. After re-running configure and then recompiling, DOSBox's error message chaned to something along the lines of "couldn't create directdraw somethingorother".

I was able to fix the problem by replacing my custom-built SDL and SDL_net DLLs with the ones included in DOSBox 0.63, but why wouldn't mine work? They're built from the latest 1.2 CVS tree.

EDIT: The actual error message is "Failed to create ddraw surface, back to normal surface."

directx headers are quite small actually.
Try looking for a buildscript that is used to build libsdl.
that one includes a link to needed headers.

So you're saying that my SDL build is missing stuff because it needs some more headers from the DirectX SDK? I'm not sure what you mean by look for a buildscript (I think I just flagged myself as a newbie to advanced *nix-style coding).

Is there a place in my MinGW filesystem that I can just dump all of the DirectX SDK headers to make it work? Or maybe a flag I can set somewhere to tell the SDL configure script where to find them?

Does SDL need access to any of the libraries from the DirectX SDK as well?

I poked around on the SDL site and they said to use a package they threw together at: http://www.libsdl.org/extras/win32/common/

But those files are OLD! The purpose of building the CVS version of SDL was to have the newest stuff available. Maybe I should just skip buliding a CVS version of the SDL DLLs and stick to the ones used in DOSBox 0.63 after all.

I have a DOSBox-related question as a result of all this though: Does the win32 version of DOSBox use DirectSound? I'm assuming it uses the SDL for sound, but is it doing it in the best way that it can on win32 in terms of performance and quality of sound?

Thanks for putting up with my rambling.

those headers are fine at the sdl site.

it doesn't matter it's old.
directdraw is old you know 😀 and that's what dosbox uses.

0.63 is build with the same headers.

Well maybe I'll give it a try then. I got SDL and DOSBox to build with stronger compiler optimizations, so it would be nice to get a ddraw-capable version of both built to do some comparisons to stock 0.63.

I'll post my results if I don't get too caught up in playing old DOS games 😉

There was some discussion about this some time ago. I think SDL has hardware surfaces disabled in source by default. Perhaps Qbix can shed some light on it what needs to be changed.

That could be, but when I run the configure script, it says something about checking for DirectX headers and libraries and reports that they weren't found. It looks like it's set to enable some DirectX code if it's able to find those. I'll give it a shot anyways and report back.

EDIT: Well, I installed the DirectX files from the SDL site, but after seeing how things were laid out I decided to copy all of the header files from the DirectX 9 SDK that I downloaded (9.0c 12/10/2004 update) into my /mingw/include directory. I then renamed all of the DirectX library files from *.lib to lib*.a and copied them into /mingw/lib. I re-ran SDL's configure script, and it detected the DirectX files this time.

I also got a hold of the latest win32 version of nasm (release, not CVS) and put it in /mingw/bin. One problem with that is that the binary is now named nasmw.exe, while SDL's configure looks for nasm.exe. I got around this by creating a symbolic link to nasmw.exe called nasm.exe. Again, SDL's configure detected it this time.

It's now recompiling *fingers crossed*

Well the compile went fine, but DOSBox (both official 0.63 and my CVS build) still claims that it can't create a ddraw surface. The only thing that I can think of is that maybe those latest DirectX SDK files won't work? I guess the only option left is to try installing the DirectX dev files from libsdl.org and recompiling SDL once again.

EDIT: Nope, it still doesn't work! I'm stumped! It seems impossible to compile this CVS version of SDL into a DLL that will enable ddraw surface support in DOSBox. Anyone know what the problem could be?

EDIT #2: The official 1.2.7 stable SDL.DLL has the same problem with DOSBox. Qbix, have you somehow customized the build of SDL.DLL that you use with DOSBox? 😕

uhm yes. let's recall what those changes were 😀
I'm using some sort of cvs version of (say a week before 0.63 release)
and the following changes

1Index: src/video/windx5/SDL_dx5video.c
2===================================================================
3RCS file: /home/sdlweb/libsdl.org/cvs/SDL12/src/video/windx5/SDL_dx5video.c,v
4retrieving revision 1.27
5diff -u -r1.27 SDL_dx5video.c
6--- src/video/windx5/SDL_dx5video.c     25 Jun 2004 05:24:50 -0000      1.27
7+++ src/video/windx5/SDL_dx5video.c     12 Dec 2004 11:43:53 -0000
8@@ -1461,7 +1461,7 @@
9                        }
10                }
11                dd_surface3 = NULL;
12-#if 0 /* FIXME: enable this when SDL consistently reports lost surfaces */
13+#if 1 /* FIXME: enable this when SDL consistently reports lost surfaces */
14                if ( (flags & SDL_HWSURFACE) == SDL_HWSURFACE ) {
15                        video->flags |= SDL_HWSURFACE;
16                } else {

Interesting. I wonder what is iffy about that code that makes them not want to enable it by default.

Anyways, I made the change and recompiled and now it works! Thanks.

A small update (not that anyone cares):

I've been building CVS versions of SDL and DOSBox in MingW32 around once every week or two for the past few months, and today I started having a weird problem: DOSBox's configure script would claim that it couldn't find a usable version of SDL. I tried a lot of things, but I think I fixed it by doing both a `make clean` and `make distclean` before the usual cvs update, autogen.sh, configure, make, make install dance.

Also, instead of running ./configure directly, I pass some optimization flags to it by running this script for DOSBox:
#! /bin/sh
./configure --enable-core-inline CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"

...and this one for SDL:
#! /bin/sh
./configure --with-gnu-ld CXXFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer" CFLAGS="-march=athlon-xp -O3 -pipe -fomit-frame-pointer"

Does anyone know what parameter(s) I need to add to keep GCC from tacking on debugging information? It would save me a step to not have to run `strip` on the binaries when they're done compiling.

set LDFLAGS to "-s", that means "strip" 😀

by the way, if you care about performance, use the -fprofile-generate/-fprofile-use pair of switches. They easily speed up dosbox by 10-30%. In some cases I've had as much as 50% speedup. Usage is like this:

Build with -fprofile-generate (simply add this to your CXXFLAGS), leave the source directory as-is.
run the newly created binary, play some games, using various parts of dosbox (cpu-intensive protected mode, scalers, different sound cards, different cpu cores). 3-4 carefully selected games should do the trick, each run for a minute or two.

Go back to the source directory. Run "make clean". do a "./configure" again, this time use -fprofile-use instead of -fprofile-generate. compile as usual. enjoy a faster dosbox 😀

Ah, thanks.

Is there a file that's generated from this profiling that I'll need to put somewhere for the compiler to see? I'm running in Windows, so I move the dosbox.exe from /usr/local/bin to a place on a different hard drive where I keep my old games. I'm probably too lazy to take the time to do that, but it sounds interesting - thanks for the tip 😀

the SDL version problem...
I would assume that dosbox somehow can't find your sdl-config file.

HunterZ wrote:

Is there a file that's generated from this profiling that I'll need to put somewhere for the compiler to see?

The profiling build (the one with -fprofile-generate) puts data files into the directories of the source code, that's why you must keep the sources extracted. After the second, optimized build, you can safely delete everything, dosbox.exe is all you need, just like usual.
You can't usually reuse the profiling data across builds since even small code changes or different CXXFLAGS can make it invalid. gcc will tell you if that's the case. If you get gcc errors on some files after updating from CVS, start with a fresh source directory.

P.S.: use gcc-3.4 or above. gcc-3.3 had different flags for profile guided optimization.

Qbix: nah, it was in my path and I even adding some debugging output to sdl-config (echo to standard error) and saw that it was being run. Something just got stupid somewhere, but at least I was able to kick it in the head and make it work again.

Moe: I doubt DOSBox will be able to find its source directory to put stuff in when I run it from my other location, since I compile from inside of an MSYS enviroment on Win32 (if that means anything to you). I should probably experiment though, just to learn how it works...

It should work, especially for MSYS. They don't do that fancy path translating like cygwin does. Though I faintly recall there was a way to get unix-path behaviour for an app if you want it. Anyways, try it, I guess it simply works.

And then send me a quick guide for compiling CVS with MSYS so I can start debugging those Windows OpenGL-HQ problems 😀 Up to now, I've hesitated tackling that task...

Dunno...I just copied sdl.dll to where dosbox.exe was created and ran dosbox from there, then did make clean and recompile with fprofile-use. But in my case the speed increase was minimal...perhaps you'll have better luck 😀

@`Moe`: mingw is nothing fancy 😁. There's even some instructions in the dosbox wiki...
"You'll need to download both the latest MiniGW and MSYS. After downloading install MiniGW and MSYS (in this order). The MSYS-Installer should ask for the installation directory of MiniGW, so you should pick the path where you installed it. After the installation, run the MSYS.BAT and you should see a unix-like command prompt.". From there you should feel like home 😁.

Here's a proper link to the page on the Wiki that gulikoza is talking about: http://dosbox.sourceforge.net/wiki/index.php? … =BuildingDOSBox

I usually get the CVS code straight from Sourceforce, which is not too hard since MSYS comes with a port of the cvs client.