SDLpl moving right along

SDL Development
1

A number of people have written me in the past couple
months asking where the perl bindings for the SDL are
going, and why the download links were broken at the
SourceForge site. Here are some answers:

This past summer I quit my job at VA Linux Systems,
and moved back east. I have been rewriting and rewriting
a high level abstraction layer for SDL applications.
Now that I think I’ve learned what I did wrong with
the first version.

This weekend I’m moving into a new apartment in
Greenwhich Village, as I’m working in Manhattan
for the Sporting News’ Fantasy Games division.
(sorry no SDL apps here)

Along with my physical move, I have decided to move the
development pages and CVS for SDLpl from SourceForge to
my own boxes, accessible at

http://cthulhu-burger.com/sdlpl

The rational for this is that I have CVS running on all
of my boxes, and it is just a pain to maintain CVS at
SourceForge. Additionally, as I update cthulhu-burger
daily, I hope that the move will mean that I provide
more feedback. Anonymous CVS is up an running, if someone
feels like really contributing drop me a line and I’ll
give you a shell account, email, cvs access in return
for patches :slight_smile:

Anyways as for the future, the current release of SDLpl
is 1.1.1.1 which is basically 1.08 with a few minor changes.
I am not planning on anything other than minor bug fixes
to the core to maintain compatability with SDL.

What will be changing the level of abstraction both at the
perl level, and the C level, is the Programmer Experience.
The goal is to unify the Perl modules (like SDL::App and
SDL::OpenGL::App) and to hide all the crap most people will
never use.

BTW, I was asked if I knew of any good games using SDLpl by
Guillaume Cottenceau , so if you have
actually done something you might like to see in Mandrake Linux
please drop Guillaume and myself a line.

Dave Goehrig

2

Dave Goehrig wrote:

What will be changing the level of abstraction both at the
perl level, and the C level, is the Programmer Experience.
The goal is to unify the Perl modules (like SDL::App and
SDL::OpenGL::App) and to hide all the crap most people will
never use.

excellent. as the python sdl maintainer, i’m always interested to see
how people do these higher level bindings for sdl. i don’t know if you
care to browse what i’ve been able to put together for pygame. it is
higher level than SDL in C, but i believe there’s always of room for
improvement. one day many years from now SDL2 will likely be released,
and at that point i’ll be interested in redoing the python stuff from
the ground up. therefore i’m always on the lookout for good design ideas :]

designing a nice higher level library like that is always tricky.
there’s a battle between flexibility and simplicity. i’d be glad to chat
about this stuff with anyone.

3

excellent. as the python sdl maintainer, i’m always interested to see
how people do these higher level bindings for sdl. i don’t know if you
care to browse what i’ve been able to put together for pygame.

Pete, I make it a point to keep track of what you’ve been up to, I follow
pygame development quite closely. At one point I had actually written
python bindings that worked more or less the same way the perl ones did,
then I found pygame and figured there was no point releasing it :slight_smile: I have
numerous time thought of replicating pygame’s API in perl, but some things
pygame does make more sense in python than it does in perl.

one day many years from now SDL2 will likely be released,
and at that point i’ll be interested in redoing the python stuff from
the ground up. therefore i’m always on the lookout for good design ideas :]

I would honestly like to bounce ideas with you, and also the people who
have done the two ruby bindings. The lot of us wackos share a common
problem set: How to make up for the interpreter overhead, without requiring
people just write things in C. I’m leaning towards relying on hardware
acceleration and OpenGL for really hardcore stuff, and just ignoring
per pixel video operations and the like on light weight clients (like my
ipaq). I know you’ve put a lot of work into mangling buffers from
python, and wouldn’t mind hearing your argument for such features.

designing a nice higher level library like that is always tricky.
there’s a battle between flexibility and simplicity. i’d be glad to chat
about this stuff with anyone.

Do you think we need a mailing list setup for that sort of thing?On Fri, Nov 09, 2001 at 10:24:59AM -0800, Pete Shinners wrote:

4

I would honestly like to bounce ideas with you, and also the people who
have done the two ruby bindings. The lot of us wackos share a common
problem set: How to make up for the interpreter overhead, without requiring
people just write things in C. I’m leaning towards relying on hardware
acceleration and OpenGL for really hardcore stuff, and just ignoring
per pixel video operations and the like on light weight clients (like my
ipaq). I know you’ve put a lot of work into mangling buffers from
python, and wouldn’t mind hearing your argument for such features.

Do you think we need a mailing list setup for that sort of thing?

nah, i dunno if it’ll get that serious. :]
danny and i (RUDL project, aka TsuiHark) worked together a lot when he
was doing his ruby binding. a lot of his code is based on stuff from
pygame. i learned a bit about ruby then :] there’s some nifty things you
can do on the api side.

the only place that really needed much “design” was with the joystick
and cdrom modules. i felt they were pretty awkward in SDL, since there
is a mix between some functions you call with an id# and some you call
with a CD object.

if i was to do it all over again. i think i’d try doing a direct
wrapping to SDL, but then cover it all in a higher level binding. then i
feel i could do some fancier “automagic” things in the higher level
layers, but people could bypass them if they really wanted.

one place where i can’t come up with a clean design is those surface
objects. there’s so much you can do with surfaces, it’s impossible to
really make all functions that effect them into the surface class (or
could i?) stuff like drawing and transformations. right now that’s one
thing i don’t really like about pygame. there’s many things you can do
with a Surface object. but there’s just as many functions that take a
reference to a Surface. kind of a split design :-/

do you have anything online yet for your new design? just looking at a
"Hello World, SDLpl2" would be curious for me to look at.

5

Pete Shinners wrote:

I would honestly like to bounce ideas with you, and also the people who
have done the two ruby bindings. The lot of us wackos share a common
problem set: How to make up for the interpreter overhead, without requiring
people just write things in C. I’m leaning towards relying on hardware
acceleration and OpenGL for really hardcore stuff, and just ignoring
per pixel video operations and the like on light weight clients (like my
ipaq). I know you’ve put a lot of work into mangling buffers from
python, and wouldn’t mind hearing your argument for such features.

Do you think we need a mailing list setup for that sort of thing?

nah, i dunno if it’ll get that serious. :]
danny and i (RUDL project, aka TsuiHark) worked together a lot when he
was doing his ruby binding. a lot of his code is based on stuff from
pygame. i learned a bit about ruby then :] there’s some nifty things you
can do on the api side.

the only place that really needed much “design” was with the joystick
and cdrom modules. i felt they were pretty awkward in SDL, since there
is a mix between some functions you call with an id# and some you call
with a CD object.

if i was to do it all over again. i think i’d try doing a direct
wrapping to SDL, but then cover it all in a higher level binding. then i
feel i could do some fancier “automagic” things in the higher level
layers, but people could bypass them if they really wanted.

 This was the direction I decided on when I could not get SDLpl to

compile with the latest SDL version on Solaris. I used SWIG to generate
the “direct” perl bindings to the SDL library. Then I was planning to
do a higher level (more perlish) interface. This would be similar to
the results of the earlier SDLpl and pygame interfaces but would allow
porting and “drop down” to a C level if desired. It would also permit
automatic generation of bindings to other languages transparently
(python).
Other performance optimizations were to follow. I was able to get a
minimal SWIG wrapper set done in about a day’s work—had to come up
to speed on the details of SWIG. I would be interested in helping out
with this. I’ve been away from that project for a few weeks but hope to
come back to it soon.

–Chris> one place where i can’t come up with a clean design is those surface

objects. there’s so much you can do with surfaces, it’s impossible to
really make all functions that effect them into the surface class (or
could i?) stuff like drawing and transformations. right now that’s one
thing i don’t really like about pygame. there’s many things you can do
with a Surface object. but there’s just as many functions that take a
reference to a Surface. kind of a split design :-/

do you have anything online yet for your new design? just looking at a
"Hello World, SDLpl2" would be curious for me to look at.

SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl