pysdl-devel

[Pysdl-devel] Announce: pystars-1.0

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

You're probably aware of Nathan Strong's "stars" demo, available
from:

http://www.devolution.com/~slouken/SDL/projects/stars/index.html

Essentially, this program, ported to SDL by Sam Lantinga, displays a
rotating starfield on the screen, adjusting the intensity of each star
to simulate depth. I decided to port this demo to pySDL, because a) it
looked pretty simple and b) it had a fps counter.

Download pystars-1.0 at:

http://www3.telus.net/futility/futility/warez/pystars-1.0.tar.gz

pystars.py will run in windowed mode.
pystarsf.py will run fullscreen.
pystarsf.py -hw will request video memory for faster speed (only works
on win32)

For comparison, here are my benchmarks on a Pentium 525/Voodoo
3/Win95 vs. Xfree 3.3.6 combo at 16 bpp:

X Windows windowed mode:         21.31 fps
X Windows fullscreen mode:       21.32 fps
Win32 windowed mode:             31.38 fps
Win32 fullscreen mode:           33.06 fps
Win32 fullscreen hardware mode:  37.06 fps

Incidently, the C version of stars, running under X windows? 53.00
fps.

Note the program I wrote wasn't optimized for Python or pySDL; I just
wanted as close to a line-by-line port as I could get. There may be
several unnecessary functions in there, especially the
int(math.floor()) crap, but I wanted to get as close to the C program
in structure as I could.

<editorial> Actually, I'm very pleased with this relative
performance. This program uses video.set_at() exclusively, and we know
that individual pixel addressing is pretty slow. Still, to have 40% of
C speed before optimization is pretty impressive!
</editorial>

Enjoy!

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

Re: [Pysdl-devel] greetings, and problems importing sdl

[Preston L. <pla...@pb...>]

Mark Baker writes:

 > You've even two upped me on SDL_image versions ;-)

I uninstalled SDL_image 1.0.6 and installed 1.0.4, recompiled pySDL,
installed it, and still no luck.

 > I'd suggest tracking down and removing any old versions of SDL_image, and
 > perhaps reinstalling it. Not exactly the most elegant advice, I know, but it
 > sounds like there's some crufty library or link somewhere.

Yeah, that was my first thought too.  Unfortunately though this is the
first time I've installed PySDL or SDL_image on this system.  I've
done a find for all versions of either libraries and there is no cruft
laying around.  Unless you have some more ideas for debugging this,
I'll probably have to drop it for a while.

thanks
Preston

Re: [Pysdl-devel] Video surface questions

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

On Wed, 31 May 2000, Mark Baker wrote:
> I've removed INFO_VIDEO from video_info, because it duplicates
> get_depth_bits(), and I doubt anyone has used it. Sorry to toss a monkey wrench
> in your documentation.

Er, INFO_DEPTH. Plus I didn't remove it entirely, in that patch. It just does
nothing, now.

For the release it'll be completely gone.

Re: [Pysdl-devel] Video surface questions

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

On Tue, 30 May 2000, "David Clark wrote:
> A couple of quick questions:
> 
> 1) is there a way to query an existing surface, to find out it's
> colour depth, or should I just use video_info()?

I've added a get_depth() and get_depth_bits() methods to Surface objects.
I have no idea how that one got past me ;-)

I've removed INFO_VIDEO from video_info, because it duplicates
get_depth_bits(), and I doubt anyone has used it. Sorry to toss a monkey wrench
in your documentation.

> 2) is there a way to find out whether an existing surface is in video
> memory or main system memory - in other words, whether my
> sdl.HWSURFACE request is granted or not?

I've added a get_info() method to surface objects. This returns a bitmask
indicating the state of the surface. You can then & the mask with the various
surface creation routines.

For instance:

flags = surface.get_info()
if(flags & sdl.HWSURFACE):
	...

I'll do a release shortly, so whatever you're writing will work out of the box.
If you find you need any other features, let me know.

[Pysdl-devel] Video surface questions

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

A couple of quick questions:

1) is there a way to query an existing surface, to find out it's
colour depth, or should I just use video_info()?

2) is there a way to find out whether an existing surface is in video
memory or main system memory - in other words, whether my
sdl.HWSURFACE request is granted or not?

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

Re: [Pysdl-devel] greetings, and problems importing sdl

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

On Mon, 29 May 2000, Preston Landers wrote:
> Hey there,
> 
> First of all, a big thanks to everyone involved in bringing SDL
> capabilities to Python.  I've downloaded the pysdl-0.0.5 archive and
> I'm trying to get it to run.  I'm running SDL 1.1.2 (all the tests
> run) and I have the all required extensions installed (SDL_image
> 1.0.6, mixer 1.0.5, ttf 1.0.2.).

You've even two upped me on SDL_image versions ;-)

On a related note, I just wrote the TIFF loader for SDL_image, so hopefully as
soon as Sam Lantinga wades through his five miles of e-mail, and finds my
message, SDL_image should finally support TIFF. ;-)

> The output of make:
> 
> planders@sauron:~/src/pysdl/pysdl-0.0.5$ make
> gcc -fPIC  -I/usr/local/include -g -O2 -I/usr/include/python1.5
> -I/usr/include/python1.5 -DHAVE_CONFIG_H -c ./sdlmodule.c
> ./sdlmodule.c: In function `sdl_surface_get_at':
> ../sdlmodule.c:1469: warning: initialization from incompatible pointer type

I've fixed this warning. Not only that, I've finally made the global
sdl.* functions safe. I need to start putting stuff into CVS, so people can
benefit from everything sooner.

> then I go into Python:
> 
> >>> import sdl
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> ImportError: libSDL_image-1.0.so.0: cannot open shared object file: No
> such file or directory

I'd suggest tracking down and removing any old versions of SDL_image, and
perhaps reinstalling it. Not exactly the most elegant advice, I know, but it
sounds like there's some crufty library or link somewhere.

> PS. has anyone experimented with OpenGL stuff from PySDL?

Pete Shinners mentioned having some success with PySDL and the OpenGL python
module.

[Pysdl-devel] greetings, and problems importing sdl

[Preston L. <pla...@pb...>]

Hey there,

First of all, a big thanks to everyone involved in bringing SDL
capabilities to Python.  I've downloaded the pysdl-0.0.5 archive and
I'm trying to get it to run.  I'm running SDL 1.1.2 (all the tests
run) and I have the all required extensions installed (SDL_image
1.0.6, mixer 1.0.5, ttf 1.0.2.).

The output of make:

planders@sauron:~/src/pysdl/pysdl-0.0.5$ make
gcc -fPIC  -I/usr/local/include -g -O2 -I/usr/include/python1.5
-I/usr/include/python1.5 -DHAVE_CONFIG_H -c ./sdlmodule.c
./sdlmodule.c: In function `sdl_surface_get_at':
./sdlmodule.c:1469: warning: initialization from incompatible pointer type
gcc -shared -lc  sdlmodule.o  -lSDL -lSDL_image -lSDL_mixer -lSDL_ttf -o sdlmodule.so

the I 'sudo make install' and it copies the sdlmodule.so to
/usr/lib/python1.5/site-packages (which is in my Python search path.)

then I go into Python:

>>> import sdl
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ImportError: libSDL_image-1.0.so.0: cannot open shared object file: No
such file or directory

libSDL_image-1.0.so.0 is properly linked:

planders@sauron:~/src$ ldd /usr/local/lib/libSDL_image-1.0.so.0
		       libSDL-1.1.so.0 =>
/usr/local/lib/libSDL-1.1.so.0 (0x4001a000)
			       libpthread.so.0 => /lib/libpthread.so.0
(0x400a8000)
	libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x400bb000)
	libpng.so.2 => /usr/lib/libpng.so.2 (0x400dc000)
	libz.so.1 => /usr/lib/libz.so.1 (0x40103000)
	libc.so.6 => /lib/libc.so.6 (0x40112000)
	libesd.so.0 => /usr/lib/libesd.so.0 (0x401ef000)
	libaudiofile.so.0 => /usr/lib/libaudiofile.so.0 (0x401f6000)
	libm.so.6 => /lib/libm.so.6 (0x40209000)
	libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40227000)
	libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x402c8000)
	libdl.so.2 => /lib/libdl.so.2 (0x402d4000)
	/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000)

And /usr/local/lib is in /etc/ld.so.conf.  (By the way, this is Debian
2.2 (potato)).

Any ideas on this one?  

thanks in advance,

Preston Landers

PS. has anyone experimented with OpenGL stuff from PySDL?

[Pysdl-devel] Docs update

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

I've made the following updates at my documentation page:

- RPMs and SRPMS for pySDL-0.0.5. Incidentaly, Mark, if these meet
your standards, you can just post them on Sourceforge - I don't know
whether people find the bandwidth to my pages adequate or not.

- Updated documentation to deal with the SDL_ttf features. This is
very slick indeed, Mark. Thanks! Note that this is all under the Video
subsection, and there is a new example, showing an interface to the
font functions.

- Updated installation instructions for 0.0.5, including win32
installation.


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

Re: [Pysdl-devel] PySDL 0.0.5

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

On Thu, 25 May 2000, "David Clark wrote:
> :) That got it. Just to be clear, Setup and Setup.in _both_ have to be
> updated, right? That's what I did, and it works fine.

Setup.in is used to generate Setup and all of the other files. If Setup has
already been generated, then modifying it should pretty much do it.

The current archive has been fixed, so the amount of damage done should be
minimal.

Re: [Pysdl-devel] PySDL 0.0.5

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

:) That got it. Just to be clear, Setup and Setup.in _both_ have to be
updated, right? That's what I did, and it works fine.

So everyone knows, I'm still away until May 28; I won't be able to
start documenting the new stuff until then :(


Mark Baker writes:
 > On Thu, 25 May 2000, "David Clark wrote:
 > > Mark Baker writes:
 > > The module builds ok, and 'make install' installs it, but when
 > > importing it, I get the following error:
 > > 
 > > >>> import sdl
 > > Traceback (innermost last):
 > >   File "<stdin>", line 1, in ?
 > > ImportError: /usr/lib/python1.5/site-packages/sdlmodule.so: undefined symbol: TTF_OpenFont
 > 
 > Haha. I forgot to copy the new Setup.in into the directory, when I made the
 > release. Add -lSDL_ttf, and all should be well. I really need to learn to check
 > to make sure these things work, eh? ;-)
 > 
 
David Clark
si...@te...
Preliminary pySDL documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

Re: [Pysdl-devel] PySDL 0.0.5

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

On Thu, 25 May 2000, "David Clark wrote:
> Mark Baker writes:
> The module builds ok, and 'make install' installs it, but when
> importing it, I get the following error:
> 
> >>> import sdl
> Traceback (innermost last):
>   File "<stdin>", line 1, in ?
> ImportError: /usr/lib/python1.5/site-packages/sdlmodule.so: undefined symbol: TTF_OpenFont

Haha. I forgot to copy the new Setup.in into the directory, when I made the
release. Add -lSDL_ttf, and all should be well. I really need to learn to check
to make sure these things work, eh? ;-)

[Pysdl-devel] PySDL 0.0.5

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

Mark Baker writes:
 > I just put the source for 0.0.5 up on SourceForge. The only new functionality
 > is support for SDL_ttf, and Pete Shinner's addition of get_error(). The rest of
 > this release was getting it to work on Win32.

Woohoo!!

 > I'm going to recompile my Win32 binaries for the SDL_* DLLs and PySDL, and then
 > make them available for public consumption.

At the 'make' step, I get the following output:

gcc -fPIC  -I/usr/local/include -g -O2 -I/usr/include/python1.5 -I/usr/include/python1.5 -DHAVE_CONFIG_H -c ./sdlmodule.c
./sdlmodule.c: In function `sdl_surface_get_at':
./sdlmodule.c:1469: warning: initialization from incompatible pointer type
gcc -shared  sdlmodule.o  -lSDL -lSDL_image -lSDL_mixer -o sdlmodule.so

The module builds ok, and 'make install' installs it, but when
importing it, I get the following error:

>>> import sdl
Traceback (innermost last):
  File "<stdin>", line 1, in ?
ImportError: /usr/lib/python1.5/site-packages/sdlmodule.so: undefined symbol: TTF_OpenFont


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

[Pysdl-devel] PySDL 0.0.5

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

I just put the source for 0.0.5 up on SourceForge. The only new functionality
is support for SDL_ttf, and Pete Shinner's addition of get_error(). The rest of
this release was getting it to work on Win32.

I'm going to recompile my Win32 binaries for the SDL_* DLLs and PySDL, and then
make them available for public consumption.

[Pysdl-devel] win32, pysdl, and pypanda!

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

tonight i broke through and got all the file stuff working
perfect with win32 pySDL. my first test? of course i was eager
to see pypanda working.

chalk one up for cross platform excellence. pypanda 0.4 ran
flawless without any changes. i know binary attachments aren't
the friend of everyone, but i jpeg'd the hack out of a screenshot.


i've submitted the changes to mark, so hopefully all will be
incorporated in the next pySDL 0.0.5 release.


btw david clark.
there is a strange bug/feature with the current pypanda.
the code to initialize the graphics "display = create_display()"
is inside the "while 1" loop. on win32 everytime you restart
the feed the window moves to the center of the screen. i'm 
not sure what linux does when the graphics system is restarted.
i'm guessing nothing happens so this went uncaught?
moving this line before the while 1 loop seems to clean
everything up nicely.

again, sorry if the attachment kills anyone, it's under 10K, so
it shouldn't really punish anyone's slow connections (?)

Re: [Pysdl-devel] Win32 etc.

[Linda B. <ho...@to...>]

On Wednesday, May 17, 2000 Peter Nicolai wrote:

>You won't see a lot of posts from me since I'm a total
>beginning programmer, but I wanted to share a few
>thoughts that relate to porting pySDL to other
>platforms (as in why bother) as well as to public
>interest in pySDL.


These are always welcome. Though the list is concerned with PySDL
development, you needn't be an active developer to impact its development.
There's certainly more to program design than code.

>Python is available on more platforms than SDL.  If
>pySDL could magically work with any flavor of Python,
>that would allow for write-once, run-anywhere SDL
>applications.  Maybe even through a Netscape plugin?


If PySDL were to be used in conjunction with a Netscape plug-in, it would be
desireable to abstract the access of the plug-in's downloadable code to a
smaller subset of functionality. For various security reasons, and for the
sanity of the designer. Still, it's quite possible.
Who knows, perhaps a subset of the higher level interface for PySDL could be
used, once it's concieved and written. I'll leave the use of PySDL to the
dreamers, as I'm more of an engineering sort.

>It would be a pity if the cross-platform stuff with
>Python turns out to be too troublesome.  I thought
>this was part of the point.


I think it may just be a matter of what happens to be compiled, by default,
with the various binary releases. I'ven't yet, though am currently in the
process of starting to, explored the problems one might find with using
PySDL on non-Unix platforms.

It is my hope to keep the number of instances of #ifdef WIN32 to a minimal
in PySDL's source code, since the platform issues really belong in Python
and SDL.

[Pysdl-devel] Win32 etc.

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

Peter Nicolai writes:
 > Hi,
 > 
 > You won't see a lot of posts from me since I'm a total
 > beginning programmer, but I wanted to share a few
 > thoughts that relate to porting pySDL to other
 > platforms (as in why bother) as well as to public
 > interest in pySDL.  

No problem; we need ideas as well as code. Besides, us coder wannabes
have to stick together :)

 > <snip stuff about pySDL internet browser plugins>

This is an interesting idea. Two problems I see:
1) pySDL can put the client computer into an unusable state very
easily by changing video modes or creating surfaces at a vast rate -
see the code fragment I posted earlier this week. A pretty clear
security.
2) pySDL's biggest drawback right now (IMHO) is its rather byzantine
install process. I've tried to document the install process here:
http://www3.telus.net/futility/futility/docs/pysdl/index.html#inst
and here:
http://www3.telus.net/futility/futility/docs/pysdl/rhinstall.html
but as you can see, it's not trivial. Consider that these instructions
are just for one platform; asking someone to download, configure and
install all these interdependent packages before they can view a
plugin is a lot to ask. Consider also that new dependencies will be
added with font support. Now I hear that SDL_image doesn't have JPEG
support by default in win32; I have a feeling we're just seeing the
beginning of the complexity involved here.

 > 
 > It would be a pity if the cross-platform stuff with
 > Python turns out to be too troublesome.  I thought
 > this was part of the point.  

I'm confident that the cross-platform issues will be worked out
eventually. We have some good people on the case here, and since both
Python and SDL are reliably cross-platform already, the outlook looks
bright. I agree that this is a very important goal for the project;
next week I'll be confined to Windows, and won't be able to work on
pySDL at all :(
 
-- 
David Clark
si...@te...
Preliminary pySDL Documentation:
http://www3.telus.net/futility/futility/docs/pysdl/index.html

[Pysdl-devel] Announce: pyPanda 0.4

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

Announcing pyPanda 0.4, with the following features:

 - an adorable icon (if I do say so myself).
 - a "Cam unavailable" feature that _actually works_
 - 35% more spaghetti code!

Incidently, if anyone is annoyed by these announcements, please let me
know, and I'll refrain. 

pyPanda 0.4 :
http://www3.telus.net/futility/futility/warez/pypanda-0.4.tar.gz

pyPanda home page :
http://www3.telus.net/futility/futility/software.html
(at the bottom)

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

[Pysdl-devel] Win32 etc.

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

Hi,

You won't see a lot of posts from me since I'm a total
beginning programmer, but I wanted to share a few
thoughts that relate to porting pySDL to other
platforms (as in why bother) as well as to public
interest in pySDL.  

Python is available on more platforms than SDL.  If
pySDL could magically work with any flavor of Python,
that would allow for write-once, run-anywhere SDL
applications.  Maybe even through a Netscape plugin? 
There's a Python-based VR project called "Alice" that
just packs up .py scripts, models, bitmaps and sounds
into a file and sends it to a plugin on your browser. 
It's only for Windows but you get the idea. It's at
www.alice.org

Also the ability to test out code right away using the
interpreter could allow for a pretty nice, simple
authoring environment for SDL apps, maybe analoguous
to Director but hopefully more elegant and flexible. 
I guess the problem with tools is that they limit you
but if it's all open source you could choose how you
wish to be limited.  Plus there could be a fun
community of people working on and sharing plugins and
modules, where with Director's Xtras it's all about
people trying to sell them to each other.

It would be a pity if the cross-platform stuff with
Python turns out to be too troublesome.  I thought
this was part of the point.  

Anyway, sorry about the dummy post and thank you for
all your work.  I'm learning C but naturally Python
would be nicer for me right now --Peter

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

Re: [Pysdl-devel] win32 progress

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

On Wed, 17 May 2000, Pete Shinners wrote:
> python is dumping in the calls sdl_image_load and sdl_sound_load.
> i've been spending my time attacking the sdl_image_load, but it
> seems curious that the same problem exists in sdl_sound_load.

> things are crashing on the meat and potatos line of sdl_image_load
> in sdlmodule.c:
> 
> surface_ref = sdl_surface_NEW(IMG_Load_RW((SDL_RWops*)ops_ref, 0));

You should compile everything with debugging on, and find exactly where it's
having issues. It's likely to be in IMG_Load_RW, either because of something to
do with the ops_ref, or some broken aspect of SDL_image. Perhaps rw_NEW() is
returning NULL for some reason, and then IMG_Load_RW isn't behaving. You might
want to consider testing ops_ref for NULL.

Other than that, without more detailed information regarding where it's
croaking, it's hard to say.

[Pysdl-devel] win32 progress

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

for all who care about how my win32 porting progress is going...

my job tonight was to get the video system initializing.
i knew there was some extra work to do as pysdl started up
on WIN32. a little tip from mbaker got me moving in the right
direction and the good news is the video system now works great!

i did some experimenting with a window and some fun with
surface.fill_rect(). all seems to be working as expected.


sadly, it's not all good news, and here's where i again look
for a little direction from you who might know more about such
things...


python is dumping in the calls sdl_image_load and sdl_sound_load.
i've been spending my time attacking the sdl_image_load, but it
seems curious that the same problem exists in sdl_sound_load.

<lament>
i was hopeful for the starfield example, since it requires
no image library. ALAS, the win32 python binary doesn't come
with the "rand" module compiled in. this'll be a project for
tomorrow night.
</lament>

anyways, i ran it through the standard gauntlet of testing.
i tried both BMP and GIF. (i tried JPG too, only to discover
JPG doesn't come standard with SDL_Image for win32, urg)
i also tried passing in a filename, and a opened binary file
handle. same results with both.

things are crashing on the meat and potatos line of sdl_image_load
in sdlmodule.c:

surface_ref = sdl_surface_NEW(IMG_Load_RW((SDL_RWops*)ops_ref, 0));

to be truthfull, i haven't gotten much further than this, but i'm
highly suspect of the RW object right now. i can see this is an
SDL thing. a wrapper around the usual <stdio.h> methods. i nice way
to make things flexible.

the bottom line of all this, is i'm hoping a lightbulb is flashing
over someone's head right now, and they have a good hunch of what
the problem is. it'll save me a bit of time as i dig in tomorrow
evening. share!



it will be a good day when i get a live feed of pandas on
my win32 desktop! thanks to all those that've helped me get
this far.

[Pysdl-devel] Announce: pyPanda-0.2

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

I'm pleased to announce Version 0.2 of pyPanda, my first real pySDL
application. pyPanda allows you to view the streaming video from the
San Diego Zoo Panda Cam on your desktop, and should work on any
platform for which pySDL can be compiled (right now, that means linux
:)

Version 0.2 is feature-complete. Feedback is appreciated. Please see
the included README file for instructions.

pyPanda-0.2 is available from:

http://www3.telus.net/futility/futility/warez/pypanda-0.2.tar.gz

A screenshot is available from:

http://www3.telus.net/futility/futility/software.html

near the bottom of the page. Enjoy!

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

Re: [Pysdl-devel] win32 porting

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

On Tue, 16 May 2000, "David Clark wrote:
>  > anyways, i'm wondering how things are looking for PySDL?
>  > personally i'm quite excited about it, and am surprised there
>  > is so little interest.
> 
> It hasn't been aggressively advertised, either on the SDL mailing list
> or on comp.lang.python. Actually, as far as I know, it hasn't even
> been _mentioned_ on either :) I haven't talked to Mark about this, but
> my guess is he'd like to get the module to a pretty-much-completed
> state before opening the floodgates. This is fine with me :)

It was mentioned once by Sam Lantinga, but other than that I'ven't aggressively
advertised new versions on any mailing list other than this one.
It has been good to keep the user base fairly small, as it has kept the amount
of mail complaining about any incompatabilities down to zero, which
is always pleasent. Pissing off people that only want to get some work done,
because you've suddenly had a change in artistic vision, is silly.

Re: [Pysdl-devel] win32 porting

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

On Tue, 16 May 2000, Pete Shinners wrote:
> most noticeably the video system. i've traced it back to
> problems creating the window. it appears SDL uses argv[0]
> as the classname for the window class. right now this is
> NULL when running under python. i'm pretty sure that's the
> problem. strangely i can't seem to fix this with simple
> changes to the SDL code.   hmmmm..

This seems a somewhat odd, if you think about it.
I'll look into it, I just need to secure access to a win32 machine.

 
> anyways, i'm wondering how things are looking for PySDL?
> personally i'm quite excited about it, and am surprised there
> is so little interest.

Things are looking fine, in my opinion. There is relatively little interest,
for probably a number of reasons. Generally speaking, game programmers (at
least novices) are more fixated with framerates than development time. Then
there's the rather fringe nature of Python, in comparison to languages like
Perl or Visual BASIC. Then there's the fact that PySDL is a relatively new
project, and while being a now mostly complete wrapper for the various low
level SDL functions and objects, it's still fairly complex in terms of use for
any sort of serious project.

I'll make another minor release, very soon, that just adds font support, and
then the brainstorming for the higher level interfaces will need to begin.
We'll want an execute buffer type mechanism for speed, and a series of higher
level primitives for composing games and the like.


 
> also, has anyone gotten any work from the project owner, "mbaker"
> ?? is the guy dead?? what's happening with PySDL?

Well, I'd like to think that I'm alive.
Anyway, you personally have gotten quite a bit of work from me. ;-)

Re: [Pysdl-devel] Request for feature :)

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

On Sun, 14 May 2000, "David Clark wrote:
> In writing my little app, I've run up against a bit of a issue - I
> don't know if it's appropriate for inclusion in pySDL or not.
> 
> I check the event queue a couple of times per second with
> events_poll(). I'm really only interested in the event that's
> occurring at the moment of the poll, but I'm finding that (for
> example) a quick mouse motion across the window is filling up the
> queue with many events, each of which has to be grabbed from the queue
> sequentially. As a result, a mouse motion and then a click may take
> ten seconds to register with my program, as I poll() myself through
> the queue.

Perhaps you might be more interested in the various state functions for the
event system. Or maybe events_get, which takes an event type as an argument.
In general polling isn't the most efficient way of handling event dispatch, I
just used it in the various sample applications because they didn't require
anything more complex.

If you need further information or examples, I'll be more than happy to throw
something together for you and everyone else.

Re: [Pysdl-devel] PySDL, excellent! (other bindings)

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

> pysdl is looking great! this weekend i will start really
> playing with it.
>
>
> i'm wondering how much support there is for some
> of the other libraries that work well with SDL.
>
> specifically i'm interested in running PyOpenGL

I have not yet gotten around to using the Python OpenGL module with PySDL, but
it is my hope that it will work. 

If you're looking to use PySDL and the OpenGL module together, I would advise
reading the OpenGL section of the SDL tutorial. Use the equivalent PySDL
functions, and see what happens.

I'm sorry I've taken so long to reply, my mother has been rather ill and I've
been dealing with family. Luckily all is well now, and I should be able to get
back to work.