chicken-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-users] SDL


From: Brandon J. Van Every
Subject: [Chicken-users] SDL
Date: Wed, 07 Feb 2007 14:15:31 -0800
User-agent: Thunderbird 1.5.0.9 (Windows/20061207)

Peter Keller wrote:
On Wed, Feb 07, 2007 at 12:12:44PM -0800, Brandon J. Van Every wrote:
  
For clarity: Thu, John, and myself are not working on the kind of GUI 
toolkit you're talking about.  We're not doing widgets.  We're just 
putting OpenGL windows up on a screen, so that game developers can get 
started with something productive.  We're not going to try to make 
events invisible to the programmer.  We will facilitate a developer who 
wants his own control over event loops, callbacks, and other event 
passing mechanisms.  Game developers usually hate it when the toolkit 
gets in the way of how they want to do the event handling stuff.
    

So how is the SDL and OpenGL egg not sufficient for this?

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.

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 also wonder whether binding SDL is "sufficiently Scheme oriented" and "sufficiently non-game oriented" to be of value to the Chicken community.  I feel a need to look at the design of SDL before making a pronouncement on this.

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.

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.

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.


 I've coded
plenty of graphics programs (in C) with those two alone. Most games have
some handwritten "windowing system" in them anyway--and wouldn't have
it any other way. SDL provides plenty of fine granularity for things
like keyboard/mouse events and the programmer has their own event loop.

Unless I'm mistaken in understanding what you're trying to do, I think
you're trying to solve a problem that isn't there.

The SDL APIs (graphics, mixer, tiff, etc) are plenty good for serious
games.  In looking through the eggs, I'd add SDL-mixer and libpng to
the pile, 

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.

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?

port the OpenGL egg to use OpenGL 1.5 at least, 

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?

add an OpenGL Shader egg, 

I hope someone else champions GLSL support.  I've been avoiding shader issues for years, because the standards keep changing.  I agree this needs to be done, but it doesn't need to be done as a 1st thing.  GLSL support is the working definition of gruntwork, IMHO.

and then there'd be *plenty* of goodies to write good games
(and their level editors).
  

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

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?  :-)


Cheers,
Brandon Van Every


reply via email to

[Prev in Thread] Current Thread [Next in Thread]