Re: [Chicken-users] SDL

[Peter Keller]

Hello,

On Wed, Feb 07, 2007 at 02:15:31PM -0800, Brandon J. Van Every wrote:
> I did not get far with the current SDL egg because it pulls in way too 
> many SDL auxiliary libraries.  This makes it really really difficult to 
> compile successfully on MinGW.  But if that's the extent of 
> difficulties, they can be solved.

I've never used the Chicken SDL egg, so I can't comment on that.

> SDL is a huge system that does a lot more than just OpenGL.  For this 
> reason, I have resisted learning it for years.  At one point in the past 
> when I looked at it, it wasn't adequate to my needs.  I wanted hardware 
> accelerated alpha blended 2D sprites, and it was doing the alpha 
> blending in software only.  But I don't know where SDL is at now.  That 
> was a few years ago.

I never got this impression at all. For me, SDL was only the small
interface layer between OpenGL, the audio/CD-Rom system, and the
windowing/kb/mouse system.  The table of contents for the API seems to
be only that: http://www.libsdl.org/intro.en/toc.html

Here is a snippet of C code which simply opens a window, sets up opengl,
and handles some keyboard inputs, the entry point to these functions
is setup_window():

void hotkey_toggle_full_screen(void)
{
    SDL_Surface *screen;

    screen = SDL_GetVideoSurface();
    if ( SDL_WM_ToggleFullScreen(screen) ) {
        printf("Toggled fullscreen mode - now %s\n",
            (screen->flags&SDL_FULLSCREEN) ? "fullscreen" : "windowed");
    } else {
        printf("Unable to toggle fullscreen mode\n");
    }
}

int process_events(void)
{
        SDL_Event event;
        while(SDL_PollEvent(&event))
        {
                switch(event.type)
                {
                        case SDL_KEYDOWN:
                                printf("key '%s' pressed\n", 
                                        SDL_GetKeyName(event.key.keysym.sym));
                                switch(event.key.keysym.sym)
                                {
                                        case SDLK_ESCAPE:
                                                /* FALL THROUGH */
                                        case SDLK_q:
                                                printf("Quitting....\n");
                                                return TRUE;
                                                break;
                                        case SDLK_RETURN:
                                                if (event.key.keysym.mod & 
KMOD_ALT)
                                                {
                                                        
hotkey_toggle_full_screen();
                                                }
                                        break;
                                        default:
                                                /* Do nothing */
                                                ;
                                }

                                break;
                        case SDL_KEYUP:
                                printf("key '%s' released\n", 
                                        SDL_GetKeyName(event.key.keysym.sym));
                                break;

                }
        }

        return FALSE;
}

void setup_opengl( int width, int height )
{
        glShadeModel( GL_FLAT );
        glEnable(GL_DEPTH_TEST);
        glDepthFunc(GL_LESS);

        glClearColor( 0.0, 0.0, 0.0, 0.0 );

        glOrtho(0, width, 0, height, -1.0, 1.0);

        glPixelStorei(GL_UNPACK_ALIGNMENT, 1);
}

void setup_sdl(int width, int height, int bpp, char *title)
{
        int flags;
        SDL_Surface *screen = NULL;
        
        /* Initialize defaults and video */
        if((SDL_Init(SDL_INIT_VIDEO)==-1)) { 
                printf("Could not initialize SDL: %s.\n", SDL_GetError());
                exit(-1);
        }

        /* Clean up on exit */
        atexit(SDL_Quit);

        /* Set up preliminary opengl stuff */
        SDL_GL_SetAttribute( SDL_GL_RED_SIZE, 8 );
        SDL_GL_SetAttribute( SDL_GL_GREEN_SIZE, 8 );
        SDL_GL_SetAttribute( SDL_GL_BLUE_SIZE, 8 );
        SDL_GL_SetAttribute( SDL_GL_DEPTH_SIZE, 16 );
        SDL_GL_SetAttribute( SDL_GL_DOUBLEBUFFER, 1 );

        flags = SDL_OPENGL;
        
        /* make a surface for OpenGL to use */
        screen = SDL_SetVideoMode(width, height, bpp, flags);
        if ( screen == NULL ) {
                fprintf(stderr, "Couldn't set %dx%dx%d video mode: %s\n",
                        width, height, bpp, SDL_GetError());
                exit(1);
        }

        SDL_WM_SetCaption(title, title);
}

void setup_window(int width, int height, int bpp, char *title)
{
        setup_sdl(width, height, bpp, title);
        setup_opengl(width, height);
}


After setup_window is called, you then enter the SDL event loop doing
your drawing, that looks like this:

    now = SDL_GetTicks();
    sample = now + 33;

    while(done == FALSE) {
        draw_frame(...)

                // sample events periodically
        if (now > sample) {
            done = process_events();
            sample = now + 33;
        }
        now = SDL_GetTicks();
    }


I mean, I never had anything more than that, ever, for SDL unless I
specifically wanted to use SDL-mixer or something for sound effects
and music.

If SDL has all sorts of other mojo in it, I don't know what it is since
the stuff I described is almost always the only stuff I'd ever use for
any game.

> I wonder if SDL makes design compromises from an OpenGL programmer's 
> point of view, that aren't so hot.  SDL started life as a 2D toolkit, 
> not 3D.

Even if SDL started as a 2D toolkit and has some bit blitting functions,
as soon as you interface it with OpenGL, you only use a small section
of SDL, and any 2D thing you want to do you do directly in OpenGL which
will be accelerated if possible. I didn't even know it started as a 2D
interface until you just mentioned it and I went and looked at the API...

> I am intrigued that Quake 4 used a modified SDL on Linux somehow.  But 
> it was modified, not straight up.  Also it seems they did it for Linux 
> only, not Windows.  I wish I could find a concise summary of why ID 
> Software didn't find off-the-shelf SDL acceptable.  Maybe I'll have to 
> download their SDL patch and comb through it for clues.

I have a friend who happened to work on Quake 4, and he said he is pretty
sure no SDL was used at all. He was only 90% sure about the Linux port
since that wasn't done in house. He said if it was used, it was probably
for the mouse/keyboard events and nothing else.

> A number of OpenGL developers have avoided SDL and instead come up with 
> things like CPW and GLFW.  I'm wondering why.  Maybe SDL didn't do 
> things once upon a time, that it does now.  Or maybe SDL has some fatal 
> flaw.  I need to read more about the pros and cons of contemporary SDL.

>From my point of view, SDL would do everything I'd ever want it to do
and in a method I like (aka: I control the event loop). I think stuff
like CPW and GLFW showed up because their designers would rather have
written something themselves instead of using previous work or because
older interfaces bitrotted and got updated into a new form. That is only
my opinion though--though heavily influenced by my experience of watching
many groups reimplement the same thing with the same design flaws over
and over again because they fear the "not invented here" perception.

> That's another issue.  Is it desireable to get stuck with support for 
> the entire stack of typical SDL libraries?  I know this doesn't advance 
> my own immediate goals.  My goal is to do clever geometry processing in 
> Scheme, ala so-called Procedural Content.  I'm not interested in a 
> million support burdens for "standard" game development toolchains.  I 
> think the way people currently produce games is pretty broken.  There's 
> too much gruntwork, 1 guy can't control what's going on.  As an indie 
> game developer, my design sensibilities are always based on what 1 guy 
> can actually get done.

[snip]

> SDL is fine on Linux.  Is it going to keep up with Windows Vista?  Does 
> it have any relevance to the Playstation3, the Wii, or the XBox 360?  Or 
> handhelds or cell phones?  Is porting SDL to new platforms hard?  Are we 
> better off with a less ambitious toolkit that tackles only a few basic 
> OpenGL jobs?

I honestly don't think ANY windowing system interface is going to meet
your goals. And I suspect that writing one will at first seem like a good
idea, until you decide you don't want to make it work on the xbox 720,
the ps3.1415926, the nintendo hypercube, and the Plan 9 operating system
when it takes over the world.

Sometimes you just have to suck it up and accept you will have porting
issues and have to end up using conditional compilation and an abstraction
interface to smooth over the sharp edges of where your code meets the
OS interfaces.

> Seamless OpenGL 2.0 support is an issue on Windows, even in plain C.  
> The Glee and Glew libraries deal with this.  But, does SDL?  Or does SDL 
> insist on "function pointer dances?"  Also, what about the various 
> flavors of OpenGL ES?  This is important to consoles like the 
> Playstation3.  SDL have anything to say about that?

As far as I know, you simply ask to make a window of the right type. Then 
opengl just "works" in that window. From what I know of the interfaces, I
can't see it do anything else.

As for things like the playstation 3, well, you should probably just
use whatever SDK the manufacturer has (while they charge you an arm and
a leg for the privledge)--that way you're sure it is going to work.

These days, if I wrote game codes in scheme, linux and windows is where
I expect it to work. 

> I think I've established that there are lotsa reasons why SDL may or may 
> not be desireable.

So then you should, or shouldn't, use it. :) Of course, I'm being
facetious there, but my point is that you should pick the platforms you
want your game to run on (and "all of them" is a bad choice) and write
whatever unification layer you need over the available native libraries
and then write your game. It is often easier to write/maintain the
unification layer than design something that would be natively used on
all of the platforms.

Let OTHER people who get paid for it maintain those native libraries.

> >If you want more toolkit-like junk, then write a nice asset management
> >library since that is stuff a programmer usually just wants to have
> >and doesn't like having to write.
> >  
> 
> We're not looking to create busywork for ourselves.  Consider the logic 
> of what you just said: are we not programmers?  :-)

For some very odd reason, an old saying in my workplace comes to mind, 
"Fix it, but don't change anything."

:)

Later,
-pete