[pygame] Collision Resolver module

2007-12-31 Thread sjbrown
Hi all.

Here's a collision resolver module I've been working on.

A common problem in 2D games is trying to move a sprite in a direction
(deltaX, deltaY) and then discovering that there is a solid object in the
new position it wants to occupy, so you have to move it back to the edge of
that solid object.

Further complicating matters, just checking the end position is sometimes
not enough.  When a rectangle moves it sweeps through a hexagonal shape, and
there might be solid objects that collide with this sweep hexagon that
don't collide with the end position.  This issue is more pronounced the
bigger (deltaX, deltaY) gets.

An even further complication: if you displace the rect due to a collision
inside the sweep hexagon, it may then collide with a new solid object that
lies outside the original sweep hexagon.

This module provides a function that you can call, resolve_collisions() that
will sort all this mess out for you.

I think this is a general enough problem in 2D games that the resolver
function be considered for inclusion in pygame itself.

I have included a program that demonstrates what it does.  Just run:

python collision_resolver_example.py

options are printed to the terminal.

-sjbrown

collision_resolver.tar.gz
Description: GNU Zip compressed data


[pygame] Scrolling Background module

2007-12-31 Thread sjbrown
Hi all.

Here's a module that provides a scrolling background.  This is pretty common
in 2D games and I think it should be considered for inclusion in pygame.

To see a simple, 100-line example, just run:

python scroll_example.py

-sjbrown

scrolling.tar.gz
Description: GNU Zip compressed data


Re: [pygame] Collision Resolver module

2007-12-31 Thread kschnee
On Mon, 31 Dec 2007 03:20:43 -0500 (EST), [EMAIL PROTECTED] wrote:
 Hi all.
 
 Here's a collision resolver module I've been working on.
 
 A common problem in 2D games is trying to move a sprite in a direction
 (deltaX, deltaY) and then discovering that there is a solid object in the
 new position it wants to occupy, so you have to move it back to the edge
 of
 that solid object.


This kind of problem -- checking a _sprite_ for collisions -- is why I
don't think it's a good idea to have game objects based around sprites.
We're trying to represent a physical space, so having objects recorded in
terms of screen coordinates blurs the distinction between where something
is drawn and where it _is_. What if the screen scrolls? Suddenly all the
objects move even if they're not supposed to be moving.

What I've been doing is decoupling sprites from game entities. Doing that
has already paid off in an unexpected way. When I changed the tile size I
was using, making one unit of space represented by fewer pixels, I noticed
that my character seemed to run slower. It didn't, actually; its apparent
speed had automatically adjusted to the new tile size, without my having to
re-code it!



Re: [pygame] Collision Resolver module

2007-12-31 Thread sjbrown

 Here's a collision resolver module I've been working on.

 A common problem in 2D games is trying to move a sprite in a direction
 (deltaX, deltaY) and then discovering that there is a solid object in the
 new position it wants to occupy, so you have to move it back to the edge
 of that solid object.


 This kind of problem -- checking a _sprite_ for collisions -- is why I
 don't think it's a good idea to have game objects based around sprites.
 We're trying to represent a physical space, so having objects recorded in
 terms of screen coordinates blurs the distinction between where something
 is drawn and where it _is_. What if the screen scrolls? Suddenly all the
 objects move even if they're not supposed to be moving.

 What I've been doing is decoupling sprites from game entities. Doing that
 has already paid off in an unexpected way. When I changed the tile size I
 was using, making one unit of space represented by fewer pixels, I noticed
 that my character seemed to run slower. It didn't, actually; its apparent
 speed had automatically adjusted to the new tile size, without my having to
 re-code it!

If you take a look at the code, particularly at the resolve_collisions
function, it doesn't actually care about sprites, it can work generically
with the rects alone, or with any object that has a .rect attribute.

-sjbrown



[pygame] controlled midi playback

2007-12-31 Thread [EMAIL PROTECTED]
hi,

i have a midi song (not polyphonic) and want to play back one note after
another triggered by key presses. what would be the best way to do this? i
guess i can't directly do this with pygame but i need some midi library?
does anyone know which one would be suited for that (ideally it should work
in linux and windows)? has anyone tried to do something similar?


Re: [pygame] controlled midi playback

2007-12-31 Thread Lenard Lindstrom

[EMAIL PROTECTED] wrote:

hi,
 
i have a midi song (not polyphonic) and want to play back one note 
after another triggered by key presses. what would be the best way to 
do this? i guess i can't directly do this with pygame but i need some 
midi library? does anyone know which one would be suited for that 
(ideally it should work in linux and windows)? has anyone tried to 
do something similar?

Check out the Python music page:

http://wiki.python.org/moin/PythonInMusic

Of the various midi packages PyPortMidi is still available.

--
Lenard Lindstrom
[EMAIL PROTECTED]