Re: [pygame] how to change my subscription settings?
http://blog.gmane.org/gmane.comp.python.pygame You can view everything there
Re: [pygame] Re: sprite.spritecollide
Follow up with this if len(colliding_with) is not 0: for sprite in colliding_with: #will go through each sprite in colliding_with #if your sprite has a unique ID like self.id try printing print sprite.id
Re: [pygame] sprite.spritecollide
colliding_with = pygame.sprite.spritecollide(x,y, 0) colliding_with is a list of all objects x is colliding in y
Re: [pygame] Pygame games run slowly :(
Toni, you make a good argument, but some of your points are a bit misleading. As for games not needing a lot of resources, your kind of off. Only reason ps3s have 512MB is that it doesn't have to worry about the many processes a computer OS requires. Plus the ram is top of the line (gddr3 / xdr) and isn't really comparable to normal computer ram. I agree that nothing beats efficient coding, but that can only go so far. Sooner or later, you still have to upgrade. I personally am a fan of simple games (#1 game is block dude.. anyone who had a ti83 or 89 should know what it is). But you can't expect game programmers to all stay low tech. Yes small mini computers and smart phones are becomming popular, but so are stronger laptops and computers. As for the slow game in question (http://www.pygame.org/project/596/) the game designer does say "Thanks! And yes, framerate is definitely an issue on (dare I say) lower-end computers" Btw, the latest budget computers have at least 2.X GHz CPUs. So yea.. it's time to upgrade.
Re: [pygame] Rect collision by direction
Diagonal collision detection seems to get a lot of people including myself the first time. If you haven't fixed it yet, the remedy will most likely require you to do 2 collision detections instead 1. Without looking at your code, I'm gonna assume your doing collision detection on both axis at once. What you should do instead is first check for collision on one axis, figure out whats happening, then do a collision detection for the other axis.
Re: [pygame] A silly request
I thought it was put there to show that a good pygame developer != good artist
Re: [pygame] pygame.quit() not working after upgrade to python 2.6
Have you tried if event.type == pygame.QUIT: sys.exit() On Tue, Apr 28, 2009 at 1:22 AM, Thadeus Burgess wrote: > Is there any reason pygame.quit() hangs the application up? > > I am running python 2.6 on Ubuntu. > > It works on python 2.6 in windows. > > What, if any information could I provide to help track down the culprite? > > -Thadeus > > http://thadeusb.com > > >
Re: [pygame] Never seen this before
If the problems fixed, yay. If not, you should put up most/all your source so it's easier for people to see whats happening.
Re: [pygame] move problems
Yea... Jakes method would do.. or you can just simplify it spaceship_speed = 10 if keys[K_LEFT]: x_move += -spaceship_speed if keys[K_RIGHT]: x_move += spaceship_self.speed rect = rect.move(x_move, 0) BTW... spaceship.speed=(spaceship.speed[0]-10, spaceship.speed[1]) is unnecessary. No point in rewriting the whole list when your only changing one part On Thu, Apr 9, 2009 at 9:56 PM, Jake b wrote: > Print out .speed to see what the values are. > > example: in IDLE > > >>> from euclid import Vector2 > > >>> class Ship(): > def __init__(self): > self.speed = Vector2(0,0) > self.loc = Vector2(0,0) > def accel(self, xvel, yvel): > self.speed += Vector2(xvel, yvel) > def update(self): > self.loc += self.speed > def __repr__(self): return "s=%s, l=%s" % (self.speed, self.loc ) > >>> s = Ship() > >>> s > s=Vector2(0.00, 0.00), l=Vector2(0.00, 0.00) > > >>> s.accel( 10, 0 ) > >>> s > s=Vector2(10.00, 0.00), l=Vector2(0.00, 0.00) > > >>> s.update() > >>> s > s=Vector2(10.00, 0.00), l=Vector2(10.00, 0.00) > > >>> s.update() > >>> s > s=Vector2(10.00, 0.00), l=Vector2(20.00, 0.00) > > -- > Jake >
Re: [pygame] Sprite group drawing with offset
I'm reading this from my iPhone so I can't verify that this is my working version, but I can tell that it's missing something important. I basically changed the sprite.RenderUpdates.draw() to accept a second and third argument "offsets [x,y]". By default they are set to 0,0 (this is whats missing... Should be def draw(self,screen, offset = [0,0])) so there would be no argument/type error when older code uses the draw method without passing the offsets. I felt by letting the draw method accept an offset, it would be easier to shift a whole sprite group at once while adding sprite rects to a rectlist. On 3/10/09, Thiago Chaves wrote: > Hi, > > I just had a conversation with some people at #pygame on IRC, and it > seems that at least me and unlucky777 agree that it would be cool to > be able to pass an offset value to the drawing function on pygame > sprite groups. The idea is that people who think about a "camera" (or > when writing games have something more natural to work with). > > Anyway, unlucky777 came up wth some modified renderUpdates sprite > group to solve a scrolling problem, while I caught myself putting > offset information on the update method of my sprite classes so I > could deal with the same problem (but apparently in an uglier way). > > I'm attaching unlycky777's relevant piece of code, and also what I > came up with. Personally, I like unlucky's idea better. > > Any thoughts? > > -Thiago >
