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!