pysdl-devel

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

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

On Tue, 25 Jul 2000, David Clark wrote:
> As far as my needs go, I consider pySDL largely feature-complete right
> now. I have a couple of very minor requests as stated below, but I
> would support version 0.0.8 or 0.0.9 becoming 1.0, and future releases
> simply being bugfixes or changes required to keep up with new features
> in the C SDL libraries.

Yes, this seems likely.
 
> As far as future expansion goes, I think it's important to divide the
> issue up into two groups:
> 
> 1) Refining and improving current features: This I support. I'd still
> like to be able to manipulate video surfaces as simple 3-d arrays (as
> in fb[x][y][color], although fb[y][x][color] would be ok too) and I'd
> like a fb.get_type() function, that returns either HWSURFACE or
> SWSURFACE (although mustlock() does pretty much the same thing).

I'm not too sure I understand the color portion of that, but let me address the
other part.

In order to modify the surface we would instead need two new objects per
surface. The first would need to carry a reference to the second, and
implement the sequence methods to acquire the second, and store the index into
it first and second, plus if it's an assignment the new value. The second would
carry a reference to the surface and use the stored index values to compute the
location in the surface.

Each surface would probably want to always keep these objects around, in order
to not need to reallocate them for every access.

The first object would probably want to be expanded from my previous statement,
to include its own reference to the surface object. This would allow it quicker
access for masquerading as a list. This, of course, is optional.

We could switch to x,y based coordinates. I've forgotten my rationalization for
the y, x scheme at this point.

> 2) New, non-SDL features: These are features that the C version of SDL
> doesn't support, such as saving surfaces as files, or drawing
> primitives, such as rectangles, lines and sprite objects. I would
> prefer not to see these features in pySDL. Suppose we implement
> fb.save_png(), and Sam or Mattias release a new version of SDL_image
> with a png save function in it? Which do we choose?

I wouldn't implement saving in PySDL. I don't even much care if SDL_image grows
or not, since I can just provide adaptors for other popular image libraries.
These adapters would simply convert surfaces into whatever format the other
libraries expect, and then the user would be on their own.
Alternatively I could go through the mind numbing process of adding yet another
implementation of file savers for every format known to man to SDL_image.
This just isn't likely, unless I find a brief moment of inspiration for working
on something that should have been standardized a number of years ago.

Something I might consider is after the next major release of glib/gdk/gtk is
writing a SDL backend for gdk. While this provides little in the form of 

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

[David C. <si...@te...>]

As far as my needs go, I consider pySDL largely feature-complete right
now. I have a couple of very minor requests as stated below, but I
would support version 0.0.8 or 0.0.9 becoming 1.0, and future releases
simply being bugfixes or changes required to keep up with new features
in the C SDL libraries.

As far as future expansion goes, I think it's important to divide the
issue up into two groups:

1) Refining and improving current features: This I support. I'd still
like to be able to manipulate video surfaces as simple 3-d arrays (as
in fb[x][y][color], although fb[y][x][color] would be ok too) and I'd
like a fb.get_type() function, that returns either HWSURFACE or
SWSURFACE (although mustlock() does pretty much the same thing).

2) New, non-SDL features: These are features that the C version of SDL
doesn't support, such as saving surfaces as files, or drawing
primitives, such as rectangles, lines and sprite objects. I would
prefer not to see these features in pySDL. Suppose we implement
fb.save_png(), and Sam or Mattias release a new version of SDL_image
with a png save function in it? Which do we choose?

I'm not saying that a sprite class or sound file saving wouldn't be
useful; my current project would benefit greatly from a
free_scrolling_tile_based_hex_map class :) I'd just like to see pySDL
remain a tightly-focused, elegant and _limited_ project,
incorportating new features as they become part of SDL and its
accompanying libraries. If we want new features (such as save_png()),
perhaps we should advocate them to Sam first, so they can be placed in
the C project, then wrapped in pySDL.

Thanks for listening.

-- 
David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

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.

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

[Peter N. <pn...@ya...>]

--- Mark Baker <mb...@0x...> wrote:
> PySDL is at the point where I'm not certain where
> its users would like it to
> further develop. This is in part why the releases
> have slowed, since I'm often
> second-guessing future design plans.
> 
> 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.

> 
> 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'.

 adding
> adaptors for PIL and PST,

The Pythonware stuff seems useful, maybe it's too bad
that the cool PIL extensions will not be free. It
would be awesome be able to use the video capture
stuff with PySDL. Still, if it's available why not use
it.

> creating an overly complex system for 'compiling'
> surface operations for speed,
> and some other things.

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. 

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

> Perhaps what they'd like is an add-on framework they
> can use the develop
> software in Python, using PySDL, so everyone using
> PySDL doesn't need to
> implement the same engine 1,000 times?

This is an idea that I have thought about, like a sort
of mini-Director program written in Python.  I don't
really like the way Director does it, but something
simpler and more flexible could be great.

I'm still kind of curious about the possibility of
PySDL as a web-plugin.  There used to be some Python
Netscape plugin things going but I think those have
been abandoned.  There is a way to run Python in
restricted mode for security, and there could maybe be
built-in limits on screen size and memory usage. 
(Although I have now seen a few shockwave movies that
unabashedly go fullscreen.) Just an idea, but with
networking it could be a lot of fun.   --Peter

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

Re: [Pysdl-devel] Record?

[Bill E. <bi...@rf...>]

Sorry, I didn't see your post before my earlier private
response.

There's a cross-platform wxWindows recording facility at

http://www.cs.cmu.edu/~music/audacity/

supporting Win/Mac/Linux/BeOS.

Do you think the input sections could be lifted
as an extra companion library for SDL/pySDL (or
as a kind of side-related plug-in only for pySDL?)

I'm happy to try hacking through the conversion
if someone can give some clues on how I would
go about doing it.

Bill

Mark Baker wrote:
> 
> On Tue, 25 Jul 2000, Bill Eldridge wrote:
> > Did I miss something, or is SDL/pySDL play-only
> > for audio?
> 
> Just to follow up a bit on what David Clark mentioned...
> 
> SDL seems to take the stance of "read only" media handling. The exception is
> the function for outputting bitmaps to a file. Needless to say, that's not all
> that useful.
> It also lacks a means for taking input from alternative sources, as David Clark
> mentioned.
> 
> I am not opposed to PySDL providing recording abilities for audio, images, or
> any other form of data. The functionality would need to exist in the SDL
> companion libraries such as SDL_mixer (or the audio subsystem of SDL) and
> SDL_image.
> Alternatively, PySDL could offer interoperability with Python modules that
> allow for saving audio and image data. Modules like PIL and PST could have
> optional adaptor functions/classes.
> 
> PySDL itself will not implement audio input functionality, but it may in the
> end provide access to this functionality through a library. This is simply
> because such basic functionality should be implemented in a means that it can
> be used by everyone, and not require PySDL so they can record wavs or mp3s in a
> C SDL program.
> 
> Part of the problem of SDL's companion libraries, is that they offer very
> little compared to existing frameworks. The problem with existing frameworks,
> is they're often too dependent on themselves. Libraries like Imlib provide much
> more functionality than say SDL_image, but it's also very dependent on X,
> making it useless elsewhere.  gdk-pixbuf suffers from a similar fate in regards
> to GDK, but at least GDK is easily retargetable, so in theory one could write a
> GDK/SDL backend (and actually run GTK/SDL on any platform SDL runs on...), and
> have something semi-usable.
> Or you can go about reimplementing the same functionality in yet another
> framework, bringing SDL_mixer and SDL_image up to date with good software
> packages..
> 
> Even after all of these decades, everyone is still not adopting the principles
> of reuse, often times in the name of performance for a given task. It almost
> boggles the mind.
> 
> _______________________________________________
> PySDL-devel mailing list
> PyS...@li...
> http://lists.sourceforge.net/mailman/listinfo/pysdl-devel

--
Bill Eldridge
Radio Free Asia
bi...@rf...

[Pysdl-devel] Further development...

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

PySDL is at the point where I'm not certain where its users would like it to
further develop. This is in part why the releases have slowed, since I'm often
second-guessing future design plans.

So what I'm looking for, is ideas as to what people want from PySDL, that it
doesn't currently provide.

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.

The first idea isn't such a terrible one, but I've yet to find a need for it,
or hear of anyone that needs such an ability.

The second idea seems like a somewhat practical way for people to save modified
data to various file formats.

The third idea seems less and less practical as time goes on, since I'm still
not convinced that Python will ever be the proper environment for complex
realtime effect generation, or if it will, that the complexity belongs within a
support module.

As you can see, these don't really account for much of what might be practical
for PySDL users. Do they care about saving screen shots in JPEG, or whether
PySDL offers a mini-compiler/interpreter for surface operations?
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?
Perhaps what they'd like is an add-on framework they can use the develop
software in Python, using PySDL, so everyone using PySDL doesn't need to
implement the same engine 1,000 times?

I don't know. So I'm asking. What is it you want?

I'd also like to note that Pete Shinners sent me a more modularized PySDL code
base a number of days ago. I'm still contemplating whether I like the layout,
but it seems to be a clean break up. I might be able to use some macros and
other evil C tricks to reduce some of the namespace pollution, but this might
not be worth the evil involved.
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. ;-)

Re: [Pysdl-devel] Record?

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

On Tue, 25 Jul 2000, Bill Eldridge wrote:
> Did I miss something, or is SDL/pySDL play-only
> for audio?

Just to follow up a bit on what David Clark mentioned...

SDL seems to take the stance of "read only" media handling. The exception is
the function for outputting bitmaps to a file. Needless to say, that's not all
that useful.
It also lacks a means for taking input from alternative sources, as David Clark
mentioned.

I am not opposed to PySDL providing recording abilities for audio, images, or
any other form of data. The functionality would need to exist in the SDL
companion libraries such as SDL_mixer (or the audio subsystem of SDL) and
SDL_image.
Alternatively, PySDL could offer interoperability with Python modules that
allow for saving audio and image data. Modules like PIL and PST could have
optional adaptor functions/classes.

PySDL itself will not implement audio input functionality, but it may in the
end provide access to this functionality through a library. This is simply
because such basic functionality should be implemented in a means that it can
be used by everyone, and not require PySDL so they can record wavs or mp3s in a
C SDL program.


Part of the problem of SDL's companion libraries, is that they offer very
little compared to existing frameworks. The problem with existing frameworks,
is they're often too dependent on themselves. Libraries like Imlib provide much
more functionality than say SDL_image, but it's also very dependent on X,
making it useless elsewhere.  gdk-pixbuf suffers from a similar fate in regards
to GDK, but at least GDK is easily retargetable, so in theory one could write a
GDK/SDL backend (and actually run GTK/SDL on any platform SDL runs on...), and
have something semi-usable.
Or you can go about reimplementing the same functionality in yet another
framework, bringing SDL_mixer and SDL_image up to date with good software
packages..

Even after all of these decades, everyone is still not adopting the principles
of reuse, often times in the name of performance for a given task. It almost
boggles the mind.

[Pysdl-devel] Record?

[David C. <si...@te...>]

Bill Eldridge writes:
 > 
 > Did I miss something, or is SDL/pySDL play-only
 > for audio?

No, you're correct; SDL and SDL_mixer (on which pySDL's audio support
is based) are read-only. Of course you could always just pipe
/dev/audio to a file, then use SOX to change the resulting .au file to
whatever you need, but that's platform-dependent, and is beyond the
scope of SDL anyway.

Sorry.

-- 
David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

[Pysdl-devel] Record?

[Bill E. <bi...@rf...>]

Did I miss something, or is SDL/pySDL play-only
for audio?
--
Bill Eldridge
Radio Free Asia
bi...@rf...

Re: [Pysdl-devel] framerate feedback request

[Peter N. <pn...@ya...>]

--- Peter Nicolai <pn...@ya...> wrote:
> > Celeron-400, TNT2-Ultra, Win98
> > Hardware =  empty:20.9   full:13.3
> > Software =  empty:19.3   full:13.2

uhh, Win98, Nvidia GeForce SDR
> P3-700/100 (wierd i know) 
> Hardware - 33(empty)-19(full)
> Software - 29(empty)-19(full)


__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

Re: [Pysdl-devel] framerate feedback request

[Peter N. <pn...@ya...>]

> Celeron-400, TNT2-Ultra, Win98
> Hardware =  empty:20.9   full:13.3
> Software =  empty:19.3   full:13.2

P3-700/100 (wierd i know) 
Hardware - 33(empty)-19(full)
Software - 29(empty)-19(full)



__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

[Pysdl-devel] framerate feedback request

[David C. <si...@te...>]

Pete Shinners writes:
 > 
 > here's my stats, just to share
 > 
 > Celeron-400, TNT2-Ultra, Win98
 > Hardware =  empty:20.9   full:13.3
 > Software =  empty:19.3   full:13.2
 > 

Celeron -466 o/c 525, Voodoo3, XWindow 3.3.6

Hardware = empty: n/a    full: n/a
Software = empty: 24.8   full: 10.3

-- 
David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

[Pysdl-devel] framerate feedback request

[Pete S. <pe...@sh...>]

i'm getting the groundwork for my little game laid, and i'm
at the point where i'd like to see what the performance is
like for different people with different machines and OS's

here is the link to my .ZIP file. unzip the contents, but
be sure to maintain the miniature directory structure 
from inside.

http://people.we.mediaone.net/shredwheat/scct.zip


one you're ready to go, run the file "pretest3.py"
this will run the psuedo-demo and report the FPS
every 10 frames...

you are free to look at the code. currently it is
really messy, and far from optimized. i'm still in the
"just do it" planning stages, so i've been trying many
different things and code has been moving around
frequently. 

one file that may be of interest to the outside world
is the "eventhandler.py" this creates a simple class
that calls a member method with the same name as any
sdl events you pass to EventHandler.handle()
(you can see an example on how to use it in pretest3.py)
anyways, this is a pretty nifty class to have around,
and i tried to make the code for this as clean and
documented as can be for now.


anyways, my main concern is to make sure that all the
different platforms are running in the same performance
ballpark. if you can try this out, and report your results
i'd be really greatful.

(also, try switching the SWSURFACE to HWSURFACE on line 12
 to see if there's any difference)

here's my stats, just to share

Celeron-400, TNT2-Ultra, Win98
Hardware =  empty:20.9   full:13.3
Software =  empty:19.3   full:13.2


(also, some of the gfx are temporarily 'borrowed', so i
wouldn't recommend using them for yourself too much)

Re: [Pysdl-devel] Subsystem init crash?

[Pete S. <pe...@vi...>]

> Perhaps a 'fill' method is in order, which takes just a color
> and fills the entire surface?

the other option is to allow fill_rect to take "None" as an
argument for the rectangle. this closely parallels SDL's
ability to take "NULL" for the rectangle

of course, i'm not sure if duplicating a "C-style" interface
is going to take the most advantage of the python language.

Re: [Pysdl-devel] Subsystem init crash?

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

On Fri, 14 Jul 2000, David Clark wrote:
> While revising my documentation, I notice the following items:
> 1) The following code produces a segfault under 0.0.7 (and maybe earlier
> versions:

There's a race condition in the Surface object's destructor.

SDL uses global variables for its 'display' management. This is one of the
reasons you'll not see SDL providing access to multiple displays at once
anytime in the near future.
But more on point is the fact that when you call SDL_FreeSurface on the
'display,' the function checks whether it's the display surface or not. If it
is, it returns without freeing the surface.
What ends up happening is PySDL calls SDL_FreeSurface on a already freed
'display' surface.

To remedy this, I've added a second pseudo-class called "MSurface."
Its destructor doesn't attempt to free the surface when called, so this sort of
thing is impossible. For all other purposes, 'MSurface' is the same as
'Surface,' so it shouldn't be considered different than a Surface.

I've also fixed a memory leak in video_set_mode, pertaining to reinitializing
the TTF library.


> 2) I noticed there's no way to pass the fill_rect() function a NULL 
> rect like there is in SDL_FillRect() or update_rect(). Could we have
> surface.fill_rect((0,0,0,0), somecolor) fill the surface with color?

I've actually been thinking about making (0, 0, 0, 0) the default for
update_rect(), so people wouldn't need to provide the tuple.

'fill_rect' is a bit of a problem, in that it's not as easy to apply the
default argument to it. Perhaps a better calling convention would have been
(color, rect), but it's a bit late to change it now.

Perhaps a 'fill' method is in order, which takes just a color and fills the
entire surface?

[Pysdl-devel] Subsystem init crash?

[David C. <si...@te...>]

While revising my documentation, I notice the following items:
1) The following code produces a segfault under 0.0.7 (and maybe earlier
versions:

<CODE>

import sdl

sdl.init(sdl.INIT_VIDEO)
fb = sdl.video_set_mode(200,200,16, sdl.SWSURFACE)
sdl.quit_subsystem(sdl.INIT_VIDEO)

sdl.init(sdl.INIT_VIDEO)
fb = sdl.video_set_mode(200,200,16, sdl.SWSURFACE)

</CODE>

2) I noticed there's no way to pass the fill_rect() function a NULL
rect like there is in SDL_FillRect() or update_rect(). Could we have
surface.fill_rect((0,0,0,0), somecolor) fill the surface with color?

David Clark
si...@te...
Preliminary pySDL documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

Re: [Pysdl-devel] pySDL 0.0.7

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

On Tue, 11 Jul 2000, David Clark wrote:
> Would you consider giving me DocManager Admin rights? Perhaps my
> documentation could find a permanent home on the project page as well.

Done. I thought I'd given you full access originally, but apparently I'd not
given you a status in regards to the documentation management.

Re: [Pysdl-devel] pySDL 0.0.7

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

On Tue, 11 Jul 2000, David Clark wrote:
> As usual, rpms for the new pysdl release are available from:
> 
> http://www3.telus.net/futility/futility/warez/pysdl-0.0.7-1.i386.rpm
> http://www3.telus.net/futility/futility/warez/pysdl-0.0.7-1.src.rpm

You can add these to the SourceForge project page, if you'd like. I added you
to the project 'bout a month ago, and apparently forgot to inform you.

[Pysdl-devel] pySDL 0.0.7

[David C. <si...@te...>]

As usual, rpms for the new pysdl release are available from:

http://www3.telus.net/futility/futility/warez/pysdl-0.0.7-1.i386.rpm
http://www3.telus.net/futility/futility/warez/pysdl-0.0.7-1.src.rpm

Incidently, several people have mailed me asking about the status of
my documentation. I'm still fully committed to working on the
documentation and will be incorporating Mark's latest version starting
tonight. If you're looking for more information than I have available,
the following resources may be of help:

SDL Documentation project:

http://sdldoc.sourceforge.net/

The archives of the SDL mailing list:

http://www.lokigames.com/ml/sdl/

and the #sdl irc channel, where I can be found as Futility:

irc.sourceforge.net

-- 
David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

Re: [Pysdl-devel] pysdl 0.0.7 fixes...

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

On Mon, 10 Jul 2000, Pete Shinners wrote:
> i had to make the following changes to pysdl to get it working
> on windows.

I simply used a compiler flag to do this.

 
> also, the research i did when first testing pysdl on windows
> has been missing. the currentl pysdl cannot load images under
> win98. replace the rw_NEW function with this, and images load
> fine

Because, as I told you months ago, it is not necessary. It has never been
present and the releases have always worked. If you are experiencing problems,
then I surmise it lies elsewhere. Anyone that has been using my binary
snapshots and has used Dave's PyAliens on Win32 can testify to image loading
working.

[Pysdl-devel] pysdl 0.0.7 fixes...

[Pete S. <pe...@sh...>]

i had to make the following changes to pysdl to get it working
on windows.


before the initsdl function (line 71) i had to add the following
three lines...
#ifdef WIN32
_declspec(dllexport)
#endif


also, the research i did when first testing pysdl on windows
has been missing. the currentl pysdl cannot load images under
win98. replace the rw_NEW function with this, and images load
fine


static RW_Object* rw_NEW(PyObject* src_obj, char* mode)
{
 RW_Object* rw_ref;

 if(!src_obj)
  return NULL;

 if(PyString_Check(src_obj))
  return rw_NEW(PyFile_FromString(PyString_AsString(src_obj), mode), NULL);

 rw_ref = (RW_Object*)Py_Malloc(sizeof(RW_Object));
 if(!rw_ref)
  return NULL;

 Py_INCREF(src_obj);
 rw_ref->obj = src_obj;

#ifndef WIN32
 if(PyFile_Check(src_obj))
 {
  SDL_RWops* ops_ref = SDL_RWFromFP(PyFile_AsFile(src_obj), 0);
  memcpy(&rw_ref->rw, ops_ref, sizeof(SDL_RWops));
  Py_Free((char*)ops_ref);

  rw_ref->seek = NULL;
  rw_ref->tell = NULL;
  rw_ref->read = NULL;
  rw_ref->write = NULL;
  rw_ref->close = NULL;

  return rw_ref;
 }
#endif

 rw_ref->seek = PyObject_GetAttrString(src_obj, "seek");
 rw_ref->tell = PyObject_GetAttrString(src_obj, "tell");
 rw_ref->read = PyObject_GetAttrString(src_obj, "read");
 rw_ref->write = PyObject_GetAttrString(src_obj, "write");
 rw_ref->close = PyObject_GetAttrString(src_obj, "close");

 rw_ref->rw.seek = rw_seek;
 rw_ref->rw.read = rw_read;
 rw_ref->rw.write = rw_write;
 rw_ref->rw.close = rw_close;

 PyErr_Clear();

 return rw_ref;
}
#endif

[Pysdl-devel] win32 binaries

[Pete S. <pe...@sh...>]

compiled by Pete (shredwheat) Shinners
on 7-10-2000

i've gone through the WINDOWS compiling
gauntlet. i've got a version of the latest
pysdl 0.0.7 ready to go. this version comes
with all your favorite dependencies.
JPG, PNG, MP3, and others are all available. 

included in the 520K zipfile... 
 PySDL 0.0.7 
 SDL 1.1.4 (latest CVS release) 
 SDL_Image 1.0.9 
 SDL_mixer 1.0.6 
 SDL_ttf 1.2.1 
 freetype 1.3.1 
 SMPEG 0.4.0 
 plus all the pysdl readme and info files 

note that the SDL included is not an official
release, but i've been using 1.1.4 and had no problems. plus 1.1.4 has my patch that cuts
win32 init time in half. 

http://people.we.mediaone.net/shredwheat/PySDL-0.0.7.zip 

someone feel free to pick this up and move it somewhere more official, heh 

[Pysdl-devel] PySDL 0.0.7

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

I just uploaded 0.0.7, which has been a bit overdue, even though the majority
of the work was done several weeks ago.

It brings PySDL more in synch with the current SDL, save the overlay
functionality. If anyone wants this functionality wrapped, I'll do it, I just
didn't see an immediate need.

SDL_ttf's new functionality has been added to PySDL, but I couldn't reproduce
problems of using the new library with an old PySDL. If others still have
problems using PySDL with the latest SDL_ttf, please let me know.

I've yet to compile a Win32 release for this version of PySDL. If releasing
MSVC projects files (especially mine, since I've had to compile support
libraries that have broken build files, so I have them all over the place and
PySDL build files shows this ;-)) wasn't such a nasty hack of a release
mechanism, I'd just release one and not have to worry about it.
Eventually (probably today) I will get around to compiling a Win32 snapshot.

[Pysdl-devel] To do?

[David C. <D. C. <si...@te...>]

As a correction to my list of dependencies for pySDL - the newest
version of SDL_ttf, 1.2.1, breaks pySDL. Trying to initialize the
video subsection results in a fatal error as the new RenderText symbol
cannot be resolved. I've reverted to 1.0.1 until there is a new
version of pySDL.

David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

Re: [Pysdl-devel] pysdl & numpy decision

[Peter N. <pn...@ya...>]

> my instinct is that if surface.pixels[] 'directly'
> operates on a numpy array, then it should be in the
> regular format of a numpy array ([y,x]) even if that
> feels wierd.  

OK now my instinct is do whatever you want however it
feels but just make it so I don't have to transpose
the arrays all the time.  Maybe that's impossible...
anyway here's the gradient thing, not with your numpy
upgrade, but it would be slow anyway, I really don't
know any tricks for speed.  I guess it was a good
exercise for me but really, gradients, how boring. It
does work though -- 30 seconds down to 1.5... whooee.. --P

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/