pysdl-devel

Re: [Pysdl-devel] Getting video modes?

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

> Actually I get good information from the regular SDL
> list even though I don't really program in C at all. 
> There are a lot of applicable discussions about how to
> do blitting and updating rectangles, that sort of
> thing. 

peter's right, i spend a lot of time here too. i do know
C programming, but pretty much all the pySDL functions
have a 1-to-1 call for their C function. pySDL is a pretty
thin wrapping, so techniques for the C SDL apply directly
to the python version.


> > Is there any publicly available PySDL applications
> > that I could use to see how others have done things?
> 
> The new version of PyAliens is pretty good for that. 
> It would be nice to have a place for people to upload
> things they've done with PySDL, I'd contribute to
> that.  

currently, all pysdl applications i know of are open
source. the "examples" directory that comes with pysdl
is a bit frightening, and i've currently rewritten most
of those to be simple and elegent (and as a bonus, work
correctly). i'll be releasing that real soon, but for
i'd recommend the cleanedup pyaliens i did, and you can
also see cowtipper by Jeff Clement. I also recommend
David Clark's pyPanda, pyStars, and the direct-from-c-
conversion, pyAliens-1.1

the devel-pysdl archive lost my post?? here is a
temporary home for the cleaner pyAliens:
(note, this wasn't the exact version i put on
the mailing list recently, but it should be close.
i noticed it does print fps to the console as it plays)
http://www.shinners.org/pete/

cowtipper:
http://bluesine.com/archives/software/cowTipper/

david's goodstuff:
http://www3.telus.net/futility/futility/software.html


> This sounds good. I just started using Python 2.0, and
> the old modules don't work with it, including pysdl. So
> far I use 1.52 for the development of the parts that use
> pysdl, and 2.0 for the parts that rely on the new XML
> handling. It would be nice if there would be a Python 2.0
> version of pysdl some day. I have no idea as to how hard
> it is to do the port, but I hope it's not impossible?

well, if anyone's interested, i have a version of my
super-secret, unlreased source-split version of pysdl ready
as a binary release for python 2.0b1 (win32). i've been using
it for my testing and it works quite well. my big grief with
it now is that it's using the latest CVS SDL and the alpha-
slightly-incompatible SDL_image-1.0.9. so all image alphas
are backwards. it's a pain using images with alphas (for now)
but it does work with python2. if anyone wants, i'll post the
binaries.

Re: [Pysdl-devel] Getting video modes?

[Jan E. <ch...@in...>]

On Mon, 11 Sep 2000, Peter Nicolai wrote:

>Actually I get good information from the regular SDL
>list even though I don't really program in C at all. 
>There are a lot of applicable discussions about how to
>do blitting and updating rectangles, that sort of
>thing. 

I have to dig through the archive for that list too when I have some
problems. Thanks for the hint!

>The new version of PyAliens is pretty good for that. 
>It would be nice to have a place for people to upload
>things they've done with PySDL, I'd contribute to
>that.  

Where can I have a look at it? It sounds a bit like the first think I made
with pysdl, namely a simple 'Space Invaders' clone. Great fun to program.
I assume I could find it on Google or Freshmeat, but surfing with 33.6kb
is a lot of antifun.

	Regards, Chakie

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Re: [Pysdl-devel] Getting video modes?

[Jan E. <ch...@in...>]

On Mon, 11 Sep 2000, Pete Shinners wrote:

>this is the best place to come for pysdl help and info.
>(unless i'm seriously missing out on something :] )

Good. Sometimes 'devel'-lists are meant for those developing on a certain
product. Questions from 'users' on those lists are not always welcome.

>sdl.video_list_modes(...) will return 0 if the call to
>SDL_ListModes(...) returns NULL. my guess is that the
>"C" version takes an entire PixelFormat structure, which
>is more information that just bpp. because pysdl video_list_modes
>is not setting the rest of the PixelFormat structure, SDL
>is returning no results.

Ok, because whatever I tried feeding to it the function just returned 0.
Well, I can manage without it, as I just aim for 1024x768 fullscreen or
windowed (togglable by the player). That resolution should be available on
almost any hardware today, and if it isn't I think Python is too slow on
it anyway... :-)

>well jan, i'm guessing you're one of the first person even
>using the video_list_modes. 

Always a pioneer.

>at this point, i'm not sure what's up with Mark Baker (the
>pysdl maintainer) it's been awhile since i've gotten anything
>back from him. if SDL 1.1.5 comes out with no word from Mark
>i'm going to take a stab at updating the pysdl source with all
>the new features. (i'll probably look deeper into this routine
>for you also)

This sounds good. I just started using Python 2.0, and the old modules
don't work with it, including pysdl. So far I use 1.52 for the development
of the parts that use pysdl, and 2.0 for the parts that rely on the new
XML handling. It would be nice if there would be a Python 2.0 version of
pysdl some day. I have no idea as to how hard it is to do the port, but I
hope it's not impossible?

>for now, i'd just hardcode a small list of screen modes for
>your app. just pick the standards, and assume you won't have
>any problems. (likely, you wont)

I need only one resolution, 1024x768. I merely wanted to be able to check
the possibility of using that mode before having pysdl try to initialize
it. Later I think multiple resolutions should be possible, but that is in
a later version. One has to start easy and get something simple that works
and then build upon it.

Thanks a lot for your help!

Btw, I figured out how to use transparency. My png:s have a transaprent
color, so it was just a matter of calling the method set_colorkey() (if I
remember the name correctly), and it all worked ok. 

	Regards, Chakie

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Re: [Pysdl-devel] Getting video modes?

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

> What is the proper forum for discussion about
> applications using PySDL or
> different techniques? I think it would be nice to be
> able to share ideas
> and get some help. I'm not that experienced in
> lowlevel surface handling
> as needed by SDL (and PySDL). Transparency is for
> instance one thing that
> would be nice to learn more about. 

Actually I get good information from the regular SDL
list even though I don't really program in C at all. 
There are a lot of applicable discussions about how to
do blitting and updating rectangles, that sort of
thing. 

> Is there any publicly available PySDL applications
> that I could use to see
> how others have done things?

The new version of PyAliens is pretty good for that. 
It would be nice to have a place for people to upload
things they've done with PySDL, I'd contribute to
that.  

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

Re: [Pysdl-devel] Getting video modes?

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

> I'm having some small problems with PySDL, but I'm not sure this is the
> correct forum. The regular discussion forums at SourceForge seemed a bit
> quiet, so I decided to try this instead.
> 
> Ok, here goes.
> 
> How do I get a proper list of all accepted video modes using PySDL? I just
> want to verify that a specific mode can be used with a certain depth. I
> tried the following code to get some info:

this is the best place to come for pysdl help and info.
(unless i'm seriously missing out on something :] )

sdl.video_list_modes(...) will return 0 if the call to
SDL_ListModes(...) returns NULL. my guess is that the
"C" version takes an entire PixelFormat structure, which
is more information that just bpp. because pysdl video_list_modes
is not setting the rest of the PixelFormat structure, SDL
is returning no results.

ugh, this is one of my beefs with current pysdl, the "C"
versions of the functions are usually a lot more flexible
(taking NULL pointers for default/best argument in many cases,
it would be great if pysdl could take "None" as a substitute.
owell, it will likely happen one day)

well jan, i'm guessing you're one of the first person even
using the video_list_modes. the good news is that SDL does
a really good job of emulating any requested video modes you
ask for (ie, setting a slightly larger resolution and just
using a black border to make up the difference. also handling
bpp differences for you automatically.)
unlike using directx or related libraries, with SDL you can
just request any mode and SDL will likely do it, adjusting
what it needs to automatic, but keeping everything on the
programmer end exactly what you wanted.

at this point, i'm not sure what's up with Mark Baker (the
pysdl maintainer) it's been awhile since i've gotten anything
back from him. if SDL 1.1.5 comes out with no word from Mark
i'm going to take a stab at updating the pysdl source with all
the new features. (i'll probably look deeper into this routine
for you also)

for now, i'd just hardcode a small list of screen modes for
your app. just pick the standards, and assume you won't have
any problems. (likely, you wont)

def fake_list_modes(bpp, flags):
    "substitute this until sdl.video_list_modes is working, sorry"
    return [(0, 0, 640, 680), (0, 0, 600, 800), (0, 0, 1024, 768)]

[Pysdl-devel] Getting video modes?

[Jan E. <ch...@in...>]

Hi there,

I'm having some small problems with PySDL, but I'm not sure this is the
correct forum. The regular discussion forums at SourceForge seemed a bit
quiet, so I decided to try this instead.

Ok, here goes.

How do I get a proper list of all accepted video modes using PySDL? I just
want to verify that a specific mode can be used with a certain depth. I
tried the following code to get some info:

#!/usr/bin/python

import sdl

sdl.init(sdl.INIT_VIDEO)

print sdl.video_list_modes(16, sdl.FULLSCREEN)
print sdl.video_list_modes(0, sdl.SWSURFACE)

print "INFO_HW_A: " + `sdl.video_info ( sdl.INFO_HW_A   )`
print "INFO_WM_A: " + `sdl.video_info ( sdl.INFO_WM_A  )`     
print "INFO_BLT_HW: " + `sdl.video_info ( sdl.INFO_BLT_HW  )`   
print "INFO_BLT_HW_CC: " + `sdl.video_info ( sdl.INFO_BLT_HW_CC  )`
print "INFO_BLT_HW_A: " + `sdl.video_info ( sdl.INFO_BLT_HW_A  )` 
print "INFO_BLT_SW: " + `sdl.video_info ( sdl.INFO_BLT_SW    )` 
print "INFO_BLT_SW_CC: " + `sdl.video_info ( sdl.INFO_BLT_SW_CC  )`
print "INFO_BLT_SW_A: " + `sdl.video_info ( sdl.INFO_BLT_SW_A   )`
print "INFO_BLT_FILL: " + `sdl.video_info ( sdl.INFO_BLT_FILL  )`
print "INFO_MEM: " + `sdl.video_info ( sdl.INFO_MEM )`

The result from the video_list_modes is always a plain 0. Like this:

% ./sdl_info.py 
0
0
INFO_HW_A: 0
INFO_WM_A: 1
INFO_BLT_HW: 0
INFO_BLT_HW_CC: 0
INFO_BLT_HW_A: 0
INFO_BLT_SW: 0
INFO_BLT_SW_CC: 0
INFO_BLT_SW_A: 0
INFO_BLT_FILL: 0
INFO_MEM: 0

This seems a bit wrong, so what do I do wrong, or what do I not understand
properly? Mainly I'd like to know wether 1024x768 can be opened on the
used system, and what depth I can get. Acceleration info could be of some
interest too, but not necessary.

What is the proper forum for discussion about applications using PySDL or
different techniques? I think it would be nice to be able to share ideas
and get some help. I'm not that experienced in lowlevel surface handling
as needed by SDL (and PySDL). Transparency is for instance one thing that
would be nice to learn more about. 

Is there any publicly available PySDL applications that I could use to see
how others have done things?

	Regards, Chakie

--------------------+--------------------------------------------------------
Jan 'Chakie' Ekholm |     Balrog New Media    http://www.balrog.fi/
   Linux Inside     | I'm the blue screen of death, nobody hears your screams

Re: [Pysdl-devel] pySDL gui?

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

Except for your last paragraph, I'd recommend
wxPython (www.wxpython.org) and Boa Constructor
for an IDE (boa-constructor.sourceforge.net).

The Audacity project (http://www.cs.cmu.edu/~music/audacity/)
is doing audio using wxWindows - you can check
out their code and see if they're getting around
Event problems in some other way.

I'm still not sure what the moral difference is
between using a payware Qt on Windows and
using Microsoft VC++ on Windows.  (I've been
informed that Cygwin is a bit slow and
bloated on Windows, so not a very lovely
free alternative).

Also, is there any consideration of putting
record capabilities into SDL?  The audacity
project has some cross-platform audio stuff
down in snd/ that could be hacked for this
as well.

Bill

David Clark wrote:
> 
> I'd like to poll the list regarding the direction we should take for
> integrating a gui with pySDL. I can see a few options:
> 
> 1) We could build in bindings to one of the SDL widget libraries, like
> ParaGUI or SDL_gui. Pros: Cross platform, shouldn't be too hard (I
> hope :)) Cons: The libraries I'm aware of aren't very complete. Do
> they overlap with SDL_ttf?
> 
> 2) We could write our own widget classes in python or C, and make them
> an extension to pySDL. Pros: Cross-platform, lots of control over the
> final product. Cons: Lots of work; does the SDL world really need
> another half-finished widget project?
> 
> 3) We could latch onto a cross-platform GUI library like wxWindows or
> FLTK. Pros: These are mature, well written projects, both of which
> have python bindings. Cons: FLTK is C++, and neither project works on
> the Mac. Both are large and complicated.
> 
> 4) We could write the code necessary to use SDL as a rendering target
> for GTK. Pros: Cross-platform. Mark already mentioned this as a
> possible future project. Cons: I don't know enough about this to
> say. Doesn't GTK still have problems on Win32?
> 
> 5) This page: http://www.trolltech.com/company/announce/loki.html
> talks about a partnership between Loki and Trolltech, the makers of
> the Qt toolkit. The press release mentiones "enabling Qt functionality
> in SDL". Does this mean native Qt widgets displaying on SDL surfaces?
> Much heat, little light so far on the SDL mailing list. Pros: Could be
> the most elegant solution of all, if it's being integrated directly
> into SDL. Cons: Isn't Qt still commercial on Win32? No timetable for
> this announcement. No specifics.
> 
> 6) We could do nothing. Pros: Easiest of all. Most cross-platform
> solution available. I don't have to write any more docs :) Cons: Each
> game developer has to reinvent the wheel. This would be a shame,
> considering how ubiquitous things like buttons and scrollbars are.
> 
> I mention all this because my project has reached the point where I'm
> starting on the gui work. I've worked with wxPython in the past, and
> although I enjoy coding for it, pySDL and wxWindows don't work very
> well together. For one thing, I'm obviously limited to windowed modes,
> but more importantly, the event models for the two libraries tend to
> conflict. For example, events_wait() locks the wxWindows events, and
> events_poll() only works if I riddle my code with empty for: pass
> loops. Yuck.
> 
> David Clark
> si...@te...
> Preliminary pySDL Documentation:
> http://www3.telus.net/futility/futility/docs/pysdl/index.html
> 
> _______________________________________________
> PySDL-devel mailing list
> PyS...@li...
> http://lists.sourceforge.net/mailman/listinfo/pysdl-devel

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

[Pysdl-devel] Re: pySDL gui?

[Nicola L. <ni...@te...>]

> 3) We could latch onto a cross-platform GUI library like wxWindows
> or FLTK. Pros: These are mature, well written projects, both of
> which have python bindings.
> Cons: FLTK is C++

Is this a problem? Python is object-oriented, after all. :^)

> 5) This page: http://www.trolltech.com/company/announce/loki.html
> talks about a partnership between Loki and Trolltech, the makers of
> the Qt toolkit.
> ...
> Cons: Isn't Qt still commercial on Win32?

Yep, see point 13 at http://www.trolltech.com/developer/faq/free.html :

"13.I want to use Qt to develop free software on Windows.
Qt/Windows is only available as Professional/Enterprise Edition, not as Free Edition. Using an X client library for Windows and a Windows X server, it is possible to use the X11 version of Qt on Windows."

Yeah, right. :^(

> No timetable for this announcement. No specifics.

Also, Qt is C++ based too. Cannot see the problem, anyway.

Also #2: there seems to be some mismatch between the platforms supported by SDL and those supported by Qt.
 
-- 
Nicola Larosa - ni...@te... - www.tekNico.net

Re: [Pysdl-devel] pySDL gui?

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

> I'd like to poll the list regarding the direction we should take for
> integrating a gui with pySDL. I can see a few options:

i've come to looking at this from time to time. currently, it seems
all the SDL GUI's have moved to C++. to me this makes them a bit
less desirable.
i've seen the Qt announcement as well, and it could provide an
interesting path, but i'm afraid for the win32 bindings, since
Qt for windows is commercial only.

i've written several "image-based-guis" in C/C++ before, and i
think it wouldn't be too far out there to try to do our own
python versions. as i see it, the widgets would be extremely
simple, (ie, a button widget would take several surfaces
representing the various states (rest,hover,push,disable)
and either call an overriden method for that widget or
potentially send a custom user SDL event message.

i wouldn't be afraid of trying to create our own. it's true
that there are several SDL libraries out there, but like you
mentioned, they aren't quite complete themselves, and the
C++ makes wrapping a little more work (plus we end up locked
down to a C++ style)
as i've done a couple UI things before, the two hardest
widgets will be a text entering field and a scrolling list
box. other than that, most game UI's just need pushbuttons,
checkboxes and a menu-type control

to me, the most important thing would be for the program
to have a lot of control over the UI. some of the SDL UI
lib's i've looked seem to want complete control over the 
SDL queue and screen surface. i'd be looking for something
completely opposite.

well, i'm off to bed for now, but i'm sure discussion will
follow

[Pysdl-devel] pySDL gui?

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

I'd like to poll the list regarding the direction we should take for
integrating a gui with pySDL. I can see a few options:

1) We could build in bindings to one of the SDL widget libraries, like
ParaGUI or SDL_gui. Pros: Cross platform, shouldn't be too hard (I
hope :)) Cons: The libraries I'm aware of aren't very complete. Do
they overlap with SDL_ttf?

2) We could write our own widget classes in python or C, and make them
an extension to pySDL. Pros: Cross-platform, lots of control over the
final product. Cons: Lots of work; does the SDL world really need
another half-finished widget project?

3) We could latch onto a cross-platform GUI library like wxWindows or
FLTK. Pros: These are mature, well written projects, both of which
have python bindings. Cons: FLTK is C++, and neither project works on
the Mac. Both are large and complicated.

4) We could write the code necessary to use SDL as a rendering target
for GTK. Pros: Cross-platform. Mark already mentioned this as a
possible future project. Cons: I don't know enough about this to
say. Doesn't GTK still have problems on Win32?

5) This page: http://www.trolltech.com/company/announce/loki.html
talks about a partnership between Loki and Trolltech, the makers of
the Qt toolkit. The press release mentiones "enabling Qt functionality
in SDL". Does this mean native Qt widgets displaying on SDL surfaces?
Much heat, little light so far on the SDL mailing list. Pros: Could be
the most elegant solution of all, if it's being integrated directly
into SDL. Cons: Isn't Qt still commercial on Win32? No timetable for
this announcement. No specifics.

6) We could do nothing. Pros: Easiest of all. Most cross-platform
solution available. I don't have to write any more docs :) Cons: Each
game developer has to reinvent the wheel. This would be a shame,
considering how ubiquitous things like buttons and scrollbars are.

I mention all this because my project has reached the point where I'm
starting on the gui work. I've worked with wxPython in the past, and
although I enjoy coding for it, pySDL and wxWindows don't work very
well together. For one thing, I'm obviously limited to windowed modes,
but more importantly, the event models for the two libraries tend to
conflict. For example, events_wait() locks the wxWindows events, and
events_poll() only works if I riddle my code with empty for: pass
loops. Yuck.



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

[Pysdl-devel] SDL updated the alpha

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

SDL (the latest CVS release) has just been updated with all alpha
values reversed. (0=full transparent, 255=full opaque)
i'm glad they changed this as SDL was the only package anywhere
i've ever seen to treat the alpha values backwards.
SDL_image > 1.0.9 will be needed to work with the new package
properly (apparantly being released soon also)

also new to SDL is altering the videocards gamma ramps. this
allows you to do great color fades and effects. it seems to work
on most available hardware.

anyways, this probably won't be rolled into pySDL until the
next official SDL release, but i must say, SDL is getting great
improvements and enhancements every couple days.

just thought everyone might want to know what's going on with
the SDL development

Re: [Pysdl-devel] New PyAliens??

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

> Did anybody try to use Python2C ( http://www.mudlib.org/~rassilon/p2c/ )
> to squeeze that extra ounce of performance?

i haven't tried python2c just yet. i've done a couple things
here and there to see if i could get a 'free' performance boost.
while it might help some, i doubt python2c would show much
of a real performance help. you're likely better off trying
to find a better algorithm.
nonetheless, i am curious, if someone has the time to do
some quick benchmarking with and without python2c i'd love
to see the results.

awhile ago i tried seeing if stackless python would make any
difference with pysdl performance. the results were almost
identical. maybe a 1 fps improvement in a couple cases, but
nothing to get excited about (or even bother switching)

i would guess there would be some benefit from Michael
Hudson's bytecode hacks (inlining functions, etc) but
they seem pretty technical and unproven. nonetheless, some
day i'd like to see what's possible by playing with it.

Re: [Pysdl-devel] New PyAliens??

[Nicola L. <ni...@te...>]

Hi everybody, I am new to the list, just a Python/Zope fan from Italy. :^)

Yesterday, after a lot of search for a way to write arcade games in Python, I found PySDL, and Cow Tipper, and PyAliens, and my life is not the same anymore. :^)))

A few problems aside (caused by not having audio on Linux on this stupid Compaq), I was going to study PyAliens as basis for a rewrite of the old Sega arcade Head On 2 ( http://www.klov.com/H/Head_On_2.html ), and lo, here comes The Pete Rewrite! That's what they call perfect timing!

Thanks to Mark, David, Pete and everybody else for such a tool. I look forward to share anything I may build.

Did anybody try to use Python2C ( http://www.mudlib.org/~rassilon/p2c/ ) to squeeze that extra ounce of performance?

>> well i was sitting around today, and i thought i'd try to
>> clean up David Clark's Excellent little PyAliens Demo.

> This is really excellent. The version I did was just a hacked-up,
> half-C half-python experiment, but Pete's code is really very
> good. It's certainly worthy of inclusion in a pysdl/demos directory,
> if Mark chooses to include one. Mark?
 
-- 
Nicola Larosa - ni...@te... - www.tekNico.net

[Pysdl-devel] New PyAliens??

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

Pete Shinners writes:
 > well i was sitting around today, and i thought i'd try to
 > clean up David Clark's Excellent little PyAliens Demo.
 > I suppose it's an excellent demo, because it is Sam Lantiga's
 > standard SDL demo program for C.

>snip<

This is really excellent. The version I did was just a hacked-up,
half-C half-python experiment, but Pete's code is really very
good. It's certainly worthy of inclusion in a pysdl/demos directory,
if Mark chooses to include one. Mark?

One suggested change: On lines 224 and 228, the explosion sound is
played on channel 0, the same channel as the shot sound. As a result,
explosions quickly followed by shots are truncated. If these two lines
are changed to "audio.play(1, Snd.explode, 0, -1)" so that the
explosions play on channel 1, the two effects can overlap. 

By the way Pete, I love your docstrings :)

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

[Pysdl-devel] New PyAliens??

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

well i was sitting around today, and i thought i'd try to
clean up David Clark's Excellent little PyAliens Demo.
I suppose it's an excellent demo, because it is Sam Lantiga's
standard SDL demo program for C.

Anyways, for better or worse i went and redid the PyAliens
that David Clark did. My goal was to make it a lot simpler
to follow, be more python-like, and most of all make an
actual good demo/sample for pysdl.

Well, here it is. perhaps it will get rolled into pyaliens 1.2?
I'm happy with the results, and anyone with small grasp of 
programming should be able to look at this new pyaliens and
follow along with ease.

As an added bonus, the python code is now about 30% smaller
and now runs well over the needed 50 fps to keep up with the
fps delay. (whereas my nt4-p300 was running well under 50fps
before this)

anyways, i've attached the whole thing. my main desire was
to see some code that actually could 'show off' what python
does. all the current demos and samples are pretty rough looking
and don't really show much benefit of Python over C. Hopefully
something like this can get rolled into the official pysdl
release. i'm motivated enough to clean up all the current
samples/demos and really make them shine.

anyways, i'll definitely hear anyone's suggestions. if
someone knows of another small demo like this that would be
beneficial to add the the pysdl samples let me know!

Re: [Pysdl-devel] slowness

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

> I've got a quick little game "Cow Tipping" I've written in pySDL at:
>  http://bluesine.com/archives/software/cowTipper/

well, much to my delight the game ran without any performance
problems. glancing over the code, i would say the two biggest
things to help you out would be convert the sprites you load
to the display format. the other would be to update only the
"changed" portions of the screen instead of redrawing the
whole thing

the first one is easy.. change your "imageLoad" function
in jdsl.py to look like this one...


def imageLoad(fn):
        temp = sdl.image_load(fn)
        img = temp.convert_display()
        img.set_colorkey(1,img.get_at(0,0))
        return img

also change the background loading on cowMain.py:128 to this

bgTemp = sdl.image_load("desert.png")
bgScene = bgTemp.convert_display()
del bgTemp

this may or may not have an effect depending on the graphics
mode of the images and the graphics mode of the scene. it will
be different on different platforms. the one this this will do
is ensure your blit's are happening as fast as possible.


the other change that is sure to give you more speed is
the way you are drawing the scene. SDL works 'best' when it
is only drawing the parts of the screen it needs to. the
easiest way to do this will be to not clear the whole
screen every frame, but just erase the background where the
cows are moving. there are many methods to do this, each
more complex and offering more speed. here is a simple 
example that should provide 'middle of the road' performance.

first, add a method to the cow class that is like this
    def erase(self, scr, bg):
        rect = (self.x, self.y,
                    self.sprites[self.aframe].get_width(),
                    self.sprites[self.aframe].get_height())
        scr.blit(bg, rect, rect)
        scr.update_rect(rect)

second, uncomment out the "update_rect" line at the end of the
cow.draw method

third, in your loop at cowMain.py:185 change it to read
    for c in cows:
        c.erase(scr, bgScene)
        c.move()
        c.draw(scr)

and finally, comment out (or delete) the lines at 179 and
194 that redraw the whole background and update_rect the whole
screen.

i didn't test any of that code out, i just typed it straight
into the email, so there may be problems (sorry)
doh, i forgot you'll also have to fill the area underneath
the printScore() text with the background also.

if you need help with any of this i'd be glad.

the next method to optimize would involve not clearing the
"entire" area before the cow moves, but only clearing the
area that is "revealed" behind the cow as he moves. but you
may not even need that sort of method.

anyways, all in all i think it's great. i think it would
be excellent for pysdl to come with something like this as
one of its sample apps.


ps, my machine is running windows nt4 on a p2-300. like i said
the performance on it was fine, and the sound and everything 
worked as expected.

pps, i much prefer the "cowDelay" set to 5. it makes for a much
funner game! (and anyone who can get past level 6 with that level
is one handy rancher!)

[Pysdl-devel] slowness

[Jeff C. <je...@bl...>]

I've got a quick little game "Cow Tipping" I've written in pySDL at:
 http://bluesine.com/archives/software/cowTipper/

I must say I absolutely love pySDL and development of this cheezy game was
a breeze.  I wrote it under Linux and ran it under windows with zero
changes which was nice.  The problem I am having is speed.  I realize that
pySDL is very early  in development but was wondering if I am doing
something wrong or it's just the way it is.  Mostly the problem is on
slower machines the mouse movement is really choppy.

If someone could take a peek at source code at let me know I would
appreciate it.  Again this is a fantastic thing to come to Python.

Attached is the source code for the game itself. 

== Jeff Clement <je...@bl...> ==

[Pysdl-devel] Audio subsystem

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

Sorry for the long break between posts - Diablo II has really killed
my productivity. Thanks to everyone who mailed me updates for the
documentation, especially Eric Jacobs, whose excellent summary of
shifts, masks and losses will probably get plopped down verbatim in
the documentation :)

I have a couple of questions about the Audio subsystem.

1) Audio_object.get_volume() doesn't seem to work as expected. The
first call on a given channel works fine, returning an INT between 0
and 128. However, if I immediately call get_volume() again, it changes
the channel's volume to 0. Presumably this is a bug, since
get_volume() should be read only. I had a look at the code for this
function, and it seems ok, which makes me think this is a bug in
SDL_mixer.

2. If I create an audio object with (say) 2 channels (number 0 and 1),
and then call audio_object.play(8, sound_object) to play the sound on
channel number 9, it works. I think it should raise an exception
instead.

What do you think, sirs?

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

Re: [Pysdl-devel] get_shifts(), get_masks, get_losses()

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

--- Eric Jacobs <ea...@ri...> wrote:
> A pixel value is computed using the formula:
> 
>       (level >> loss) << shift
> 
> for each channel and then bitwise or'ing the results
> together.
> This is exactly what map_rgb does for packed-pixel
> surfaces.
> 
> (255 >> loss) << shift should yield the channel
> mask.
> 
> There usually won't be a reason to get down and muck
> with this
> stuff from PySDL. The one notable exception is if
> you're writing
> to a surface with an alpha channel. 

Another nice thing is the bitwise operators work on
numpy-arrays without using a loop, like in Pete
Shinners' flame demo.  I used this in a function to
make gradients, and it saved time.  

I might modify this so that the MakeMap part makes a
4x larger map with the center always at the center. 
Then MakeMap would only ever need to be done once, and
MakeGradient could run every frame with different
colors, curve and center point (the center point would
determine what slice of the map array to use). 

It would be equally possible to make changing
alpha-gradients or other patterns that didn't affect
the RGB values of a surface.  This could be nice for
clouds or smoke effects.


__________________________________________________
Do You Yahoo!?
Kick off your party with Yahoo! Invites.
http://invites.yahoo.com/

[Pysdl-devel] get_shifts(), get_masks, get_losses()

[Eric J. <ea...@ri...>]

> fbref.get_shifts() -> (INT rshift, INT gshift, INT bshift, INT ashift)
>
> This function returns the bit shift information for the surface.
>
> FIXME: What does this mean? find out. 

SDL provides a general method to specify and use packed-pixel surface
formats. Every surface format is created with four channel masks:
Rmask, Gmask, Bmask and Amask, corresponding to the R, G, B, and A
channels.

A bit set in a channel mask means that that bit is used to convey
information about the level of that channel. SDL supports channel
masks that have up to eight consecutive bits set, which means that
a channel can have a range as large as 0 to 255.

Based on the channel masks that are passed in when a surface is
created, SDL derives two values for each channel: the shift and
the loss. The shift is the number of zero bits following the
rightmost bit set in the mask. The loss is 8 (max width of a
channel) minus the number of consecutive bits set in the mask.

For example, here is a green channel mask (Gmask) and its shift
and loss (Gshift and Gloss) for a 16-bit surface:

Gmask: 0000 0111 1110 0000
             |     |
             |     |<--->|  Gshift = 5 bits from rightmost bit
             |     |
             |<--->|        Gloss = 8 - 6 bits set = 2 bits lost



A pixel value is computed using the formula:

      (level >> loss) << shift

for each channel and then bitwise or'ing the results together.
This is exactly what map_rgb does for packed-pixel surfaces.

(255 >> loss) << shift should yield the channel mask.

There usually won't be a reason to get down and muck with this
stuff from PySDL. The one notable exception is if you're writing
to a surface with an alpha channel. SDL doesn't expect that
user programs will be interested in manipulating an alpha channel
directly; therefore it doesn't provide functions such as map_rgba,
get_rgba, etc. In this case, the pixel value can be computed
using the shift and the loss values.

Caveat: Although SDL computes the proper value for Aloss, it
currently does not ever use this value in any way. Alpha channels
must either be eight bits wide (Aloss == 0) or not exist at all
(Aloss == 8).

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

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

Mark Baker wrote:
> 
> On Wed, 26 Jul 2000, Bill Eldridge wrote:
> 
> > No one picked up on my thought earlier about
> > whether the Audacity cross-platform audio recording stuff
> > could be easily converted into a Python abstracted
> > recording module for PySDL:
> >
> > http://www.cs.cmu.edu/~music/audacity/
> 
> I took at look at audacity and it appears to be a sound editor written
> in C++. It didn't mention anything regarding recording, nor did it
> look like it was worth rewriting or ripping out parts of it and then
> thunking it in C so it could be used for PySDL.

Oops, yep, audio recording is on their "suggested features" list.
Sorry.

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

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

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

On Wed, 26 Jul 2000, Bill Eldridge wrote:

> No one picked up on my thought earlier about
> whether the Audacity cross-platform audio recording stuff
> could be easily converted into a Python abstracted
> recording module for PySDL:
> 
> http://www.cs.cmu.edu/~music/audacity/

I took at look at audacity and it appears to be a sound editor written
in C++. It didn't mention anything regarding recording, nor did it
look like it was worth rewriting or ripping out parts of it and then
thunking it in C so it could be used for PySDL.
 
> It also looks like the new Java Media Framework has much
> better support for audio recording (at least
> on Windows and in beta on Linux), though that
> might require pulling in too much extra stuff
> into PySDL:

Yes. Pulling Java into PySDL is right out.
If what you want is JMF, take a look at JPython.

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

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

> No one picked up on my thought earlier about
> whether the Audacity cross-platform audio recording stuff
> could be easily converted into a Python abstracted
> recording module for PySDL:
> 
> http://www.cs.cmu.edu/~music/audacity/

i would imagine it best to keep this entirely separate
from SDL. (at most, perhaps a tostring/fromstring type
interface like PIL uses to transfer sounds between the
packages)

the best bet would for someone to take the audacity
code (looks gpl'd?) and create a new library all together.
since it looks like their code is meant to only be used
by themselves. probably needs to be cleaned up a bit to
compile nicely as a library

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

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

Peter Nicolai wrote:

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

No one picked up on my thought earlier about
whether the Audacity cross-platform audio recording stuff
could be easily converted into a Python abstracted
recording module for PySDL:

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

It also looks like the new Java Media Framework has much
better support for audio recording (at least
on Windows and in beta on Linux), though that
might require pulling in too much extra stuff
into PySDL:

http://java.sun.com/products/java-media/jmf/index.html
--
Bill Eldridge
Radio Free Asia
bi...@rf...

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

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

Mark Baker writes:
 > On Tue, 25 Jul 2000, David Clark wrote:
 > > 
 > > 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.
 > 

Whoops. Sorry. I meant a 2-d array; fb[x][y] = color.

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

I guess my point is that the proper place for innovation is in SDL;
pySDL should just wrap that functionality.
 
 > 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 

Your post was truncated here; I'll assume you're talking about
providing gtk toolkit rendering in an SDL window. If this is in fact
what you're considering, I'd be fully in favour of it. My current
project requires heavy gui widget support. I had briefly considered
and rejected creating my own widgets - the only remaining
cross-platform option is using something like pygtk or wxPython and
keeping my SDL output windowed. This will definitely hurt my
performance, especially on Windows. Seeing that GTK is already pretty
cross-platform, and seeing that pyGTK is pretty mature, I would think
that adding GTK as the toolkit for pySDL would be the natural choice
:)

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