[Numpy-discussion] Re: [Pysdl-devel] Further development...

Pete Shinners pete at shinners.org
Wed Jul 26 00:46:33 CDT 2000


> Ideas I've tossed around include creating an interface similar to the one
> surface objects have for audio buffers, adding adaptors for PIL and PST,
> creating an overly complex system for 'compiling' surface operations for speed,
> and some other things.
> I don't know. So I'm asking. What is it you want?

interfacing with PIL should be pretty easy with the "fromstring" and
"tostring" style functions that PIL uses. Numpy interfaces with PIL
in this manner. (in fact with my unofficial numpy extension, you can
already use numpy to get the images into PIL (or so i assume, have
yet to test something like that :] ))

i also like the idea of easier integration with "C" extensions,
but this will prove a bigger challenge than breaking up the
source i'd imagine. (although it will likely require it, since
currently, all the global objects are created in the header file
(DOH)) 


well, you asked for it...
here's a sampling things i'd like to see for pysdl
--------------------------------------------------------------------

first is throwing exceptions instead of returning -value error codes
now that i'm into python, i love the flexibility of exceptions, instead
of checking every function call for its return code, you just call
all the functions, and put the error handling at the end

a wrapper for some line/polygon filling library. i assume SDL has
something like this already, but everynow and then i keep thinking
i'll want this. i'd especially like this if it was done on a library
tuned for SDL, so i can get fast-as-possible-filled-polygons

break the sourcecode into smaller files. :]
actually i really do want this one. i would love to hear a discussion
of the best possible ways to get this done. i've done this in a 
reasonably clean and efficient way. it isn't thoroughly planned out
but i was pleased with how it turned out. if it can be used as a 
starting point for discussion it will have served its purpose!

numeric python implementation. i've got a crude sample of this
going. (the other) peter and i were able to attain some amazing
speed gains. it's not for everyone (and i think well discussed :] )
but it beats the pants off trying to drum up a C extension to do
basic image operations.
anyways, those speedups we saw were on pretty basic operations.
things like a 640x480 radial gradient went from about 20 seconds
to under 2 seconds (and that was still with python doing the color
conversions, and a generic non-optimized numpy-2-sdl transfer).
i also have my basic "fire" demo running under numpy that would
be foolhardy without numpy

cleanup of the "event" handling routines. currently i think it's
too much "C" and too little "python". i've thought out a couple
simple changes that make it much smaller and more graceful than
event handling with C-SDL

some higher-level classes written in python. simple base classes
for things like sprites, eventhandlers (i'm enjoying mine!).
the reason these should be in python to begin with is so they can
be easily inherited and extended.

i still haven't got to using the sound routines in pysdl, but
it seems like a much cleaner implementation could be made from
what there is in C-SDL (and we've currently duplicated for pysdl).
instead of the current "audio.play(mysound)" something more like
"mysound.play()". i realize there's some issues involved, and
i haven't really looked at the audio interfaces (yet), but from
what i currently see it seems a little backwards

heh, this one just occurred to me, but check with PERL and 
other SDL language bindings to make sure we're not missing
out on any great ideas

at least the thought of switching to using distutils. i've
scanned through their docs and examples, and it seems powerful.
perhaps best to wait for the next python release which includes
distutils standard. but i would love to hear anyone's experience
if they've maintained any packages with this.

this will probably just have to wait until someone out there
needs something like this and just goes ahead and creates it.
but to help a pysdl game rely on 3rd-party extensions written
in python there could be some prebuild "rexec" modes that
can run python code in a 'gaming-oriented' restricted environment.
i dunno, it's just something that pops into my head once in awhile

i looked into the SDL_net library to see if it was worth including
with pysdl. after checking it all out i saw nothing that wasn't
offered by the standard python "socket" libraries. i'd say this
library is worth ignoring, until someone can bring forth some
facts that i overlooked

finally, i'll end with a simple one. just a global pysdl function
to get the current screen. when writing my game between multiple
modules i'm always having to pass the screen (and other info)
around between all the modules. there may be other pysdl
"state" info like this that is usefull to be able to access from
any of the modules in my game (i just haven't found em yet)



i like peter nicolai's idea for the web plugin. but i fear that
SDL is not the base library of choice for this type of project,
since SDL has little control over the display window.
(ie, impossible to "embed" into other windows)

as for other platforms, i have done limited testing on IRIX
which has worked great for me. (IRIX being another platform
that SDL has recently supported)





> A side note to Pete: I haven't been ignoring you, I've just been
> trying to decide what I think of it before giving you a response

no trouble. i've decided to just start writing stuff and deal
with issues as they come up. i figure with this approach there are
two benefits. first, i'll have real-world experience to make my
"suggestions" a lot more worthwhile. second, there is a top
notch pysdl game out there!







More information about the Numpy-discussion mailing list