Pygame (release version) win32 installer for Python 2.7

Hi,

I have build an installer for the most recent release version of Pygame 
(1.9.1) for Python 2.7. It can be downloaded here:
<https://bitbucket.org/pygame/pygame/downloads/pygame-1.9.1.win32-py2.7.msi> 
at <bitbucket.org/pygame/pygame>.

Here are some md5 sums:

630e05f9f08c8a196822d5dd450d70c9 *pygame-1.9.1.win32-py2.7.msi

f2269992f12bfe661ca338ba73c581dd *prebuilt-pygame1.9.0-msvcr90-win32.zip

The other file is only required if building Pygame 1.9.1 from source. It 
contains the external libraries used by Pygame (included with the binaries).

May Python 2.6 rest in peace. *

Enjoy,

Lenard Lindstrom

* Unfortunately, Python 2.6 is still the default version for the current 
Debian release, squeeze.

Just sharing

I've been working on my little gravity program, except it really doesn't
apply to gravity anymore. Feel free to use it as you wish.

:
* press Esc to exit, q to almost stop all the particles, mouse to move
the central particle, any other key to add a new particle.
* 3d distances+ interactions
* 'spin'
* mouse attracts particles, scroll to control attraction speed
* uses multiprocessing (though not perfectly. Still working on the
comments I got from here, thanks!)

Note: If you aren't using python 3, uncomment the section in the file so
that the print statements don't raise a syntax error.

issue with pygame.rect.inflate_ip()

Re: issue with pygame.rect.inflate_ip()

On 04/02/12 07:12 AM, david BERTRAND wrote:
> Hi,
>
> I'm new here but I'm working whith pygame (1.9.2) since few month.
> When I use inflate() or inflate_ip, the resulting size and the new 
> rect.center are never as expected.
>
> reading the sources (1.9.1, rect.c), I found :
>
> self->r.x -= x / 2;
> self->r.y -= y / 2;
> self->r.w += x;
> self->r.h += y;
>
> if (r.w, r.h) is the size of the rect this is correct.
> But it woks like if (r.w, r.h)  represents the rect.bottomright corner.
> Andin this case, it seems better to write something like :
>
> self->r.x -= x / 2;
> self->r.y -= y / 2;
> self->r.w += x / 2;
> self->r.h += y / 2;
>
> Please, excuse me if I am wrong : I am not a great C reader.

Hi David,

A rectangle is stored as the position of the top-left corner (r.x, r.y), 
and the size (r.w, r.h). It is the same with rectangles in Python: 
Rect(left, top, width, height).

Lenard Lindstrom

loopwave.py equivalent?

I want to be able to continuously modify a sound buffer from a
callback, exactly as shown in the pygame 0.09 example loopwave.py

http://hg.pygame.org/pygame/src/d1cbb8c9d94b/test/loopwave.py

This uses direct access to SDL which seems to have disappeared in more
recent versions of pygame. I need to be able to  continuously vary the
frequency modulation of a tone in response to user input.

Will

Re: issue with pygame.rect.inflate_ip()

Is Pygame suitable for full HD games?

(I sent this earlier but I forgot to subscribe to the original mailing
list)

Hi all! I'm currently developing a 2D platformer (well, actually I
started it a lot of years ago with another language, but I got stuck
and stopped developing, and now I've rebooted the project with
Pygame), and I'd like it to be something like Sonic or some other
great platformers from the 16-bit era, specially from Sega Genesis
(Dynamite Headdy, Rocketknight Adventures, Ristar...) but in full HD.

Yesterday I finished the tiled background engine, and I've noticed a
15 fps drop in 1920x1080. And when I added a 5 planes parallax scroll,
fps are going down to 10-20. I doubt it's the machine, as I play games
like Starcraft in Ultra settings on it. Also, I'm noticing most games
developed with Pygame are 640x480 or 800x600. So the question would
be: is Pygame suitable for doing a full HD side-scrolling platformer?

My current approach is to render all scrolls planes and the tiled
background to a single surface (the ".image" of my Stage class),
instead of rendering each one in different planes. I haven't tried
separating yet, but I doubt it will improve performance, as the
blitting will be the same. Am I wrong?

I've read the Surface.blit() function is somehow slow and shouldn't be
overused, but I don't know another way of rendering images to the
screen. I tried using flags "HWSURFACE | DOUBLEBUF | FULLSCREEN" and
it increased 2-3 fps. Am I missing some other optimization or am I
just using the wrong engine for an HD platformer?

Thanks a lot in advance.

Re: issue with pygame.rect.inflate_ip()

Re: Is Pygame suitable for full HD games?

Re: Is Pygame suitable for full HD games?

On 2/5/2012 6:23 AM, Luis Morcillo wrote:

> I finished the tiled background engine, and I've noticed a
> 15 fps drop in 1920x1080. And when I added a 5 planes parallax scroll,
> fps are going down to 10-20. I doubt it's the machine, as I play games
> like Starcraft in Ultra settings on it. Also, I'm noticing most games
> developed with Pygame are 640x480 or 800x600. So the question would
> be: is Pygame suitable for doing a full HD side-scrolling platformer?
> 
> My current approach is to render all scrolls planes and the tiled
> background to a single surface (the ".image" of my Stage class),
> instead of rendering each one in different planes. I haven't tried
> separating yet, but I doubt it will improve performance, as the
> blitting will be the same. Am I wrong?
> 
If you don't blit it directly to a HWSURFACE, then it will still be
software blitting and probably wont make much of a difference. Try
initiating your .image with the HWSURFACE flag, and see if it improves
speed.

I think you are blitting everything to a .image, then the .image to the
screen once, right?

> I've read the Surface.blit() function is somehow slow and shouldn't be
> overused, but I don't know another way of rendering images to the
> screen. I tried using flags "HWSURFACE | DOUBLEBUF | FULLSCREEN" and
> it increased 2-3 fps. Am I missing some other optimization or am I
> just using the wrong engine for an HD platformer?

Say, are you using per-pixel transparency?
I know for a fact that it slows pygame down a lot, so if you don't need
intermediate tranlucency (eg, fading) you could use colorkeys.

I know that per-pixel alphas are slow, because I ran a test at 1920x1080
and adding a fifth surface with per-pixel alpha dropped frames from ~ 30
to ~8 per second.

Using colorkeys gave me 200 fps w/ pygame.RLEACCEL.
Adding one surface w/ transparency dropped it to 60fps.

I can send the code if you wish.

I do have a higher-end system, so opengl will probably be a good idea.
I'd suggest looking into PyGL3Display, which works for me although I
have just started to try it out.

I hope I have been helpful to your efforts.