At 10:04 PM 3/26/2001 -0800, you wrote:
I’m new to SDL (I know, not another one) and I’ve ran into a few issues
while porting an application to SDL.
I’m using version 1.1.8
- Is there something about using SDL that would prevent my own
DirectSound sound system from working? I started my port with just the
graphics layer (which was originally in MGL). I discovered my sound
routines wouldn’t work even though I didn’t initialize SDL’s sound
subsystem. The funny thing is, the DirectSound stuff initialized
correctly, allocated buffer, loaded samples and believed it was palying
sounds but no audible sounds were coming out of the speakers. Very
weird. I’m just a little concerned if that using SDL means you have to
it for EVERYTHING which could be problematic for some of the other
In DirectX, sound is tied to the window handle. The simplest way to get
this to work is just to use SDL for audio, but it is possible to retrieve
the window handle from SDL.
This is exactly what I did. It is the same situation with MGL, you grab
the windows handle and pass it to DirectSound. As I said, DirectSound
thinks everything is fine (it accepts the window handle and creates buffers
with no problem), but no sound. That is what is so weird since its never
failed before with MGL and regular OpenGL.
- I did end up porting the sound layer (which went pretty quickly) but I
was wondering if there was a way to adjust the hardware sound volume from
within SDL? With DirectSound, you would simply adjust the volume of the
primary sound buffer (if supported), but I couldn’t find an equivalent in
the docs and nothing in the source code jumped out at me.
No, the general consensus over the years has been that it’s dangerous
to modify the hardware volume without asking the user. To simplify the
issue, SDL assumes that the user uses an external program to adjust the
hardware volume. SDL 1.3 will revisit this issue.
Bummer. In the end, the app will be the only program running (booted off a
CD-ROM, if possible), so it is necessary that the app be able to adjust the
hardware volume since there will be no other app to do it. I guess I could
try accessing DirectSound (and whatever Linux or BeOS use) to do it but
given what happened above, I’m kinda skeptical that this will work. Also,
it increases the amount of platform-specific code to maintain.
- For double buffer modes, how can you tell which page is being
displayed? I have a dirty-rectangles system that needs this info. I used
to fake it under MGL (curbuffer = (curbuffer++)%nPages) but it could
sometimes mess up. I never could figure out if it was my fault or MGL’s,
but since the current page is a property of their display contexts, it
have been desired and useful to someone besides me.
Double buffer modes have only two pages at the moment. The pages are flipped
after a call to SDL_Flip(). Keep in mind that double buffering isn’t
with all video drivers.
I will be able to guarantee what hardware the app ultimately runs on, and
the app does check for its availability and will either drop back to single
buffering or simply inform the user that it can’t run. I realize that I
should be able to track which buffer is active myself, but like I said
that wasn’t the case with MGL. Will triple buffering (for 3D) be added later?
That’s it for now. So far, I’m really impressed with how easy the porting
has gone. I can’t wait to try out the OpenGL stuff.
Thanks! I think you’ll be happy with the OpenGL stuff too…
-Sam Lantinga, Lead Programmer, Loki Entertainment Software