Re: [pygame] Sprite Collision

[Ethan Glasser-Camp]

Kris Schnee wrote:
> Aha! I've seen a problem like this before. I called it the "stripey doom
> error," because when I did a tile-based game and changed one element,
> I'd see a whole stripe of tiles change instead of one. Python has other
> "sticky variable" problems sometimes if you don't think carefully about
> whether something is a reference to another variable. I would sometimes
> end up changing "constants" and having other problems.

This has happened to me too and "stripey doom error" is a great name
for it :).

> When all else fails, copy.deepcopy() seems to make Python understand, "I
> want this to have _the same value_ as X now has, not to be a _reference_
> to X."

When I was learning C++, and being taught how to write classes, we
were taught that some copies are shallow, and some copies are deep,
like with copy.deepcopy. A shallow copy is one that only copies one
level of stuff. So, for example:

>>> l = [1, 'a', {}]
>>> l2 = l[:]# make a shallow copy
>>> l
[1, 'a', {}]
>>> l2
[1, 'a', {}]
>>> l2 [1] = 'b'
>>> l
[1, 'a', {}]
>>> l2
[1, 'b', {}]

l2 is a copy of l, and I can change it separately. But the elements of
l2 are the same as the elements in l (the same objects, not a copy) so
if I change the dictionary:

>>> l2[-1]['a'] = 4
>>> l2
[1, 'b', {'a': 4}]
>>> l
[1, 'a', {'a': 4}]

... it changes in both. That's OK for your coords example, for
instance, because you aren't changing the integers (integers are
immutable), but changing the list that has those integers.

By comparison:

>>> l = [1, 'a', {}]
>>> l2 = copy.deepcopy(l)
>>> l2[-1]['a'] = 4
>>> l
[1, 'a', {}]
>>> l2
[1, 'a', {'a': 4}]

For lists, you can use the [:] syntax, which creates a slice of the
whole object, to get a shallow copy. You can also use functions like:

copy_of_coords = list(coords)
copy_of_d = dict(d)

The code that generates "stripey doom errors" isn't really creating a
copy of the rows, but repeating the same row, so it isn't even a
shallow copy.

I hope this is useful! The problem, the symptoms and the solution have
already been posted but I thought I would add some Computer Science
Lore to spice things up a bit.

Ethan



signature.asc
Description: OpenPGP digital signature

Re: [pygame] Sprite Collision

[Kris Schnee]

Ethan Glasser-Camp wrote:

Ian Clark wrote:

On 4/30/07, Casey Duncan <[EMAIL PROTECTED]> wrote:

passible_at = [[True] * 100] * 100 # Create a 2 dimensional list with
an element for each tile

This does not do what you think it would:

Someone more skilled than I can explain *why* the first one does what
it does. I just know one way to get around it (and I'm sure there's a
more elegant solution).


The expression

[True]*100

evaluates to a list that has 100 elements, each pointing to the same
thing (the True object).


Aha! I've seen a problem like this before. I called it the "stripey doom 
error," because when I did a tile-based game and changed one element, 
I'd see a whole stripe of tiles change instead of one. Python has other 
"sticky variable" problems sometimes if you don't think carefully about 
whether something is a reference to another variable. I would sometimes 
end up changing "constants" and having other problems.


>>> coords = [42,100]
>>> copy_of_coords = coords
>>> copy_of_coords[0] += 5000
>>> copy_of_coords
[5042, 100]
>>> coords
[5042, 100] ## Bad!

But:
>>> coords = [42,100]
>>> copy_of_coords = [coords[0],coords[1]]
>>> copy_of_coords[0] += 5000
>>> copy_of_coords
[5042, 100]
>>> coords
[42, 100] ## OK!

When all else fails, copy.deepcopy() seems to make Python understand, "I 
want this to have _the same value_ as X now has, not to be a _reference_ 
to X."


Kris

Re: [pygame] Sprite Collision

[Kris Schnee]

Dave LeCompte (really) wrote:

Actually the correct syntax to address an element would be:

passible_at[x][y]

Not thinking in Python this morning ;^)


Another option is to use a one-dimensional list, which might be slightly 
faster. In my game instead of doing:


tiles = []
for y in range(foo):
tiles.append([])
for x in range(bar):
tiles[-1].append("something")

...which gives a list of lists, I do:

tiles = []
for y in range(foo*foo):
tiles.append("something")

It's then addressed at any x,y location by:
tiles[y*foo + x]

Kris

Re: [pygame] Sprite Collision

[Casey Duncan]

Hehe, yeah. It's because the same inner list object gets repeated for  
each row. You change one row and they all change since they're the  
same list.


I actually like the dictionary suggestion using coordinate tuples as  
keys. That's more elegant. To retrieve the state of a tile you can  
just use:


state = tile_at.get((x, y))

which will return None if the coordinate has no value.

-Casey

On Apr 30, 2007, at 4:50 PM, Ian Clark wrote:


On 4/30/07, Casey Duncan <[EMAIL PROTECTED]> wrote:

passible_at = [[True] * 100] * 100 # Create a 2 dimensional list with
an element for each tile


This does not do what you think it would:

passible_at = [[True] * 3] * 4
passible_at
[[True, True, True], [True, True, True], [True, True, True], [True,  
True, True]]

passible_at[0][0] = False
passible_at

[[False, True, True], [False, True, True], [False, True, True],
[False, True, True]]




One way to get what you're talking about is as follows:

rows = 4
cols = 3
passible_at = []
for _ in xrange(rows):

... passible_at.append( [True] * cols )
...

passible_at
[[True, True, True], [True, True, True], [True, True, True], [True,  
True, True]]

passible_at[0][0] = False
passible_at

[[False, True, True], [True, True, True], [True, True, True], [True,
True, True]]




Someone more skilled than I can explain *why* the first one does what
it does. I just know one way to get around it (and I'm sure there's a
more elegant solution).

Ian

Re: [pygame] Sprite Collision

[Ethan Glasser-Camp]

Ian Clark wrote:
> On 4/30/07, Casey Duncan <[EMAIL PROTECTED]> wrote:
>> passible_at = [[True] * 100] * 100 # Create a 2 dimensional list with
>> an element for each tile
> 
> This does not do what you think it would:
> 
> Someone more skilled than I can explain *why* the first one does what
> it does. I just know one way to get around it (and I'm sure there's a
> more elegant solution).

The expression

[True]*100

evaluates to a list that has 100 elements, each pointing to the same
thing (the True object).

Therefore, the expression

[[True]*100]*100

evaluates to a list that has 100 elements, each pointing to the same
thing (the first list).

This may be easier to explain with the following example:

>>> l = [{}]*3
>>> l
[{}, {}, {}]
>>> l[0]['a'] = 1
>>> l
[{'a': 1}, {'a': 1}, {'a': 1}]

Multiplying a list by a number creates more pointers to the same
objects; if those objects are mutable, and they are changed, the
pointers reflect the new, changed, object.

Your proposed workaround, which uses a repeated call to append,
creates a new element each time through the loop, and so does not
exhibit the same unpleasant behavior.

Ultimately, though, Samuel Mankins's question is dependent on how he
stores his blocks. The suggested data structures (a dict which maps
location->block, or two-dimensional array of blocks) are both suitable
(assuming you don't get bitten by gotchas like this one).

Ethan



signature.asc
Description: OpenPGP digital signature

Re: [pygame] Sprite Collision

[Ian Clark]

On 4/30/07, Casey Duncan <[EMAIL PROTECTED]> wrote:

passible_at = [[True] * 100] * 100 # Create a 2 dimensional list with
an element for each tile


This does not do what you think it would:

passible_at = [[True] * 3] * 4
passible_at

[[True, True, True], [True, True, True], [True, True, True], [True, True, True]]

passible_at[0][0] = False
passible_at

[[False, True, True], [False, True, True], [False, True, True],
[False, True, True]]




One way to get what you're talking about is as follows:

rows = 4
cols = 3
passible_at = []
for _ in xrange(rows):

... passible_at.append( [True] * cols )
...

passible_at

[[True, True, True], [True, True, True], [True, True, True], [True, True, True]]

passible_at[0][0] = False
passible_at

[[False, True, True], [True, True, True], [True, True, True], [True,
True, True]]




Someone more skilled than I can explain *why* the first one does what
it does. I just know one way to get around it (and I'm sure there's a
more elegant solution).

Ian

RE: [pygame] Galcon mods - using pysafe

[Phil Hassey]

Ben,

Sure thing - I've sent you a single player reg. code so you can access the mods.

(Offer still stands to any other pygamers interested.)

Have fun!
- Phil

Ben Woodhead <[EMAIL PROTECTED]> wrote: Hello Phil,

Looks like an interesting project. I would be glad to test out the mod 
system if you are still looking for beta testers.

Ben Woodhead
Telos Productions

>From: Phil Hassey 

>Reply-To: pygame-users@seul.org
>To: pygame 

>Subject: [pygame] Galcon mods - using pysafe
>Date: Fri, 27 Apr 2007 21:27:46 -0700 (PDT)
>
>Hi,
>
>Thanks again to the folks who helped me troubleshoot my pysafe code.  I've 
>now integrated that into Galcon and the game now the ability to create 
>Galcon mods.  Here's the announcement I sent out:
>
>http://www.imitationpickles.org/galcon/download.html
>
>The new mods system in Galcon is in "beta" now. It works, but use it at 
>your own risk! To check it out press 'm' on the main menu (there isn't a 
>clickable link) and you'll be sent to a page where you can see the 3 mods 
>I've included for you to play with. They are a version of the "Classic" 
>game, a map editor, and a mini game called nibbles. All of these mods 
>include full source, so now you can modify those to have different game 
>play different bots, different maps, etc. Over time I'll be adding some 
>guides to the website and more tutorial-like examples to it. For now, you 
>just have some raw stuff to work with.
>
>To add your own mods, go to:
>Windows: c:\program files\galcon\mods\
>MacOSX: /Applications/Galcon.app/Contents/Resources/mods/
>Linux: ./galcon/mods
>
>This is all very *experimental* so things may not work perfectly. Also, 
>since this is in "beta" some of the Galcon API, is subject to change over 
>time. If you find any bugs or problems, please post them to the Galcon 
>forums in the new Mods topic. I'm very excited to see what people are able 
>to build!
>
>... the mods feature is only available to registered Galcon users ... but 
>if you asked me really nicely, I might be able to slip you a reg. code for 
>access to this feature :)
>
>Thanks!
>Phil
>
>
>-
>Ahhh...imagining that irresistible "new car" smell?
>  Check outnew cars at Yahoo! Autos.

_
Win a webcam! Nominate your friend’s Windows Live Space in the Windows Live 
Spaces Sweetest Space Contest and you both could win! 
http://www.microsoft.com/canada/home/contests/sweetestspace/default.aspx





   
-
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.

Re: [pygame] pygame and Ubuntu

[Charles Joseph Christie II]

On Monday 30 April 2007 12:09:10 pm James Paige wrote:
> On Sun, Apr 29, 2007 at 05:38:33PM -0400, Jason Coggins wrote:
> > I am trying to run them from the desktop by double clicking on them then
> > selecting either run or run in terminal from the box that pops up.  I
> > tried right clicking on the program to select "open with python" but that
> > was not an option.  When I right clicked and selected "open with another
> > application" python was not listed on the application list.  I know I
> > have python 2.5 installed because it states so on the synamtic package
> > manager.
> >
> > Jason
>
> I have had a lot of problems with this too. The problem is that most
> pygame games assume that that the current working directory has been set
> to the directory where the .py file is located. But when you
> double-click and pick "run" or right-click and pick "open with python",
> the current working directory does NOT get set, and the game cannot find
> its data files.
>
> What I do for my own games is something similar to this:
>
>   import os
>   import sys
>   os.chdir(os.path.dirname(sys.argv[0]))
>
> That makes sure that the data files will always be found where you
> expect them.
>
> ---
> James Paige

That's good information. I'll have to remember to make my game do that too!

Re: [pygame] Sprite Collision

[Samuel Mankins]

This would require defining every block to be not passable, right? I'd 
rather not do that, because I would be defining the terrain twice... I 
think I'll stick with the spritecollide stuff.

Thanks anyway!

Casey Duncan wrote:
If you keep track of which tiles are passible in an list, you only 
need to consider the tiles surrounding a given monster, which should 
not be a problem performance-wise. In fact, you only need to consider 
the tiles that the monster wants to move into, and if the first one is 
passible then that's all you need to test.


Let's say you have a map that is 100 x 100 tiles. You can initialize a 
list for it like so:


passible_at = [[True] * 100] * 100 # Create a 2 dimensional list with 
an element for each tile


(then populate it however you create your map, setting the elements 
that are not passable to some True value). So if there's a big boulder 
at x=25, y=30 you would do:


passible_at[25, 30] = False

let's say you want to see if you can pass through a given x, y 
coordinate on the map, just do this:


if passible_at[x, y]:
# can go there, tally ho!
else:
# can't go there, maybe consider another direction

You could even get fancy and have varying degrees of passibility, like 
mountains or swamp or debris that can be passed through, but takes 
longer to do so. This would be done by assigning a passibility "score" 
to each map location that tells how many turns it takes to get 
through. The value None could mean "impassible".


Another question is are we talking about navigating around small 
obstacles (relative to the map) or through a more complex system of 
rooms with long walls or other large obstructions with only small 
pathways through? If it's the latter you'll probably want to use a 
path finding algorithm so the monster can figure out how to navigate 
through the rooms from point a to point b (an example implementation 
of this was posted a week or so ago). If you do have "rooms", but the 
monsters don't ever leave the room they start in on their own, this 
might not be necessary, however.


-Casey

On Apr 30, 2007, at 6:56 AM, Samuel Mankins wrote:

Now that my AI is chasing the Ninja around, I'd like to make it so 
that when they bump into a block, they "slide" around it. I figured 
I'd do this by having it find out where the block is in relation to 
the monster, and then stop moving in the direction that was causing 
it to bump into the block. But I don't want to say "for block in 
block_group" because that eats up too much CPU, so my question is, 
how can I figure out where the block is without using that? Is there 
an easier way to solve the problem?
I tried just using ifs to do it (It looked something like: If 
self.x_dir == 1 and self.y_dir == 1, self.x_dir = 1 and self.y_dir = 
0) but then the monsters just floated over the blocks.

Thanks!

RE: [pygame] Galcon mods - using pysafe

[Ben Woodhead]

Hello Phil,

Looks like an interesting project. I would be glad to test out the mod 
system if you are still looking for beta testers.


Ben Woodhead
Telos Productions


From: Phil Hassey <[EMAIL PROTECTED]>
Reply-To: pygame-users@seul.org
To: pygame 
Subject: [pygame] Galcon mods - using pysafe
Date: Fri, 27 Apr 2007 21:27:46 -0700 (PDT)

Hi,

Thanks again to the folks who helped me troubleshoot my pysafe code.  I've 
now integrated that into Galcon and the game now the ability to create 
Galcon mods.  Here's the announcement I sent out:


http://www.imitationpickles.org/galcon/download.html

The new mods system in Galcon is in "beta" now. It works, but use it at 
your own risk! To check it out press 'm' on the main menu (there isn't a 
clickable link) and you'll be sent to a page where you can see the 3 mods 
I've included for you to play with. They are a version of the "Classic" 
game, a map editor, and a mini game called nibbles. All of these mods 
include full source, so now you can modify those to have different game 
play different bots, different maps, etc. Over time I'll be adding some 
guides to the website and more tutorial-like examples to it. For now, you 
just have some raw stuff to work with.


To add your own mods, go to:
Windows: c:\program files\galcon\mods\
MacOSX: /Applications/Galcon.app/Contents/Resources/mods/
Linux: ./galcon/mods

This is all very *experimental* so things may not work perfectly. Also, 
since this is in "beta" some of the Galcon API, is subject to change over 
time. If you find any bugs or problems, please post them to the Galcon 
forums in the new Mods topic. I'm very excited to see what people are able 
to build!


... the mods feature is only available to registered Galcon users ... but 
if you asked me really nicely, I might be able to slip you a reg. code for 
access to this feature :)


Thanks!
Phil


-
Ahhh...imagining that irresistible "new car" smell?
 Check outnew cars at Yahoo! Autos.


_
Win a webcam! Nominate your friend’s Windows Live Space in the Windows Live 
Spaces Sweetest Space Contest and you both could win! 
http://www.microsoft.com/canada/home/contests/sweetestspace/default.aspx

Re: [pygame] sound crackling and fmod

[John Popplewell]

On Mon, Apr 30, 2007 at 02:55:27AM -0700, Andrew Pape wrote:
> 
> Could it be an OS problem? I'm using Ubuntu Linux (Feisty Fawn)
> but others on the mailing list have said there's a bug in the Windows
> Pygame that causes sound crackle too. Any other ideas?
> 
It could be a problem with the OS sound configuration. I've traditionally
always had problems with ALSA and the snd_intel8x0 and snd_ac97_* drivers.

Try running this in a shell (I'm running Gentoo at the moment):

$ lsmod | grep snd
...
snd_intel8x0   30524  1
snd_ac97_codec 99908  2 snd_ice1712,snd_intel8x0
snd_ac97_bus1824  1 snd_ac97_codec
...

Try running this in a shell (part of the 'pciutils' package):

$ /usr/sbin/lspci
...
00:1f.5 Multimedia audio controller: Intel Corporation 82801AA AC'97 Audio (rev 
02)
...

If you've got hardware something like this, you might consider using the
"/etc/asound.conf" file from here:

http://johnnypops.demon.co.uk/debian/index.html#alsa

which I always end up using whatever Linux distribution I install. You'd only
need the first part that starts with:

# Configuration for on-board AC97 'turkey'

... down to the bit that starts:
# Configuration for the Terratec EWS-88

As I understand it, the hardware only works at 48Khz and the default ASLA
'dmix' settings (which does the conversion) don't quite work with my particular
hardware combination.

Many other apps work ok without it, but apps using SDL often seems to have 
problems.
(this is on old hardware: a PIII with a re-capped motherboard),

cheers,
John.

Re: [pygame] Sprite Collision

[Dave LeCompte (really)]

> Actually the correct syntax to address an element would be:
>
> passible_at[x][y]
>
> Not thinking in Python this morning ;^)

The original syntax - passable_at[x,y] - is something that I've used
before; use a dictionary keyed on location instead of nested arrays. This
can be more space efficient if you're only storing things that sparsely
populate your world. The dictionary lookup might even be faster, but you'd
have to profile that for your specific case to know for sure.

Of course, abstracting your game code from the underlying representation
gives you some flexibility to optimize later on:


g_passable_dict={}

def is_passable(x,y):
  return g_passable_dict.get((x,y),False)

def make_passable(x, y, isPassable):
  if isPassable:
g_passable_dict[(x,y)]=True
  else:
try:
  g_passable_dict.pop((x,y))
except KeyError:
  # was already unpassable - up to you if this is OK
  pass


-

However, if I was trying to handle more than a hundred or so objects, I'd
quickly switch over to a system that can do localized queries more
efficiently.

Keywords you might look into:
quadtrees
octtrees
k-d trees
spatial hashing


Hope this helps,
Dave LeCompte

Re: [pygame] Sprite Collision

[Casey Duncan]

Actually the correct syntax to address an element would be:

passible_at[x][y]

Not thinking in Python this morning ;^)

-Casey

On Apr 30, 2007, at 9:39 AM, Casey Duncan wrote:

If you keep track of which tiles are passible in an list, you only  
need to consider the tiles surrounding a given monster, which  
should not be a problem performance-wise. In fact, you only need to  
consider the tiles that the monster wants to move into, and if the  
first one is passible then that's all you need to test.


Let's say you have a map that is 100 x 100 tiles. You can  
initialize a list for it like so:


passible_at = [[True] * 100] * 100 # Create a 2 dimensional list  
with an element for each tile


(then populate it however you create your map, setting the elements  
that are not passable to some True value). So if there's a big  
boulder at x=25, y=30 you would do:


passible_at[25, 30] = False

let's say you want to see if you can pass through a given x, y  
coordinate on the map, just do this:


if passible_at[x, y]:
# can go there, tally ho!
else:
# can't go there, maybe consider another direction

You could even get fancy and have varying degrees of passibility,  
like mountains or swamp or debris that can be passed through, but  
takes longer to do so. This would be done by assigning a  
passibility "score" to each map location that tells how many turns  
it takes to get through. The value None could mean "impassible".


Another question is are we talking about navigating around small  
obstacles (relative to the map) or through a more complex system of  
rooms with long walls or other large obstructions with only small  
pathways through? If it's the latter you'll probably want to use a  
path finding algorithm so the monster can figure out how to  
navigate through the rooms from point a to point b (an example  
implementation of this was posted a week or so ago). If you do have  
"rooms", but the monsters don't ever leave the room they start in  
on their own, this might not be necessary, however.


-Casey

On Apr 30, 2007, at 6:56 AM, Samuel Mankins wrote:

Now that my AI is chasing the Ninja around, I'd like to make it so  
that when they bump into a block, they "slide" around it. I  
figured I'd do this by having it find out where the block is in  
relation to the monster, and then stop moving in the direction  
that was causing it to bump into the block. But I don't want to  
say "for block in block_group" because that eats up too much CPU,  
so my question is, how can I figure out where the block is without  
using that? Is there an easier way to solve the problem?
I tried just using ifs to do it (It looked something like: If  
self.x_dir == 1 and self.y_dir == 1, self.x_dir = 1 and self.y_dir  
= 0) but then the monsters just floated over the blocks.

Thanks!

Re: [pygame] Sprite Collision

[Casey Duncan]

If you keep track of which tiles are passible in an list, you only  
need to consider the tiles surrounding a given monster, which should  
not be a problem performance-wise. In fact, you only need to consider  
the tiles that the monster wants to move into, and if the first one  
is passible then that's all you need to test.


Let's say you have a map that is 100 x 100 tiles. You can initialize  
a list for it like so:


passible_at = [[True] * 100] * 100 # Create a 2 dimensional list with  
an element for each tile


(then populate it however you create your map, setting the elements  
that are not passable to some True value). So if there's a big  
boulder at x=25, y=30 you would do:


passible_at[25, 30] = False

let's say you want to see if you can pass through a given x, y  
coordinate on the map, just do this:


if passible_at[x, y]:
# can go there, tally ho!
else:
# can't go there, maybe consider another direction

You could even get fancy and have varying degrees of passibility,  
like mountains or swamp or debris that can be passed through, but  
takes longer to do so. This would be done by assigning a passibility  
"score" to each map location that tells how many turns it takes to  
get through. The value None could mean "impassible".


Another question is are we talking about navigating around small  
obstacles (relative to the map) or through a more complex system of  
rooms with long walls or other large obstructions with only small  
pathways through? If it's the latter you'll probably want to use a  
path finding algorithm so the monster can figure out how to navigate  
through the rooms from point a to point b (an example implementation  
of this was posted a week or so ago). If you do have "rooms", but the  
monsters don't ever leave the room they start in on their own, this  
might not be necessary, however.


-Casey

On Apr 30, 2007, at 6:56 AM, Samuel Mankins wrote:

Now that my AI is chasing the Ninja around, I'd like to make it so  
that when they bump into a block, they "slide" around it. I figured  
I'd do this by having it find out where the block is in relation to  
the monster, and then stop moving in the direction that was causing  
it to bump into the block. But I don't want to say "for block in  
block_group" because that eats up too much CPU, so my question is,  
how can I figure out where the block is without using that? Is  
there an easier way to solve the problem?
I tried just using ifs to do it (It looked something like: If  
self.x_dir == 1 and self.y_dir == 1, self.x_dir = 1 and self.y_dir  
= 0) but then the monsters just floated over the blocks.

Thanks!

Re: [pygame] Sprite Collision

[Samuel Mankins]

I assume it's eating up CPU, it's doing something so that the game slows 
down the point where updates take about a half a second. I don't have 
thousands of blocks, but I do have a fair amount, something in the 
vicinity of fifty, and three monsters.
I'm using for so I can access the attributes of the individual blocks, 
not to detect the collision. Is there another way?

Thanks!

Jason Massey wrote:
Eats up too much CPU?  How do you know? Have you profiled?  Do you 
have thousands of blocks?


I'd get it working first, with whatever solution works before you 
start worrying about optimizing.  Also you can always exit the for 
loop when you find a collision so you don't have to iterate over the 
whole list.


On 4/30/07, *Samuel Mankins* <[EMAIL PROTECTED] 
> wrote:


Now that my AI is chasing the Ninja around, I'd like to make it so
that
when they bump into a block, they "slide" around it. I figured I'd do
this by having it find out where the block is in relation to the
monster, and then stop moving in the direction that was causing it to
bump into the block. But I don't want to say "for block in
block_group"
because that eats up too much CPU, so my question is, how can I
figure
out where the block is without using that? Is there an easier way to
solve the problem?
I tried just using ifs to do it (It looked something like: If
self.x_dir
== 1 and self.y_dir == 1, self.x_dir = 1 and self.y_dir = 0) but then
the monsters just floated over the blocks.
Thanks!

Re: [pygame] pygame and Ubuntu

[James Paige]

On Sun, Apr 29, 2007 at 05:38:33PM -0400, Jason Coggins wrote:
> I am trying to run them from the desktop by double clicking on them then 
> selecting either run or run in terminal from the box that pops up.  I tried 
> right clicking on the program to select "open with python" but that was not 
> an option.  When I right clicked and selected "open with another 
> application" python was not listed on the application list.  I know I have 
> python 2.5 installed because it states so on the synamtic package manager.
> 
> Jason

I have had a lot of problems with this too. The problem is that most 
pygame games assume that that the current working directory has been set 
to the directory where the .py file is located. But when you 
double-click and pick "run" or right-click and pick "open with python", 
the current working directory does NOT get set, and the game cannot find 
its data files.

What I do for my own games is something similar to this:

  import os
  import sys
  os.chdir(os.path.dirname(sys.argv[0]))

That makes sure that the data files will always be found where you 
expect them.

---
James Paige

Re: [pygame] pygame and Ubuntu

[Charles Christie]

Solarwolf is REALLY awesome. You could stay addicted to that for hours!

On 4/30/07, Horst JENS <[EMAIL PROTECTED]> wrote:


On Sun, 2007-04-29 at 21:23 +0200, DR0ID wrote:

> I have installed ubuntu 7.04 recently and found pygame in the synaptics
> system. (it had a somewhat strange name, cant remember sorry)
>


The name is python-pygame. Use the search function of Synaptics.

Also check out the game "solarwolf", that is written in pygame.

-Horst

Re: [pygame] Drawing Bullets

[Charles Christie]

so, I should have pygame.display.update(dirtyrects, bullets) in my main loop
if I have two groups of sprites to watch (bullets and dirtyrects) instead of
two separate pygame.display.update functions, right? The docs say to do that
but they never actually say what the syntax for it is. Do I separate them
with commas or spaces or what? Someone should say how to pass it multiple
lists of sprite groups to update.

On 4/28/07, Charles Joseph Christie II <[EMAIL PROTECTED]> wrote:


On Saturday 28 April 2007 12:53:38 pm DR0ID wrote:
> Charles Joseph Christie II schrieb:
> > On Saturday 28 April 2007 11:45:15 am DR0ID wrote:
> >> Charles Joseph Christie II schrieb:
> >>> On Saturday 28 April 2007 01:28:38 am Kris Schnee wrote:
>  Charles Christie wrote:
> > Well, bullets just seem to be a sticking point for me...
> 
>  Stick with it!
> 
> > 1. bullet cleanup (self.kill, etc.) which isn't important to me
right
> > now, as the demo won't be running for an extended period, and when
it
> > does it'll be running on a monstrous beast of a computer that can
> > probably handle the crappy coding.
> > 2. Drawing bullets (pygame.update.dirtyrects, etc) which is VERY
> > important to me right now.
> 
>  I don't think you need a kill function. What I did in my shooter
game
>  was to have the bullets stored in two lists, and then every frame:
> 
>  self.player_bullets = [bullet for bullet in self.player_bullets if
>  bullet.ttl > 0]
>  self.enemy_bullets = [bullet for bullet in self.enemy_bullets if
>  bullet.ttl > 0]
> 
>  This filtering gets rid of the ones whose time-to-live is expired,
due
>  to Python's automatic garbage-collection.
> 
> > So, I tried to load an image for the bullets, and that didn't work
> > either. What happened was that it couldn't load the image...
probably
> > because it doesn't exist. Which it does, though.
> >
> > It's in the project directory under the folder img/Bullet.png.
When I
> > put img/Bullet.png into the load_image function it says it can't
load
> > the image! I tried it with front and back slashes and it didn't
work.
> 
>  Yeah, Python doesn't automatically handle path names. Try
>  os.path.join, as in:
> 
>  import os
>  filename = os.path.join("img","Bullet.png")
>  my_image = pygame.image.load(filename).convert_alpha()
> 
>  As I understand it, os.path.join attaches the directory terms (any
>  number of them) according to whatever format is appropriate for the
>  OS.
> 
> > After I get the image loaded, however, I can't add the bulletlist
to
> > my list of dirtyrects to update... The dirtyrect doesn't read from
> > lists! How do I get pygame.sprite.RenderUpdates to display my
bullets
> > on the screen?
> 
>  I haven't messed with dirty rectangle functions myself, so this one
is
>  beyond me.
> 
>  Kris
> >>>
> >>> Woohoo! Thanks! I'll try this ASAP. Still need to figure out how to
get
> >>> the dirtyrects thing sorted out though...
> >>
> >> Hi
> >>
> >> if you use Renderupdates then you have to do the following:
> >>
> >> make an instance of the RenderUpdateGroup
> >> add as many sprites you want to it
> >>
> >> then in each frame of you game:
> >>renderUGroup.clear()
> >># update your sprites in here
> >>dirty_rects = renderUGroup.draw(screen)
> >>display.update(dirty_rects)
> >>
> >> It should be more or less that thing. Try to look at an example like
> >> "chimp" on the pagame website.
> >>
> >> Sorry, about that short and quick instruction, but I have not much
time
> >> at the moment.
> >>
> >> ~DR0ID
> >
> > No problem, any help is appreciated! Does RenderUpdateGroup read from
> > lists, though?
>
> Hi again
>
> well, the pygame.sprite.RenderUpdates is like your list, it is a
> container for sprites. I would inherit from Sprite to make the Bullet:
>
> class myBullet(pygame.sprite.Sprite):
> def __init__(self):
>   pygame.sprite.Sprite.__init__(self)
>   
>
> Then in your code you do:
>
> #instanciate Render group
> rg = pygame.sprite.RenderUpdates()
> # add some Bullets
> for i in range(100):
> rg.add( myBullet() )
>
> # in main loop, to draw all bullet in rg
> rg.clear()
> rg.update()
> dirty_rects = rg.draw(screen)
> pygame.display.update(dirty_rects)
>
> Naturally any Bullet in the group will be updated and drawen on screen.
> I would just instanciate a new Bullet when needed and add it to the rg
> group (so it get visible). If you need to go through the bullet (for
> collisions detection for example) you can use rg.sprites() which returns
> a list with the bullet sprites.
>
> I hope that helps a better. I hope I havent told you something incorect,
> because it is a while I have used the pygame.sprite groups.
>
> ~DR0ID

now THAT'S some good information. I owe you  one too, DR0ID!

Re: [pygame] Sprite Collision

[Jason Massey]

Eats up too much CPU?  How do you know? Have you profiled?  Do you have
thousands of blocks?

I'd get it working first, with whatever solution works before you start
worrying about optimizing.  Also you can always exit the for loop when you
find a collision so you don't have to iterate over the whole list.

On 4/30/07, Samuel Mankins <[EMAIL PROTECTED]> wrote:


Now that my AI is chasing the Ninja around, I'd like to make it so that
when they bump into a block, they "slide" around it. I figured I'd do
this by having it find out where the block is in relation to the
monster, and then stop moving in the direction that was causing it to
bump into the block. But I don't want to say "for block in block_group"
because that eats up too much CPU, so my question is, how can I figure
out where the block is without using that? Is there an easier way to
solve the problem?
I tried just using ifs to do it (It looked something like: If self.x_dir
== 1 and self.y_dir == 1, self.x_dir = 1 and self.y_dir = 0) but then
the monsters just floated over the blocks.
Thanks!

Re: [pygame] sound crackling and fmod

[Kamilche]

He's right - pygame.mixer.pre_init and all that doesn't appear to help, 
at least on my Windows 2000 machine. I left it in just in case it helps 
on some platforms tho.


I found what DID help, was setting the channel volume down to .5. One 
song I have perfectly illustrated the problem, when I played it on both 
pygame and windows media player. In Pygame, it sounded like it was 
overdriving the computer speakers, but when I played it in Windows Media 
Player, it was perfect, but quieter. I put 2 and 2 together, and reduced 
the volume, and got much better results.


The final result is a little worse than Windows Media Player, but at 
least it's not grating to the ears any more.


--Kamilche

Re: [pygame] about the great 100% CPU thread

[Kamilche]

Laura Creighton wrote:

My note about that did not get out due to my company and domain name
changing.

The pypy project has destroyed several machines so far in its 2 year history.
Mostly laptops, but at least one tower as well.  We're using all the CPU for
extended periods of time, and when we talk to manufacturers about it,
often about claims because the machine is under warrantee, they all ask
us what the heck we have been doing.  We tell them.  And they tell us that
their machines are not designed to run at 100% CPU for extended periods of
time.

However, should James Paige decide that despite all of this his dual
mac _still_ isn't having enough fun, we could send him some nightly
pypy builds.  That ought to do the trick. :-)

Laura






No way! It's amazing that computer manufacturers build a machine that 
can't run full-bore 24 hours a day, 365 days a year. Well, I can believe 
it for laptops, sure, they've always had a heating problem, but towers 
too? Planned obsolescence sucks. :-P


I hope you got them all replaced under warranty.

--Kamilche

[pygame] Sprite Collision

[Samuel Mankins]

Now that my AI is chasing the Ninja around, I'd like to make it so that 
when they bump into a block, they "slide" around it. I figured I'd do 
this by having it find out where the block is in relation to the 
monster, and then stop moving in the direction that was causing it to 
bump into the block. But I don't want to say "for block in block_group" 
because that eats up too much CPU, so my question is, how can I figure 
out where the block is without using that? Is there an easier way to 
solve the problem?
I tried just using ifs to do it (It looked something like: If self.x_dir 
== 1 and self.y_dir == 1, self.x_dir = 1 and self.y_dir = 0) but then 
the monsters just floated over the blocks.

Thanks!

[pygame] about the great 100% CPU thread

[Laura Creighton]

My note about that did not get out due to my company and domain name
changing.

The pypy project has destroyed several machines so far in its 2 year history.
Mostly laptops, but at least one tower as well.  We're using all the CPU for
extended periods of time, and when we talk to manufacturers about it,
often about claims because the machine is under warrantee, they all ask
us what the heck we have been doing.  We tell them.  And they tell us that
their machines are not designed to run at 100% CPU for extended periods of
time.

However, should James Paige decide that despite all of this his dual
mac _still_ isn't having enough fun, we could send him some nightly
pypy builds.  That ought to do the trick. :-)

Laura

Re: [pygame] sound crackling and fmod

[�������]

Dude

Do the following (this time AFTER the pygame.init()):

pygame.mixer.quit()
pygame.mixer.init(44100,-16,1,4096)

report back
Takis



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [pygame] sound crackling and fmod

[Andrew Pape]

Hi,

- Original Message 
From: Παναγιώτης Τσιμπέρης <[EMAIL PROTECTED]>
To: pygame-users@seul.org
Sent: Monday, 30 April, 2007 6:23:34 PM
Subject: Re: [pygame] sound crackling and fmod

Ooopss...

Just before the pygame.init() , write:

pygame.mixer.pre_init(22050,-16,1,4096)

just that.

I've tried that, and unfortunately it doesn't solve the problem - I still get 
crackling music. Someone else suggested that I don't use pygame.init() because 
it inits everything, and that I should only init what I want, and one thing at 
a time (ie init display, init mixer). Unfortunately, that hasn't worked either. 
I reckon I've tried everything. I'm totally new to Python and Pygame and am 
really stuck here. Could it be an OS problem? I'm using Ubuntu Linux (Feisty 
Fawn) but others on the mailing list have said there's a bug in the Windows 
Pygame that causes sound crackle too. Any other ideas?

Cheers,

Andrew.






Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [pygame] sound crackling and fmod

[�������]

Ooopss...

Just before the pygame.init() , write:

pygame.mixer.pre_init(22050,-16,1,4096)

just that.




__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [pygame] sound crackling and fmod

[Luke Paireepinart]

>>1) why am I getting the crackling when running the
>>demos?
>open the game's code and change in the mixer's
>initiation, the size of the buffer - it's the last
>parameter.  For instance if you find:
>pygame.mixer.init()
>then replace with:
>pygame.mixer.init(22050,-16,1,2048)

Unfortunately, I still can't solve the problem. The demo code has no 
call to pygame.mixer.init. Instead, the code (the Shadow of the Beast 
animation on the website) looks like:

pygame.init()
[snip irrelevant code]
and then the main game loop.

There is no call in the same code to pygame.mixer(), so I added one as 
you suggested, and even tried it in several places, like after 
pygame().init, after the screen opening, after the call to start the 
music, and so on, changing only one line for each test, but had no 
luck. I checked out the webpage on the use of the mixer, and found 
there's a pre_init() call that can be used before pygame.init(). I 
even tried that, but it made no difference. I then decided to use 
Synaptic Package Manager to re-apply the libsdl mixer library, in case 
that was the problem. Still no luck.
pygame.init() initializes a lot of things.  _remove_ 'pygame.init()' and 
initialize everything separately.

Just initialize what you need.
F.E.

pygame.display.init()
#put your mixer init here
# maybe pygame.joystick.init or something.

#then use it regularly.


see if that works.
-Luke

Re: [pygame] sound crackling and fmod

[Andrew Pape]

Hi,

>>1) why am I getting the crackling when running the
>>demos?

>open the game's code and change in the mixer's
>initiation, the size of the buffer - it's the last
>parameter.  For instance if you find:
>pygame.mixer.init()
>then replace with:
>pygame.mixer.init(22050,-16,1,2048)
>or even:
>pygame.mixer.init(22050,-16,1,4096)

>that should fix it.

Unfortunately, I still can't solve the problem. The demo code has no call to 
pygame.mixer.init. Instead, the code (the Shadow of the Beast animation on the 
website) looks like:

...
pygame.init()

screen = pygame.display.set_mode((640, 480))
pygame.display.set_caption("Shadow of the Beast")

s1 = pygame.image.load(os.path.join("resources", "bgd1_ciel.png"))
s2 = pygame.image.load(os.path.join("resources", "bgd2_montagnes.png"))
s3 = pygame.image.load(os.path.join("resources", "bgd3_sol1.png"))
s4 = pygame.image.load(os.path.join("resources", "bgd4_sol2.png"))
s5 = pygame.image.load(os.path.join("resources", "bgd5_sol3.png"))
s6 = pygame.image.load(os.path.join("resources", "sprite_nuages1.png"))
s7 = pygame.image.load(os.path.join("resources", "sprite_nuages2.png"))
s8 = pygame.image.load(os.path.join("resources", "sprite_nuages3.png"))
s9 = pygame.image.load(os.path.join("resources", "sprite_nuages4.png"))
s10 = pygame.image.load(os.path.join("resources", "sprite_barriere.png"))
s11 = pygame.image.load(os.path.join("resources", "fireworks.png"))
s12 = pygame.image.load(os.path.join("resources", "sprite_arbre.png"))
s13 = pygame.image.load(os.path.join("resources", "scrolltext.png"))

music = pygame.mixer.Sound(os.path.join("resources", "remix.ogg")).play()
pygame.mouse.set_visible(False)

and then the main game loop.

There is no call in the same code to pygame.mixer(), so I added one as you 
suggested, and even tried it in several places, like after pygame().init, after 
the screen opening, after the call to start the music, and so on, changing only 
one line for each test, but had no luck. I checked out the webpage on the use 
of the mixer, and found there's a pre_init() call that can be used before 
pygame.init(). I even tried that, but it made no difference. I then decided to 
use Synaptic Package Manager to re-apply the libsdl mixer library, in case that 
was the problem. Still no luck. 

By the way, as I mentioned in the original post, I'm using ubuntu Linux.

Any help would be much appreciated.

Thanks in advance,

Andrew.






Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [pygame] pygame and Ubuntu

[Horst JENS]

On Sun, 2007-04-29 at 21:23 +0200, DR0ID wrote:

> I have installed ubuntu 7.04 recently and found pygame in the synaptics 
> system. (it had a somewhat strange name, cant remember sorry)
> 


The name is python-pygame. Use the search function of Synaptics.

Also check out the game "solarwolf", that is written in pygame.

-Horst