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

[Mark B. <mb...@0x...>]

On Tue, 25 Jul 2000, Peter Nicolai wrote:
> > So what I'm looking for, is ideas as to what people
> > want from PySDL, that it
> > doesn't currently provide.
> 
> Support for more OS's and smpeg.

It's fairly difficult to tell whether PySDL functions on platforms other than
Unix and Win32, without access to platforms other than Unix and Win32.

So perhaps someone can tell me where PySDL fails on MacOS or BeOS, which're the
only other operating systems that SDL supports that PySDL might not.
The code should be rather endian neutral.

There are probably issues on 64-bit platforms, too, since Python doesn't
gurantee the size of a data type. Whether or not this is the case,  I can't say.
If someone has an Alpha or an Ultra, they're free to let me know.


> > Ideas I've tossed around include creating an
> > interface similar to the one
> > surface objects have for audio buffers,
> 
> I'd like this, and if Python had better MIDI support
> it could probably be used for some weird MAX-like
> stuff.  I know that's probably off the subject.  But I
> do think SDL could offer more than just 'play sound'.

Yes, I agree that it could do more than play sound.
I'm not sure that Python, though, would be any better for real-time audio
processing than it is for real-time surface processing.

CPython's tendancy to "do it simply" instead of "do it well" limits it domain
a little.

> I remember this in the whole discussion about Numeric
> -- it seems like an interesting idea but maybe you're
> right about Python not being right for this kind of
> thing.  I do really hope you'll put in a way to
> transfer between Numeric arrays and surfaces though,
> if it doesn't wreck anything. 

I still am perplexed as to what domain numpy would provide a good deal of
benefit, since it seems to require good sized arrays to garner impressive
increases. Or at least that's what I inferred from their documentation.
I've been waiting for Pete Shinners to provide a preliminary connection between
PySDL and numpy that doesn't make PySDL depend upon it, and provides a
distinctive speed advantage. Perhaps he's made a patch available and I've
missed it. 
Given that I've never used numpy, and Pete has, I think he can meet the
criteria better than I can. It wouldn't be fair for me to do it, find my poor
attempt insufficient, and then discard it. I suppose I could do some research,
though.

If it can be shown that it provides a benefit that outweighs adding yet another
library to PySDL's list, I'll be happy to accept a fully numpy-dependent PySDL
patch.

 > > Perhaps what they'd like are C functions for more
> > easily integrating PySDL
> > into a C SDL program, so they can use it for
> > scripting?
> I bet this would be popular with the regular C SDL
> people.  It seems like it would make PySDL useful for
> a wider range of things, would it also make it easier
> to write a program and then migrate code from Python
> to C?

It should, since you could theoretically still write large portions of the
program in Python, and the speed critical portions in C.
I think the majority of what is needed are more type 'wrappers' like MSurface,
which don't deallocate the SDL object once the Python use is done, so one can
share them inside of Python and keep track of them in C if need be.
Or simply requiring the use of Py_INCREF/Py_DECREF might be sufficient to
protect the objects one uses directly from C.

This would allow realtime effects on surfaces, while still allowing a game to
be written in Python.
The only problem is it'd require a little namespace pollution. This might be
worth the advantages, though.