Features -> build problems

SDL Development
1

Hi folks,

while building dosbox against sdl-1.2.9 I’ve noticed some
conceptional problems with switchable features, which directly
affect the API: things which normally belong into several
libraries, ie. cdrom handling, are a part of libSDL.so and
completely missing, if these features are disabled. It seems
there’s no clean way for applications to test for these
features, and so linking may break with missing symbols.

For distro/integrator folks like me, this makes work quite
complicated. Feature dependencies are in general bad design,
and if supplied features cannot be detected, it makes the
problem even worse.

To get out of this debacle, the cleanest way would be splitting
off libSDL.so into several libs - one for each feature / API part.

At least this should happen virtually - by supplying several
.pc files / -config scripts, each representing an separate library,
but all pointing to the same .so.

cu–

Enrico Weigelt == metux IT service

phone: +49 36207 519931 www: http://www.metux.de/
fax: +49 36207 519932 email: contact at metux.de
cellphone: +49 174 7066481

– DSL ab 0 Euro. – statische IP – UUCP – Hosting – Webshops –

2

Hi
I’m currently writing a small opengl+sdl screensaver for windows. The
problem is, that my main programming environment is a mac and I just
switch over to windows (virtual pc) to compile and test.
However - the screensaver works, but on some systems it’s lagging
really bad, like 8 fps or so.
After what I found on the net about win-screensavers I guess (yes,
just a guess) it’s got something to do with the window-handle windows
passes to the screensaver by commandline parameter (and which I’m not
using at the moment), because on the very same computer the
screensaver works fine when started as a “normal” application.

Now for my question: Is there any possibility to pass that window-
handle to sdl? I’m not that good in (read: I’ve never done) WinAPI
programming, so I would really like to stay with SDL, especially
after I’ve seen the Nehe-Tutorial for creating a OpenGL-window under
windows - I must say “I’m not amused” ^^

Arne

3

first of all

#include SDL_syswm.h

then in your code:

SDL_SysWMInfo info;
SDL_VERSION(&info.version);
SDL_GetWMInfo(&info) // fill the structure

on WIN32 this struct is

typedef struct {
SDL_version version;
HWND window; /* The Win32 display window /
HGLRC hglrc; / The OpenGL context, if any */
} SDL_SysWMinfo;

as to what you’ll do with it i don’t know, but SDL does use it.

hope this helps

4

first of all

#include SDL_syswm.h

then in your code:

SDL_SysWMInfo info;
SDL_VERSION(&info.version);
SDL_GetWMInfo(&info) // fill the structure

on WIN32 this struct is

typedef struct {
SDL_version version;
HWND window; /* The Win32 display window /
HGLRC hglrc; / The OpenGL context, if any */
} SDL_SysWMinfo;

as to what you’ll do with it i don’t know, but SDL does use it.

I already got that tip from another reader via personal email (but
thank you, too :).
The problem is, that I don’t just need the SDL window handle but to
change it like

void setupSDL(HWND windowhandle) {
SDL_useHandle(windowhandle)
SDL_Init(SDL_INIT_VIDEO);
SDL_SetVideoMode(0,0,0,SDL_OPENGL);
}

The last line means “use the existing window-resource (with
resolution and such if a HWND resource covers this), just make it an
opengl surface”.
I guess that’s going to be a kind of deeper hack into sdl, so I don’t
know if it’s possible at all.

Arne

5

i use SDL to get away from os specific code, so i have no idea.

good luck though…

6

Search for the window id hack.

You can set an env var SDL_WINDOWID (or similar, can’t remember exactly)
to your desired window handle.
AFAIK, using this method you have to process native event yourself.

Regards,
JohannesOn Thursday 01 September 2005 14:37, Arne Claus wrote:

Now for my question: Is there any possibility to pass that window-
handle to sdl? I’m not that good in (read: I’ve never done) WinAPI
programming, so I would really like to stay with SDL, especially
after I’ve seen the Nehe-Tutorial for creating a OpenGL-window under
windows - I must say “I’m not amused” ^^

7

while building dosbox against sdl-1.2.9 I’ve noticed some
conceptional problems with switchable features, which directly
affect the API: things which normally belong into several
libraries, ie. cdrom handling, are a part of libSDL.so and
completely missing, if these features are disabled. It seems
there’s no clean way for applications to test for these
features, and so linking may break with missing symbols.

The standard SDL build should always have all subsystems enabled.
You’re welcome to build SDL with any of the subsystems disabled,
but you should never ship that for general use with any system;
it should be a custom library included specifically for your app.

-Sam Lantinga, Software Engineer, Blizzard Entertainment