Recommended initialisation order?

SDL Development
1

I’m experiencing a couple of minor problems with the Win32 version of
SDL, which I’ve only managed to work-cure by swapping the
initialisation order.

When put last, the sound would always give a couple of clicks after
calling SDL_OpenAudio, but when it’s just about the first thing I do
there’s no problem. I tried with an empty sound callback and filling
any requests with fixed silence, but it made no difference. Only
increasing the sample buffer size to 4096 seemed to cure it, but
that’s far too big for what I need!

Another problem is that the function keys don’t work when my
application is first started (most other keys seem fine). If I
Alt-tab away, then back to it, they work fine. I have had this
working in the past, but swapping things round to cure the sound seems
to have broken this!

I realise the underlying DirectSound implementation will use a window
handle (the main window?), so that may be sensitive to order, but I’m
not sure about other platforms and sub-systems complications.

So, is there a recommended order for setting up the various SDL
sub-systems, which is best for all platforms? Should I initialise all
at once with SDL_Init and let it worry about it?

Best regards,

Si

Si—
Note: My e-mail address is intentionally invalid to foil spammers. Change ‘nospam’ to ‘si’ for my real e-mail address.

2

I know using SDL_OPENGLBLIT is slow and all, but as a first step of
converting an app over to using OpenGL for everything, I thought I would
try SDL_OPENGLBLIT just so I could see everything (albeit slower than it
should be). Anyway, it works except that none of the colorkeying works
(the transparent color is showing up in the blit). Is this a known
limitation of SDL_OPENGLBLIT or am I doing something wrong?

-Todd

3

I know using SDL_OPENGLBLIT is slow and all, but as a first step of
converting an app over to using OpenGL for everything, I thought I would
try SDL_OPENGLBLIT just so I could see everything (albeit slower than it
should be). Anyway, it works except that none of the colorkeying works
(the transparent color is showing up in the blit). Is this a known
limitation of SDL_OPENGLBLIT or am I doing something wrong?

I think it should work - note that when using OPENGLBLIT, the "screen"
surface has an alpha channel. Exactly what format (depth and RGBA masks)
do your source and destination surfaces have? Do you use RLE? Is
SDL_SRCALPHA set on the source surface?

4

In theory someone could rewrite SDL_OPENGLBLIT as the NVIDIA drivers have a
fastpath for things like that now which should make it faster and the code
cleaner. They also support parts of the ARB_imaging extension now :slight_smile:

I initially wrote the code for the port of the Building Architect Tool (Sim
City 3000 Unlimited) so time was limited. There definitely is enough room
for improvemt in the code :wink:

  • Daniel Vogel, Programmer, Epic Games Inc.> -----Original Message-----

From: owner-sdl at lokigames.com [mailto:owner-sdl at lokigames.com]On Behalf
Of Mattias Engdeg?rd
Sent: Friday, June 01, 2001 5:12 AM
To: sdl at lokigames.com
Subject: Re: [SDL] SDL_OPENGLBLIT and colorkeying?

I know using SDL_OPENGLBLIT is slow and all, but as a first step of
converting an app over to using OpenGL for everything, I thought I would
try SDL_OPENGLBLIT just so I could see everything (albeit slower than it
should be). Anyway, it works except that none of the colorkeying works
(the transparent color is showing up in the blit). Is this a known
limitation of SDL_OPENGLBLIT or am I doing something wrong?

I think it should work - note that when using OPENGLBLIT, the "screen"
surface has an alpha channel. Exactly what format (depth and RGBA masks)
do your source and destination surfaces have? Do you use RLE? Is
SDL_SRCALPHA set on the source surface?

5

At 11:11 AM 6/1/2001 +0200, you wrote:

I know using SDL_OPENGLBLIT is slow and all, but as a first step of
converting an app over to using OpenGL for everything, I thought I would
try SDL_OPENGLBLIT just so I could see everything (albeit slower than it
should be). Anyway, it works except that none of the colorkeying works
(the transparent color is showing up in the blit). Is this a known
limitation of SDL_OPENGLBLIT or am I doing something wrong?

I think it should work - note that when using OPENGLBLIT, the "screen"
surface has an alpha channel. Exactly what format (depth and RGBA masks)
do your source and destination surfaces have? Do you use RLE? Is
SDL_SRCALPHA set on the source surface?

It’s a 16-bit screen (actually a window on a 16-bit desktop for testing).
All I did was take a 2D app and turn set the SDL_OPENGBLIT flag for the
screen mode. None of the original source blits have an alpha channel, only
a transparent color. It should “just work”, right? If I have to convert
everything to having an alpha-channel, then it seems I may as well convert
everything to 3D (which I will do anyway, but I was under the impression
that it was a quick way to get 2D and 3D co-existing). It’s not a huge
deal since it will all be textures eventually, but I was just wondering if
a fully functional 2D app should work as-is with SDL_OPENGLBLIT.

-Todd

6

The short answer is: No, it won’t “just work”. I ran into this same
problem when I was adding OpenGL support to SDL_Console.

I’m afraid I can’t remember all the relevant details, but it goes
something like this: In an OpenGL context in SDL, colorkeying for
transparency won’t work. According to Sam The Man, you have to manually
march through the pixels of the image, read the color of each one and
compare against the designated transparent color, and if they match,
change the alpha value of that pixel appropriately and write it back.

A side effect of this is that blitting transparent surfaces in SDL/OpenGL
is really only practical in 32-bit color mode, since 16-bit surfaces don’t
have alpha channels at all, and performing the above operations in
packed-pixel 24-bit mode is really quite slow, unless you put some work
into it (due to all the shifting and masking you need to do to extract the
color information). In 32-bit mode you’re just walking through an array
of bytes, so it’s pretty speedy.

I also recall something about actually disabling SDL_SRCALPHA on the
source image (isn’t that intuitive?), or else it still won’t work. But
again, I might have the details wrong.

If you look into the source of SDL_Console you can see it done right
(well, maybe not right, but at least done in a way that works).

When I asked if there was a better way, I was told “No, not yet”. Well,
is it “yet” yet?

  • cort

WARNING!***

  • This signature file contains certain unprintable ASCII character codes *
  • which may conflict with certain models of Hayes-compatible modems. If you *
  • own one such mo#em,FG%,.uld&not at …QH/vie@*&&cumen.lASDH%@@&#…^@#$^%
    ATDT $
    NO CARRIEROn Wed, 30 May 2001, Todd Allendorf wrote:

I know using SDL_OPENGLBLIT is slow and all, but as a first step of
converting an app over to using OpenGL for everything, I thought I would
try SDL_OPENGLBLIT just so I could see everything (albeit slower than it
should be). Anyway, it works except that none of the colorkeying works
(the transparent color is showing up in the blit). Is this a known
limitation of SDL_OPENGLBLIT or am I doing something wrong?

7

It should “just work”, right?

For suitable values of “just work”, yes.
please produce a minimal complete example program that shows the problem

8

I’m afraid I can’t remember all the relevant details, but it goes
something like this: In an OpenGL context in SDL, colorkeying for
transparency won’t work.

if you give a minimal example program we may be able to find out why

9

Another problem is that the function keys don’t work when my
application is first started (most other keys seem fine). If I
Alt-tab away, then back to it, they work fine. I have had this
working in the past, but swapping things round to cure the sound seems
to have broken this!

Interesting. Do you have a small sample application which you can
post a link to so we can reproduce this? Does it happen under all
versions of Windows?

So, is there a recommended order for setting up the various SDL
sub-systems, which is best for all platforms? Should I initialise all
at once with SDL_Init and let it worry about it?

Yes, the best is to initialize everything at once with SDL_Init().
If there are problems doing that, it’s either a bug in SDL, or a bug
in the underlying platform drivers.

See ya,
-Sam Lantinga, Lead Programmer, Loki Software, Inc.

10

Simon Owen wrote:

Another problem is that the function keys don’t work when my
application is first started (most other keys seem fine).

Interesting. Do you have a small sample application which you can
post a link to so we can reproduce this? Does it happen under all
versions of Windows?

False alarm on this - I think this was down to sticky keys on setting
video mode (I’m using the official 1.2.0, which I think is pre-fix?).

I was running my app thru Visual Studio using Ctrl-F5, and Ctrl seemed
to get stuck after the video was initialised. Either pressing and
release it or switching to another application and back seemed to fix
it (the one I noticed).

So, is there a recommended order for setting up the various SDL
sub-systems, which is best for all platforms? Should I initialise
all at once with SDL_Init and let it worry about it?

Yes, the best is to initialize everything at once with SDL_Init().
If there are problems doing that, it’s either a bug in SDL, or a bug
in the underlying platform drivers.

I do still suffer from this, even with SDL_Init at the start of the
application. I’ve had it happen with a variety of sound and video
cards (all were Windows 2000 with DX8), so I’ll strip it down as much
as I can (or until I discover something else that’s causing it!).

Best regards,

Si

SiOn 7 Jun 2001 06:41:22 -0700, Sam Lantinga wrote:

Note: My e-mail address is intentionally invalid to foil spammers. Change ‘nospam’ to ‘si’ for my real e-mail address.