WinDIB

Neil_Griffiths · August 7, 2001, 12:02pm

Hi,

Something that I can’t find documented is finding a way to force SDL to use
the standard DIB/GDI routines and not DirectX?

I’ve found on the web about “set SDL_VIDEODRIVER=windib” - does this still
work? I haven’t tried it yet in case there’s an easier way of doing it. I’d
rather not have more environment settings than I need to!

Neil.

icculus · August 7, 2001, 12:08pm

I’ve found on the web about “set SDL_VIDEODRIVER=windib” - does this still
work? I haven’t tried it yet in case there’s an easier way of doing it. I’d
rather not have more environment settings than I need to!

That’s how it’s done. Programatically:

putenv(“SDL_VIDEODRIVER=windib”);
SDL_Init(SDL_INIT_VIDEO);

Hhm…maybe we should think about a way to enumerate these drivers at
runtime for SDL 1.3.

–ryan.

slouken · August 7, 2001, 2:58pm

That’s how it’s done. Programatically:

putenv(“SDL_VIDEODRIVER=windib”);
SDL_Init(SDL_INIT_VIDEO);

Hhm…maybe we should think about a way to enumerate these drivers at
runtime for SDL 1.3.

Absolutely.

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Kylotan · August 7, 2001, 10:02pm

That’s how it’s done. Programatically:

putenv(“SDL_VIDEODRIVER=windib”);
SDL_Init(SDL_INIT_VIDEO);

I tried this and it still tells me I am using the “directx” driver. The
putenv call doesn’t return a failure value. Is Windib only supported
under NT? (I use Win98 SE).From: icculus@icculus.org (icculus)
Sent: Tuesday, August 07, 2001 8:20 PM

–
Ben Sizer

David_Olofson · August 8, 2001, 3:55am

That’s how it’s done. Programatically:

putenv(“SDL_VIDEODRIVER=windib”);
SDL_Init(SDL_INIT_VIDEO);

I tried this and it still tells me I am using the “directx” driver. The
putenv call doesn’t return a failure value. Is Windib only supported
under NT? (I use Win98 SE).

Make sure that the windib target is compiled into your SDL library (can
it be disabled…?), and check for typos in the putenv() argument. Hmm…
Any other ideas?

//David Olofson — Programmer, Reologica Instruments AB

.- M A I A -------------------------------------------------.
| Multimedia Application Integration Architecture |
| A Free/Open Source Plugin API for Professional Multimedia |
----------------------> http://www.linuxaudiodev.com/maia -' .- David Olofson -------------------------------------------. | Audio Hacker - Open Source Advocate - Singer - Songwriter |--------------------------------------> david at linuxdj.com -'On Wednesday 08 August 2001 06:57, Kylotan wrote:

From: Ryan C. Gordon
Sent: Tuesday, August 07, 2001 8:20 PM

icculus · August 8, 2001, 5:04am

I tried this and it still tells me I am using the “directx” driver. The
putenv call doesn’t return a failure value. Is Windib only supported
under NT? (I use Win98 SE).

I’ve used it under Win98. windib should always be available (it’s a
fallback for systems without directx, honestly).

If you can post the code, we can take a look. That should be our new
mantra around here.

–ryan.

Kylotan · August 8, 2001, 5:34am

I’ve used it under Win98. windib should always be available (it’s a
fallback for systems without directx, honestly).

If you can post the code, we can take a look. That should be our new
mantra around here.

int res = _putenv(“SDL_VIDEODRIVER=windib”);
if (res == -1)
{
fprintf(stderr, “Could not set environment variable.”);
exit(-1);
}

if ((SDL_Init(flags) == -1))
{
fprintf(stderr, “Could not initialize SDL: %s.\n”, SDL_GetError());
exit(-1);
}

… later in the code…

char buffer[255];
SDL_VideoDriverName(buffer, 255);
printf(“Driver: %s\n”, buffer); // writes “directx” to stdout.txt–
Ben Sizer

icculus · August 8, 2001, 5:58am

int res = _putenv(“SDL_VIDEODRIVER=windib”);

(What’s with the underscore?)

Try:

set SDL_VIDEODRIVER=windib
on the commandline before running the program. If that doesn’t work, we’ll
have to see if there’s some reason your SDL library doesn’t have windib
support.

–ryan.

Kylotan · August 8, 2001, 6:21am

int res = _putenv(“SDL_VIDEODRIVER=windib”);

(What’s with the underscore?)

_putenv isn’t an ANSI function, apparently, and the underscore indicates
that it is platform dependent.

Try:

set SDL_VIDEODRIVER=windib

That works. So, obviously I have windib support, but setting the
environment variable doesn’t. (Even though I check for the return code
and it is fine. MSDN says “_putenv and _wputenv return 0 if successful,
or -1 in the case of an error.”)–
Kylotan

Neil_Griffiths · August 8, 2001, 7:16am

Hi,

set SDL_VIDEODRIVER=windib

That works. So, obviously I have windib support, but setting the
environment variable doesn’t. (Even though I check for the return code
and it is fine. MSDN says “_putenv and _wputenv return 0 if successful,
or -1 in the case of an error.”)

Let me guess. You’ve made a mistake. You’ve already called SDL_Init() before
using _putenv(), aren’t you?

Neil.

Kylotan · August 8, 2001, 7:36am

Let me guess. You’ve made a mistake. You’ve already called SDL_Init()
before
using _putenv(), aren’t you?

No. See my post before the one you replied to.–
Ben Sizer

Adam_Gates · August 8, 2001, 4:21pm

Have you tried ‘SetEnvironmentVariable’?

Kylotan wrote:>

int res = _putenv(“SDL_VIDEODRIVER=windib”);

(What’s with the underscore?)

_putenv isn’t an ANSI function, apparently, and the underscore indicates
that it is platform dependent.

Try:

set SDL_VIDEODRIVER=windib

That works. So, obviously I have windib support, but setting the
environment variable doesn’t. (Even though I check for the return code
and it is fine. MSDN says “_putenv and _wputenv return 0 if successful,
or -1 in the case of an error.”)

–
Kylotan

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

David_MacCormack · August 8, 2001, 7:56pm

I realize that Kylotan said that using windib doesn’t solve his problem,
but others may try to use it as well so I believe this is still
relevant.

The problem is that both SDL and your app have a copy of the
environemnt; so putenv changes your app’s environment, but SDL (the DLL)
won’t see it. You need to tell SDL and your app to link to msvcrt.lib (or
msvcrtd.lib in the “Debug” release settings), recompile, and it should
work fine.

I found this out while patching the SDL_WINDOWID hack under win32 ;).

Dave----------------
David MacCormack
@David_MacCormack

On Wed, 8 Aug 2001, Kylotan wrote:

int res = _putenv(“SDL_VIDEODRIVER=windib”);

(What’s with the underscore?)

_putenv isn’t an ANSI function, apparently, and the underscore indicates
that it is platform dependent.

Try:

set SDL_VIDEODRIVER=windib

That works. So, obviously I have windib support, but setting the
environment variable doesn’t. (Even though I check for the return code
and it is fine. MSDN says “_putenv and _wputenv return 0 if successful,
or -1 in the case of an error.”)

–
Kylotan

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

slouken · August 8, 2001, 10:27pm

I realize that Kylotan said that using windib doesn’t solve his problem,
but others may try to use it as well so I believe this is still
relevant.

The problem is that both SDL and your app have a copy of the
environemnt; so putenv changes your app’s environment, but SDL (the DLL)
won’t see it. You need to tell SDL and your app to link to msvcrt.lib (or
msvcrtd.lib in the “Debug” release settings), recompile, and it should
work fine.

As far as I know, if you follow the recommendation in the FAQ to build
with “Multithreaded DLL” settings, it should work. Please let me know
if this isn’t the case.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

Kylotan · August 8, 2001, 11:07pm

The problem is that both SDL and your app have a copy of the
environemnt; so putenv changes your app’s environment, but SDL (the
DLL)

won’t see it. You need to tell SDL and your app to link to
msvcrt.lib (or

msvcrtd.lib in the “Debug” release settings), recompile, and it
should

work fine.

As far as I know, if you follow the recommendation in the FAQ to build
with “Multithreaded DLL” settings, it should work. Please let me know
if this isn’t the case.

I was certainly using the Multithreaded DLL, as this was the only way I
could get my application to link with the SDL library in the first
place. (By the way, is this easy to change? One reason is because, as
far as I know, the first release of Win95 doesn’t have msvcrt.dll by
default) But using _putenv doesn’t work in this case. I can confirm (for
a previous poster) that SetEnvironmentVariable (a Win32 API function)
doesn’t work any more than _putenv does. (But it is almost certain that
_putenv maps directly to SetEnvironmentVariable in the runtime library
anyway.)

This doesn’t bother me, since I don’t anticipate needing the Windib
driver for much, but it might be a concern for someone else.

For what it’s worth, I use MSVC6.0 with Service Pack 3, on Windows 98
SE.–
Ben Sizer

David_MacCormack · August 9, 2001, 12:21am

I realize that Kylotan said that using windib doesn’t solve his problem,
but others may try to use it as well so I believe this is still
relevant.

The problem is that both SDL and your app have a copy of the
environemnt; so putenv changes your app’s environment, but SDL (the DLL)
won’t see it. You need to tell SDL and your app to link to msvcrt.lib (or
msvcrtd.lib in the “Debug” release settings), recompile, and it should
work fine.

As far as I know, if you follow the recommendation in the FAQ to build
with “Multithreaded DLL” settings, it should work. Please let me know
if this isn’t the case.

Thanks!
-Sam Lantinga, Software Engineer, Blizzard Entertainment

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl

I stand corrected. It seems that the selection of "Multithreaded DLL"
tells the application (and SDL) to link with msvcrt.lib – so same effect,
different means.

DaveOn Wed, 8 Aug 2001, Sam Lantinga wrote:

–

David MacCormack
@David_MacCormack

David_MacCormack · August 9, 2001, 12:44am

I stand corrected. It seems that the selection of "Multithreaded DLL"
tells the application (and SDL) to link with msvcrt.lib – so same effect,
different means.

Dave

But the SDL_WINDOWID hack is still busted (at least on win32).
SDL_RegisterApp is being called before the user’s main(…). And because
SDL_RegisterApp is the one checking for SDL_WINDOWID, the user never has a
chance to set it.

Of course I may be missing something, but I don’t think it needs to be
called from WinMain. On win32, all SDL_RegisterApp does is register the
window class and setup the trackmouse stuff, but
(DIB|DX5)_CreateWindow(…) calls SDL_RegisterApp before it tries to
create the window, so the same stuff is done later anyway. So simply
commenting out the call to SDL_RegisterApp in WinMain (plus the few other
changes included in the patch) does the trick (as can be seen the the
demo apps I sent).

Dave–

David MacCormack
@David_MacCormack

Dominique_Louis · August 10, 2001, 2:31am

Hi David,
Sam has sent me the Latest CVS compilation of SDL.dll which is
supposed to include the changes you have suggested and I am still having
problems with this window id hack… here is the Pascal code I am using…

{$IFDEF WIN32}
EnvVal := inttostr(Panel1.Handle);
SetEnvironmentVariable(‘SDL_WINDOWID’, PChar( EnvVal ) );
{$ENDIF}
if ( SDL_Init( SDL_INIT_VIDEO ) < 0 ) then
begin
exit;
end
else
begin
// Set the window manager title bar
SDL_WM_SetCaption(‘JEDI-SDL Test Window’, nil);
screen_ := SDL_SetVideoMode( seWidth.Value, seHeight.Value,
eBPP.Value, video_flags );
if ( screen_ = nil ) then
begin
exit;
end;
end;

It seems fairly straight forward to me. Can you or anyone see what maybe
causing the problem? Am I supposed to include a call SDL_RegisterApp or
is that taken care of?

The reason why I being so tenacious about this window id hack is that a
fellow Delphi developer is thinking of using SDL and my Pascal bindings
to port his OpenGL project, GLScene ( http://glscene.org ) over to Linux
and using the same code base for both Windows and Linux development. I
think GLScene would be a great application to have under Linux, hence
the reason why I am helping with this aspect.

Thanks for your patience.

Dominique

David MacCormack wrote:>> I stand corrected. It seems that the selection of “Multithreaded DLL”

tells the application (and SDL) to link with msvcrt.lib – so same effect,
different means.

Dave

But the SDL_WINDOWID hack is still busted (at least on win32).
SDL_RegisterApp is being called before the user’s main(…). And because
SDL_RegisterApp is the one checking for SDL_WINDOWID, the user never has a
chance to set it.

Of course I may be missing something, but I don’t think it needs to be
called from WinMain. On win32, all SDL_RegisterApp does is register the
window class and setup the trackmouse stuff, but
(DIB|DX5)_CreateWindow(…) calls SDL_RegisterApp before it tries to
create the window, so the same stuff is done later anyway. So simply
commenting out the call to SDL_RegisterApp in WinMain (plus the few other
changes included in the patch) does the trick (as can be seen the the
demo apps I sent).

Dave

Dominique_Louis · August 10, 2001, 6:26am

Hi All,
Apparently I am not going mad as I previously thought.After doing
some testing David and I have found out that the SetEnvironmentVariable
Windows API stores it’s variables in a different place to the libc
putenv function.

Since environment variables seem to be used on WinCE, Windows, Linux and
are probably also available under other OSes, is there any reason why
SDL_putenv and SDL_getenv are not available on at least Windows and
Linux, so that there is a uniform way of setting environment variables
under various Oses that SDL supports and that in turn support
environment variables?

Thanks,

Dominique.

David MacCormack wrote:>> I stand corrected. It seems that the selection of “Multithreaded DLL”

tells the application (and SDL) to link with msvcrt.lib – so same effect,
different means.

Dave

But the SDL_WINDOWID hack is still busted (at least on win32).
SDL_RegisterApp is being called before the user’s main(…). And because
SDL_RegisterApp is the one checking for SDL_WINDOWID, the user never has a
chance to set it.

Of course I may be missing something, but I don’t think it needs to be
called from WinMain. On win32, all SDL_RegisterApp does is register the
window class and setup the trackmouse stuff, but
(DIB|DX5)_CreateWindow(…) calls SDL_RegisterApp before it tries to
create the window, so the same stuff is done later anyway. So simply
commenting out the call to SDL_RegisterApp in WinMain (plus the few other
changes included in the patch) does the trick (as can be seen the the
demo apps I sent).

Dave

slouken · August 10, 2001, 7:49am

Since environment variables seem to be used on WinCE, Windows, Linux and
are probably also available under other OSes, is there any reason why
SDL_putenv and SDL_getenv are not available on at least Windows and
Linux, so that there is a uniform way of setting environment variables
under various Oses that SDL supports and that in turn support
environment variables?

Right now SDL_putenv and SDL_getenv are only available on operating systems
where there isn’t a standard environment variable mechanism. What I can do
though, for language bindings, is make them map to putenv() and getenv() on
systems that support them. Remind me, I’ll do this for the next SDL release.

However, keep in mind that the environment variable mechanism will go away
and be replaced with a general configuration solution with SDL 1.3

See ya,
-Sam Lantinga, Software Engineer, Blizzard Entertainment