I'll fix that crashing by times, but it only hides that something else is
wrong as the video can't be initialized with =directx.

But what? I also launched dxdiag, and verified that hardware accelleration was on (card is NVIDIA GeForce Go 7800 with somewhat recent drivers: 78.59). Also tried with hw-accelleration off. No change.

SDL needs some modifications to support ddraw

Re: CVS compile question(s)

Ran all the SDL-test programs with SDL_VIDEOMODE=directx. No failures in the test-programs, but dosbox crashes.

gulikoza wrote:

SDL needs some modifications to support ddraw

Re: CVS compile question(s)

I recompled 1.2.11 with

1--- SDL_dx5video.c.ORIG Tue Jun 27 05:48:31 2006
2+++ SDL_dx5video.c      Fri Mar  9 21:15:04 2007
3@@ -1489,7 +1489,7 @@
4                        }
5                }
6                dd_surface3 = NULL;
7-#if 0 /* FIXME: enable this when SDL consistently reports lost surfaces */
8+#if 1 /* FIXME: enable this when SDL consistently reports lost surfaces */
9                if ( (flags & SDL_HWSURFACE) == SDL_HWSURFACE ) {
10                        video->flags |= SDL_HWSURFACE;
11                } else {

but it made no difference.

But what?

Erm i didn't say it's caused by the hardware acceleration setting. I don't
know why it does that (i would have guessed that the change gulikoza
posted would help, but well) and didn't really bother yet. Qbix's compile
works fine.

MiniMax wrote:

Ran all the SDL-test programs with SDL_VIDEOMODE=directx. No failures in the test-programs, but dosbox crashes.

UPS!!! That was totally wrong. Noticed that it is not SDL_VIDEOMODE, it is SDL_VIDEODRIVER!

Re-did the test with SDL_VIDEODRIVER=directx, and SDL_VIDEODRIVER=ddraw, and now the test-programs that creates windows fails. They don't even show the SDL-window - they just silently dies.

Edit: A stderr.txt file is left saying "Couldn't initialize SDL: No available video device".

SDL_VIDEODRIVER=ddraw does not exist, that's why sdl crashes. directx and windib are the only available options. Why don't you compile in debug mode and check where it crashes? 😀

I will - I am on a steep learning curve here. I have identified 2 points in sdlmain.cpp where SDL_InitSubSystem is being called. I am recompiling now. Will try with ./configure --enable-debug next.

here are my changes

patch -p1 < sdl11rel.diff

gulikoza wrote:

SDL_VIDEODRIVER=ddraw does not exist, that's why sdl crashes. directx and windib are the only available options. Why don't you compile in debug mode and check where it crashes? 😀

It dies (as expected) in sdlmain.cpp:main(), around line 1379:

1#if defined (WIN32) 
2#if SDL_VERSION_ATLEAST(1, 2, 10)
3    sdl.using_windib=true;
4#else
5    sdl.using_windib=false;
6#endif
7    char sdl_drv_name[128];
8    if (getenv("SDL_VIDEODRIVER")==NULL) {
9        if (SDL_VideoDriverName(sdl_drv_name,128)!=NULL) {
10            if (strcmp(sdl_drv_name,"directx")!=0) {
11                SDL_QuitSubSystem(SDL_INIT_VIDEO);
12                putenv("SDL_VIDEODRIVER=directx");
13/* JBA2 */      if( SDL_InitSubSystem(SDL_INIT_VIDEO) < 0 )
14                    E_Exit("JBA2: Could not initialize SDL: %s",SDL_GetError());
15            }       
16            sdl.using_windib=false;
17        }       
18    } else {
19        char* sdl_videodrv = getenv("SDL_VIDEODRIVER");
20        if (strcmp(sdl_videodrv,"directx")==0) sdl.using_windib = false;
21        else if (strcmp(sdl_videodrv,"windib")==0) sdl.using_windib = true; 
22    }       
23    if (SDL_VideoDriverName(sdl_drv_name,128)!=NULL) {
24        if (strcmp(sdl_drv_name,"windib")==0) LOG_MSG("SDL_Init: Starting up with SDL windib video driver.\n          Try to update
25 your video card and directx drivers!");
26    }       
27#endif

with the message:

Exit to error: JBA2: Could not initialize SDL: No available video device

Added a little debugging output to SDL_video.c:SDL_VideoInit():

1for ( i=0; bootstrap[i]; ++i ) {
2    fprintf( stderr, "JBA3: Checking for driver '%s' against bs[%i]('%s')\n", driver_name, i, bootstrap[i]->name );
3
4    if ( SDL_strncmp(bootstrap[i]->name, driver_name,
5            SDL_strlen(bootstrap[i]->name)) == 0 ) {
6        if ( bootstrap[i]->available() ) {
7            video = bootstrap[i]->create(index);
8            break;
9        }
10    }
11}
12} else {
13    for ( i=0; bootstrap[i]; ++i ) {
14        if ( bootstrap[i]->available() ) {
15            fprintf( stderr, "JBA4: No driver name. First available driver bs[%i]('%s')\n", i, bootstrap[i]->name );
16
17            video = bootstrap[i]->create(index);
18            if ( video != NULL ) {
19                break;
20            }
21        }
22    }
23}

If I explicitly select SDL_VIDEODRIVER=windib, SDL_video.c:SDL_VideoInit succesfully finds the driver in the bootstrap-list:

1JBA3: Checking for driver 'windib' against bs[0]('windib')
2SDL_Init: Starting up with SDL windib video driver.
3          Try to update your video card and directx drivers!
4CONFIG: Using default settings. Create a configfile to change them
5MIDI:Opened device:win32

Selecting directx fails, because the bootstrap[] does not contain a driver with that name:

1JBA3: Checking for driver 'directx' against bs[0]('windib')
2JBA3: Checking for driver 'directx' against bs[1]('dummy')
3Exit to error: Can't init SDL No available video device

Without an SDL_VIDEODRIVER specified, I see something strange:

1JBA4: No driver name. First available driver bs[0]('windib')
2JBA3: Checking for driver 'directx' against bs[0]('windib')
3JBA3: Checking for driver 'directx' against bs[1]('dummy')
4Exit to error: JBA2: Could not initialize SDL No available video device

I assume that it is some logic in DOSBox that first calls SDL_VideoInit without a named driver, then checks the returned name (windib), and decides to force directx - which fails.

So the question is: Why is there no directx in my bootstrap[] list?

/me digs deeper into SDL...

You need directx headers for directx to be compiled. Check the configure...you should see some lines - checking for ddraw.h...

Aha! Thanks gulikoza: Looks like configure don't find ddraw.h:

1$ grep ddraw config.log 
2configure:20: checking ddraw.h usability
3conftest.c:124:19: ddraw.h: No such file or directory
4| #include <ddraw.h>
5configure:65: checking ddraw.h presence
6conftest.c:90:19: ddraw.h: No such file or directory
7| #include <ddraw.h>
8configure:136: checking for ddraw.h
9ac_cv_header_ddraw_h=no

Edit: Looks like this article contains the basics for getting the MS DirectX stuff into my MinGW setup. Guess I need to download, extract, and re-confgure SDL with the headers and libs in pkace.

Found the latest SDK here:
http://msdn.microsoft.com/library/default.asp … tentid=28000410

It will take quite some time for that to download, so this will be the end of tonights debugging session. It has been interesting 😀

Qbix wrote:

here are my changes

patch -p1 < sdl11rel.diff

I look at those diffs, and here is my interpretation:

SDL_video.c: Switch the order of the WINDIB and DDRAW drivers in the bootstrap-list, so DDRAW comes before WINDIB. But why? What do this accomplish? DDRAW is faster/better/more compatible across Windows platforms?

SDL_dx5events.c: A change to let DOSBox handle all keyinput? It is an ugly way to do it by removing a break, and let the code fall-through to the return(0) . I would have kept with the structure of the original code and added a separate return(0) for WM_SYSKEYUP/DOWN (and - for style - I would have inserted break's after each return(0)'s.

SDL_dx5video.c: I can read the comments as well as anyone else. Is this a particular problem with DOSBox on some platforms, or is it just to prevent problems, should they happen?

I can read the comments as well as anyone else.

Nice, thanks for telling.

DDRAW is faster/better/more compatible across Windows platforms?

The windib driver has some bugs (fullscreen, keyboard) on many pcs.

A change to let DOSBox handle all keyinput?

No, reverting a change.

It is an ugly way to do it by removing a break

No it's not. If you don't like it don't do it.

wd wrote:

A change to let DOSBox handle all keyinput?

No, reverting a change.

So with an unmodified SDL, the SDL-application would get control of the PrtScr/SysRq key on the keyboard? And with DOSBox, that is not desired? If so, why not keep SDL unchanged, accept the event in DOSBox, and pass it back to the window manager?

why not keep SDL unchanged, accept the event in DOSBox

Because you don't get it then. Leave it out and hit ALT.

Okay - I think I understand the WM_SYSKEY issue now. The standard SDL-1.2.11 correctly passes these SYSKEY-events (e.g. ALT-key, F10, ..) to the Windows window-manager(?) so ordinary SDL/Windows applications will behave like they they always do and focus on the window-menu (with File, Edit, Help, ...) or close the window when ALT-F4 is pressed.

But DOSBox do not want this to happen. It wants full control of ALT, Right-CTRL and similar system-keys. By doing a return(0) SDL is told that there is no special handler for this event, and the application (DOSBos) gets to handle the ALT-key.

This means, that to build and run DOSBox, I need

1. a modified version of SDL (which explains the path-names listed in Qbix's diffs (SDL-1.2.11rel and SDL-1.2.11 - one for the official release, and one for an DOSBox-adapted version)
2. to make sure that I don't accidential install the modified SDL.dll in my ordinary build envinronment, e.g. /mingw/bin.

MiniMax wrote:

SDL_dx5video.c: I can read the comments as well as anyone else. Is this a particular problem with DOSBox on some platforms, or is it just to prevent problems, should they happen?

It was this diff:

1-#if 0 /* FIXME: enable this when SDL consistently reports lost surfaces */
2+#if 1 /* FIXME: enable this when SDL consistently reports lost surfaces */
3 		if ( (flags & SDL_HWSURFACE) == SDL_HWSURFACE ) {
4 			video->flags |= SDL_HWSURFACE;
5 		} else {

Why is this recommended when building SDL for DOSBox?