headers
Pete Shinners | 2 Jun 2002 04:10
Picon

[pygame] Solarwolf 1.1

Hey folks, here's my exciting announcement.

SolarWolf 1.1 released today. This is a fun new version for everyone's 
favorite pygame project. Here's the breakdown:

  * Stereo sound panning
  * Easier, slightly slower and better continue
  * "Commentary"
  * Works at 8bit now
  * emm, lots of other stuff too

http://www.pygame.org/shredwheat/solarwolf/

____________________________________
pygame mailing list
pygame-users@...
http://pygame.seul.org
Permalink | Reply | 0 comments |
headers
Syver Enstad | 3 Jun 2002 23:57
Picon
Picon

Re: [pygame] How fast is pygame meant to be?

Pete Shinners <pete@...> writes:

>i tested it on
> 
> a NT4 machine with no directx. at 300mhz the program ran at 26fps with
> 
> no frags, and 23fps with a couple explosions onscreen. with hardware
> acceleration i'm guessing you will also be at 80fps like bb.
> 

With win2k pro, pentium III 550 I get my refresh rate per second (75) when
clicking the mouse button now and then, if I click very fast the frame
rate drops as the sparks acumulate.

--

-- 

Vennlig hilsen 

Syver Enstad

____________________________________
pygame mailing list
pygame-users@...
http://pygame.seul.org
Permalink | Reply | 0 comments |
headers
tomten | 4 Jun 2002 01:47
Picon
Picon

Re: [pygame] How fast is pygame meant to be?

Christian Perfect wrote:

>Hi,
>	I'm a Blitz Basic (www.blitzbasic.com) user who's been playing
>aroudn with pygame, so the first thing I decided to do was to make a pygame
>version of the "firepaint" demo that comes with BB. It's a simple demo that
>shoots sparks from your mouse cursor that fall to the screen when you click
>the mouse. I'm no good at optimising, so the code just follows the BB
>firepaint demo pretty closely. When I ran the demo, it ran *much* slower
>than the BB demo, at 8fps, whereas in BB it runs at my refresh rate (80fps+)
>Is pygame just not meant to be used for this kind of thing, and just
>blitting a few images and playing some sounds, or is there some secret
>different way of doing things I haven't found yet? :)
>If you're interested, I've uploaded my firepaint demo to
>www.ebizimonkey.com/firepaint.py
>
>	Christian Perfect
>____________________________________
>pygame mailing list
>pygame-users@...
>http://pygame.seul.org
>
Ahh, Blizt Basic remember it form my Amiga days... Didn't know it 
excised for the PC :-).
The main thing to remember with python is that it's not a compiled 
language as I think Blitz Basic is and thus not even in the same 
ballpark when it comes to this sort of programming.
I think this is a typical trap with python(pygame), you have to know the 
language to avoid the pitfalls, know the limitations and the workarounds.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Christian Perfect | 4 Jun 2002 09:34
Picon

RE: [pygame] How fast is pygame meant to be?

thanks for your help :)
I'm not exactly sure what I was thinking when I wrote AND for the flags, but
it definitely wasn't right :P
Thanks for the tip about global vars - I didn't know about that.
I've implemented your changes (and the index thing for handling the frags
jozef posted) and it runs at 80fps when there's nothing happening, but slows
down to around 15/20 fps when there are lots of frags on screen. I think my
question's answered, then - don't use pygame for pixel plotting :P

Another observation - hardware acceleration doesn't seem to be available in
windowed mode. Is it meant to be?

I've uploaded the new code to the same address -
www.ebizimonkey.com/firepaint.py, if anyone wants to check the frame rates.

Thanks for your help,
	Christian Perfect

-----Original Message-----
From: Pete Shinners [mailto:pete@...]
Sent: 03 June 2002 21:11
To: pygame-users@...
Subject: Re: [pygame] How fast is pygame meant to be?

Christian Perfect wrote:
> 	I'm a Blitz Basic (www.blitzbasic.com) user who's been playing
> aroudn with pygame, so the first thing I decided to do was to make a
pygame
> version of the "firepaint" demo that comes with BB. It's a simple demo
that
(Continue reading)

Permalink | Reply | 4 comments |
headers
Pete Shinners | 4 Jun 2002 10:55
Picon

Re: [pygame] How fast is pygame meant to be?

Christian Perfect wrote:
> down to around 15/20 fps when there are lots of frags on screen. I think my
> question's answered, then - don't use pygame for pixel plotting :P

this is true. any intense pixel work will definitely show up on the python 
scale of speed. if we needed we could probably hardcode some of the effect 
down and gain a little extra speed. the only fortunately thing is that 
python mixes easily with C, so particle systems could be handled elsewhere 
inside a game.

> Another observation - hardware acceleration doesn't seem to be available in
> windowed mode. Is it meant to be?

true, this is how SDL works. when using a window SDL doesn't even bother 
with directx acceleration. there's nothing technical keeping that from 
working, it just sadly has never been written for SDL.

____________________________________
pygame mailing list
pygame-users@...
http://pygame.seul.org
Permalink | Reply | 3 comments |
headers
Andy Sy | 4 Jun 2002 12:11

Re: [pygame] How fast is pygame meant to be?

> > Another observation - hardware acceleration doesn't seem to be available
in
> > windowed mode. Is it meant to be?
>
> true, this is how SDL works. when using a window SDL doesn't even bother
> with directx acceleration. there's nothing technical keeping that from
> working, it just sadly has never been written for SDL.

Accelerated OpenGL in a window works (at least
on my Windows XP/Voodoo 3 setup) fine though. The
hardware alpha blending, scaling, vastly more
powerful sprite blitting (i.e. 2D polygons) etc...
that OpenGL provide make the added complexity
of learning the API really worth it.

A 3D API is really the way to go as a lot of
hardware functionality is not exposed by
DirectDraw especially now that it's deprecated.

Pygame makes initializing OpenGL whether in a
window or fullscreen a snap and the integration
with the other functions like sound is still
just as easy.

____________________________________
pygame mailing list
pygame-users@...
http://pygame.seul.org
Permalink | Reply | 0 comments |
headers
Christian Perfect | 4 Jun 2002 12:08
Picon

RE: [pygame] How fast is pygame meant to be?

OpenGL sounds cool :)
I'll try and have a go at the NeHe tutorials in a bit..
The only thing that I don't like about OpenGL is all the talk of
transformations and stuff.. I suppose I'll just have to learn :P

-----Original Message-----
From: Andy Sy [mailto:andy@...]
Sent: 04 June 2002 11:11
To: pygame-users@...
Subject: Re: [pygame] How fast is pygame meant to be?

> > Another observation - hardware acceleration doesn't seem to be available
in
> > windowed mode. Is it meant to be?
>
> true, this is how SDL works. when using a window SDL doesn't even bother
> with directx acceleration. there's nothing technical keeping that from
> working, it just sadly has never been written for SDL.

Accelerated OpenGL in a window works (at least
on my Windows XP/Voodoo 3 setup) fine though. The
hardware alpha blending, scaling, vastly more
powerful sprite blitting (i.e. 2D polygons) etc...
that OpenGL provide make the added complexity
of learning the API really worth it.

A 3D API is really the way to go as a lot of
hardware functionality is not exposed by
DirectDraw especially now that it's deprecated.
(Continue reading)

Permalink | Reply | 0 comments |
headers
steve | 4 Jun 2002 19:52
Favicon

[pygame] y-Sorted RenderGroup

Hello,

   I've developed a RenderUpdate group that sorts it's sprites on their 
y position, useful for things like Japaneese style RPGs where sprites 
closer to the bottom of the screen are drawn first, and sprites near the 
top of the screen are drawn last.

   As you can see, I sort when I paint the sprites, because Python's 
dictionaries return their items in random order, sorting the dictionary 
would be pointless (you can't anyways).  After I sort, I paint the 
sorted list of sprites instead of spritedict.items(), #3 below.  I use 
my own sorting routine called y_sort(a, b).

   My question is, is creating an iternal list inside draw(), "y" in #1 
below, the right way of doing this?  Since draw is called so frequently, 
should I worry about garbage, and make this sorted list a class variable 
(self.y)?  Is there a better way of doing this within the existing 
Sprite classes, or am I on track here?

   Run this program within pygame's examples directory, it uses two of 
the images there for the test.

   TIA: Thanks in advance,
   Steve

------------------------------------------------------------------------

"""
    This is my implementation of a RenderUpdate group that sorts its 
sprites by
(Continue reading)

Permalink | Reply | 5 comments |
headers
Frank Raiser | 4 Jun 2002 20:16
Picon

Re: [pygame] y-Sorted RenderGroup

On Tue, Jun 04, 2002 at 10:52:02AM -0700, steve wrote:
>    I've developed a RenderUpdate group that sorts it's sprites on their 
> y position, useful for things like Japaneese style RPGs where sprites 
> closer to the bottom of the screen are drawn first, and sprites near the 
> top of the screen are drawn last.

Looks like an addition to the PCR to me.

>    As you can see, I sort when I paint the sprites, because Python's 
> dictionaries return their items in random order, sorting the dictionary 
> would be pointless (you can't anyways).  After I sort, I paint the 
> sorted list of sprites instead of spritedict.items(), #3 below.  I use 
> my own sorting routine called y_sort(a, b).

Ever got into lambda functions? Your sort routine can be rewritten like
this:

# y.sort(y_sort)
y.sort(lambda a,b: cmp(a[0].rect.top, b[0].rect.top))

It's nice, it's small and it's usually faster. I'm not exactly sure
how big the overhead of the cmp() call is, but you could also eliminate
that one by calling:

y.sort(lambda a,b: ((a[0].rect.top > b[0].rect.top)<<1)-1)

This one doesn't work exactly in case the two tops are equal.. but then
again order is irrelevant (to the sort) if they're exactly atop each other.

>    My question is, is creating an iternal list inside draw(), "y" in #1
(Continue reading)

Permalink | Reply | 1 comment |
headers
Mike C. Fletcher | 4 Jun 2002 20:48
Favicon

Re: [pygame] y-Sorted RenderGroup

If there's no reason to keep the sprites in a dict (sorry, haven't had 
time to look at the code, just going by Frank's comments), then using a 
bisect-based approach can be very fast.

Basically, you store the data in a sorted-order list and use the bisect 
module to add new items (which maintains sort order).  If you really do 
need the objects in a dict, you can do the work of pushing them into 
both dict and list and deleting them when adding/removing items.  The 
key is that you store the objects in the list as (sortParam, object), so 
that the standard Python sorting and comparison automatically works for 
the items.

The (sortParam,object) storage means you need to access objects as 
list[item][1] (or wrap that in an accessor method), but compared to 
calling a Python function (lambda or not) huge numbers of times (which 
is pretty darn slow) to do a sort, it should be much faster.

For the common case (wanting all objects), you can use
	map( operator.getitem, sortedlist, [1]*len(sortedlist))
to get all second items (the objects in sorted order) very fast.

Asides:
	cmp is a built-in, very fast.

	list.sort using a custom function is often much slower than building a 
temporary list of (sortValue, object) tuples, using default sort, then 
doing the operator.getitem (also a built-in) trick above to get the results.

	for changed values, simply remove the sprite, then re-insert with bisect. 
  There is overhead in finding the entry in the sorted list (use
(Continue reading)

Permalink | Reply | 0 comments |

Gmane