[pygame] split newbie strikes back
Hi all, Following your wise advice, I have used the split screen technique that Casey wrote about, and everything worked great ... until I tried to create sprites that spawned on the bottom screen, to which it politely refuses. All the sprites are instantiated in the top screen, and I have no idea why (I think it's because this subsurface method creates a child of the top_screen, and then when assigning random positions, it all gets messed up). Anyway, if any can help, my code is here: http://tinyurl.com/349wk9 thanks for the help! mundial PS: any feedback on the (messy, ugly) code, is very welcome
Re: [pygame] split newbie strikes back
Mundial 82 wrote: Following your wise advice, I have used the split screen technique that Casey wrote about, and everything worked great ... until I tried to create sprites that spawned on the bottom screen, to which it politely refuses. All the sprites are instantiated in the top screen, and I have no idea why (I think it's because this subsurface method creates a child of the top_screen, and then when assigning random positions, it all gets messed up). playerTop.draw(screen) playerBot.draw(screen) topPoints.draw(screen) botPoints.draw(screen) Try changing to: playerTop.draw(top_screen) playerBot.draw(bot_screen) topPoints.draw(top_screen) botPoints.draw(bot_screen) etc. Also, your check_bounds for the Square class doesn't make sense. The purpose of using subsurfaces is that you don't have to worry about where the sprite.rect is relative to the parent surface, only the child surface. I changed that to this: def checkBounds(self): if self.rect.centerx self.screen.get_width(): self.rect.centerx = 0 if self.rect.centerx 0: self.rect.centerx = self.screen.get_width() if self.rect.centery self.screen.get_height(): self.rect.centery = 0 if self.rect.centery 0: self.rect.centery = self.screen.get_height() I'd be a little wary of blending your sprite-drawing code and your physics code like this, though. Hope this helps! Ethan signature.asc Description: OpenPGP digital signature
Re: [pygame] split newbie strikes back
Hi, Ethan, that was right on spot! Now I do feel like an idiot! (i was just drawing things in the wrong place, d'oh!) About the physics code - it is the method I learned from Andy Harris' Game Programming book. I think it's a great book (it put me up to speed with pygame in about a month), but I guess it is a beginners book after all. So what should I do, a function that checks the boundaries? (and same goes for all the physics checking?) thanks a bunch once again! mundial On 12/10/07, Ethan Glasser-Camp [EMAIL PROTECTED] wrote: Mundial 82 wrote: Following your wise advice, I have used the split screen technique that Casey wrote about, and everything worked great ... until I tried to create sprites that spawned on the bottom screen, to which it politely refuses. All the sprites are instantiated in the top screen, and I have no idea why (I think it's because this subsurface method creates a child of the top_screen, and then when assigning random positions, it all gets messed up). playerTop.draw(screen) playerBot.draw(screen) topPoints.draw(screen) botPoints.draw(screen) Try changing to: playerTop.draw(top_screen) playerBot.draw(bot_screen) topPoints.draw(top_screen) botPoints.draw(bot_screen) etc. Also, your check_bounds for the Square class doesn't make sense. The purpose of using subsurfaces is that you don't have to worry about where the sprite.rect is relative to the parent surface, only the child surface. I changed that to this: def checkBounds(self): if self.rect.centerx self.screen.get_width(): self.rect.centerx = 0 if self.rect.centerx 0: self.rect.centerx = self.screen.get_width() if self.rect.centery self.screen.get_height(): self.rect.centery = 0 if self.rect.centery 0: self.rect.centery = self.screen.get_height() I'd be a little wary of blending your sprite-drawing code and your physics code like this, though. Hope this helps! Ethan
Re: [pygame] split newbie strikes back
Miguel Sicart wrote: About the physics code - it is the method I learned from Andy Harris' Game Programming book. I think it's a great book (it put me up to speed with pygame in about a month), but I guess it is a beginners book after all. So what should I do, a function that checks the boundaries? (and same goes for all the physics checking?) I personally would prefer to structure things as: Sprite keeps a reference to the object it represents. Sprite.update() changes self.rect.center to be object.pos A separate function or class or something changes the velocity of the object and its position as needed. But note that I don't speak with authority here; it's possible that your structure works better for some types of games. (I was developing using an external physics library, Open Dynamics Engine, so I *had* to keep my physics separate in some way.) Ethan signature.asc Description: OpenPGP digital signature
