Maelstrom 3.0.4 Beta

The SDL 1.2 compliant version of Maelstrom is now available for testing:
http://www.devolution.com/~slouken/Maelstrom/src/Maelstrom-3.0.4.tar.gz

It requires SDL 1.2 prerelease:
http://www.libsdl.org/cvs.html

It also requires the prerelease SDL_net library:
http://www.libsdl.org/cvs/SDL_net-1.1.2.tar.gz

It works on all platforms supported by SDL except MacOS classic,
because SDL_net hasn’t been ported to it yet.
The person who was porting SDL_net to MacOS classic please send me
e-mail with the current progress? I lost your address in the great
mail loss.

Please send feedback directly to slouken at devolution.com

Thanks!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

It works on all platforms supported by SDL except MacOS classic,
because SDL_net hasn’t been ported to it yet.
The person who was porting SDL_net to MacOS classic please send me
e-mail with the current progress? I lost your address in the great
mail loss.

I don’t have his name on-hand, but he did send me the source a long time
ago, perhaps enough of it works to get Maelstrom running:

http://icdweb.cc.purdue.edu/~walisser/sdl/devel/SDL_net_102.sit

Regards,
Darrell
-------------- next part --------------
A non-text attachment was scrubbed…
Name: not available
Type: text/enriched
Size: 609 bytes
Desc: not available
URL: http://lists.libsdl.org/pipermail/sdl-libsdl.org/attachments/20010324/c0a56d06/attachment.binOn Saturday, March 24, 2001, at 10:06 AM, Sam Lantinga wrote:

It works on all platforms supported by SDL except MacOS classic,
because SDL_net hasn’t been ported to it yet.
The person who was porting SDL_net to MacOS classic please send me
e-mail with the current progress? I lost your address in the great
mail loss.

I don’t have his name on-hand, but he did send me the source a long time
ago, perhaps enough of it works to get Maelstrom running:

It doesn’t. I’ve already tried all the mac port versions that are
floating around. If somebody wants to tackle it fresh, grab the
CVS source archive:
http://www.libsdl.org/cvs/SDL_net-1.1.2.tar.gz

See ya,
-Sam Lantinga, Lead Programmer, Loki Entertainment Software> On Saturday, March 24, 2001, at 10:06 AM, Sam Lantinga 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

  1. 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 use
    it for EVERYTHING which could be problematic for some of the other subsystems.

  2. 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.

  3. 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 must
    have been desired and useful to someone besides me.

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 in advance.

-Todd Allendorf
@Todd_Allendorf

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

  1. 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 use
    it for EVERYTHING which could be problematic for some of the other subsystems.

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.

  1. 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.

  1. 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 must
    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 available
with all video drivers.

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… :slight_smile:

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software

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

  1. 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
    use
    it for EVERYTHING which could be problematic for some of the other
    subsystems.

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.

  1. 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.

  1. 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
    must
    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
available
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… :slight_smile:

See ya!

    -Sam Lantinga, Lead Programmer, Loki Entertainment Software

Thanks again.

-Todd Allendorf
@Todd_Allendorf

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.

As I said, this functionality will probably end up in SDL 1.3 at some point,
since so many people want it. It will have big warnings in the documentation
though. :slight_smile:

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.

It should be the case with SDL.

Will triple buffering (for 3D) be added later?

I’m not sure how triple buffering is done with OpenGL.
General multi-buffering for 2D will be available in SDL 1.3

See ya!
-Sam Lantinga, Lead Programmer, Loki Entertainment Software