Re: [pygame] how to bind surface rects without subsurface (need help with bug)
On Mon, Mar 9, 2009 at 10:31 PM, Michael Fiano michael.fi...@gmail.com wrote: I realize my code isn't the best code there is, but it's also my first programming project and I've been teaching myself all sorts of things as I go. But, could someone please take a look at code and tell me why the foreground isn't aligned when scrolling? To reproduce, you'll have to move the player toward the right side of the screen until it scrolls the map, and while it does pay attention to the huge trees and other foreground objects such as the tall grass. Sure. I love looking at other peoples code for problems. (Honestly, it's a lot more fun than trying to find problems in code I wrote) This was hard, because while your code is not bad per say, there is a lot of indirection, and much overengineering going on. There are too many strong connections between classes (like the player having to know about the background and the foreground), and this coupling makes it very inflexible. In this case, the problem is simply a matter of ordering. The background is updated, then the player, then the foreground. When you start scrolling the screen (from the player update), the background has already run it's update for that frame, while the foreground gets to run its update with the move command. So it is a frame ahead of the background. In scene.py, if you change the order that objects are updated: self.render.add(self.map.background) self.render.add(self.map.foreground) self.render.add(self.player) Then the player will set up the scrolling for the next frame, which fixes the problem. A better way to do cameras, instead of having it happening in the player movement function, is to have a separate camera update that scrolls the right direction at a maximum speed until whatever it is focused on is within some region of the screen. That way if you start the player offscreen, the camera will still be able to find him. Also, for cutscenes, you can have the camera focus on a different character than the player fairly easily. Another thing that bugged me: It seems weird that you have limited yourself to only two layers in the code, when any number of layers would actually be easier. A map.move() function, which moves all of its layers by a set amount, means one less line all of the places you have to write background.move... foreground.move, and would also solve the above problem (because the movement happens instantly instead of waiting for some update). And in the map, instead of having background, and foreground, you could simply have layers[]. In the future, when you want to add a paralax treeshadow layer to display on top of the player and npc's, you will be hitting yourself at all of the places you will have to add the new layer. Good luck with the game, the sprites/tiles look really nice, and the code isn't all bad :)
Re: [pygame] Google Summer of Code participation
On, Mon Mar 09, 2009, Nirav Patel wrote: Windows and OS X webcam support are other possibilities. If students come up with interesting ideas, that's fine as well, though. There's no need to stick to the ideas list only :-). Absolutely. Hopefully students will come forward with project ideas. Unless there are objections to a pygame organization application, it would be useful to have a post on the front page requesting that interested students take a look at the ideas page or propose their own projects on the wiki and the list. If we are not accepted, it would still be useful if PSF gives us slots. Done. I added a news entry and a new ideas page at http://pygame.org/wiki/gsoc2009ideas I guess some of the todo entries at http://pygame.org/wiki/todo would make a good GSoC task, too, such as the website rewrite and redesign. Regards Marcus pgpxOw8c9tabd.pgp Description: PGP signature
[pygame] Fade to black question...
I'm trying to get a fade to black working, to that end I've written a simple program just to try it out... the (partial) code looks like this: self.screen.fill(white) self.screen.blit(self.image, self.size, self.size) print self.screen.get_at((4,4)); self.screen.fill((2,2,2), None, BLEND_SUB) print self.screen.get_at((4,4)); self.screen.fill((2,2,2), None, BLEND_SUB) print self.screen.get_at((4,4)); self.screen.fill((2,2,2), None, BLEND_SUB) print self.screen.get_at((4,4)); sys.exit() And the output... (46, 46, 44, 255) (44, 255, 42, 255) (42, 255, 40, 255) (40, 255, 38, 255) To me, it looks like it's working for the R and B components, but for some reason G immediately goes to 255 and never changes. Is there something I'm doing wrong here? Also, one other question... how would I get it to stop at (0,0,0) rather than wrap around? If I continue the loop for a long time, I get output that looks like this... (8, 255, 6, 255) (6, 255, 4, 255) (4, 255, 2, 255) (2, 255, 0, 255) (0, 255, 254, 255) (254, 255, 252, 255) (252, 255, 250, 255) (250, 255, 248, 255) Which means I've going to have to check that each time and make sure no wrap around has occured? I might as well loop through every pixel in the image and do this kind of operation myself :P. Thanks! ~Ty
Re: [pygame] Warn desktop user in some way
hmmm... for a non-gamish app I recommend Tkinter or wxPython. (Mostly Tkinter :) --- On Sun, 3/8/09, Luca luca...@gmail.com wrote: From: Luca luca...@gmail.com Subject: [pygame] Warn desktop user in some way To: pygame-users@seul.org Date: Sunday, March 8, 2009, 6:20 AM Hi all! I want to use pygame library (and one of the pygame based GUI) to write a non-gamish Desktop application. The develop of a GUI is not a problem, but I need to warn the desktop user in some way every 20 minutes. The simplest way is the use of a sound but I need to be sure to raise the event for users that has the sound disabled. The most common way if make the linux/windows/mac application bar to flash/jump (that's normal when a popup is raised). My problem is that using pygame I'm not sure how to obtain this! Can someone suggest a way to warn the user? PS: like say abowe: I need to reach this in a os indipendent way (Mac too!) -- -- luca
Re: [pygame] how to bind surface rects without subsurface (need help with bug)
Yep, changing the layer order is just a quick fix, not a real solution. You can keep the layer order you had before, and add a move_layers function to the map. Give the player a reference to the map instead of the two layers, and call move_layers in the spots you are setting the background.move and foreground.move. Map.move_layers would look something like this: def move_layers(self, amount): for layer in [self.background, self.foreground]: layer.dirty = 1 layer.rect.move_ip(amount) Actually, it might be even better to just make move a function instead of an attribute on TileLayer. You will have to change less code (but will still have the ugly bg/fg references in player). class TileLayer(pygame.sprite.DirtySprite): def __init__(self, screen, layer, w, numx, h, numy): self.screen = screen pygame.sprite.DirtySprite.__init__(self) if layer == 'fg': self.image = pygame.Surface((w*numx,h*numy), SRCALPHA, 32).convert_alpha() else: self.image = pygame.Surface((w*numx,h*numy)).convert() self.rect = self.image.get_rect() def move(self): self.dirty = 1 self.rect.move_ip(self.move) Then in player you would say: self.background.move([self.movement, 0]) self.foreground.move([self.movement, 0]) etc. Instead of assigning to those values. The real problem is that you are delaying an action until the update functions when it is really (in this case) an in-place action.
Re: [pygame] Fade to black question...
On Tue, Mar 10, 2009 at 8:32 AM, Ty ... ty.sql...@gmail.com wrote: I'm trying to get a fade to black working, to that end I've written a simple program just to try it out... the (partial) code looks like this: self.screen.fill(white) self.screen.blit(self.image, self.size, self.size) print self.screen.get_at((4,4)); self.screen.fill((2,2,2), None, BLEND_SUB) print self.screen.get_at((4,4)); self.screen.fill((2,2,2), None, BLEND_SUB) print self.screen.get_at((4,4)); self.screen.fill((2,2,2), None, BLEND_SUB) print self.screen.get_at((4,4)); sys.exit() I think maybe you want BLEND_MULT instead of BLEND_SUB? I don't know, I rarely use flags. What I would do for fade to black is create a black surface, and call set_alpha() on the surface with an increasing alpha value on each frame, and blit it.
Re: [pygame] Fade to black question...
That's a bug. I think all the BLEND_ stuff was broken like that (where green is messed up). It should be fixed now, though - can you try a pre-release build? If you are on windows or Mac, you can get a pre-release build here: http://thorbrian.com/pygame/builds.php on linux though, I think you'd need to build from source. On Tue, Mar 10, 2009 at 7:32 AM, Ty ... ty.sql...@gmail.com wrote: I'm trying to get a fade to black working, to that end I've written a simple program just to try it out... the (partial) code looks like this: self.screen.fill(white) self.screen.blit(self.image, self.size, self.size) print self.screen.get_at((4,4)); self.screen.fill((2,2,2), None, BLEND_SUB) print self.screen.get_at((4,4)); self.screen.fill((2,2,2), None, BLEND_SUB) print self.screen.get_at((4,4)); self.screen.fill((2,2,2), None, BLEND_SUB) print self.screen.get_at((4,4)); sys.exit() And the output... (46, 46, 44, 255) (44, 255, 42, 255) (42, 255, 40, 255) (40, 255, 38, 255) To me, it looks like it's working for the R and B components, but for some reason G immediately goes to 255 and never changes. Is there something I'm doing wrong here? Also, one other question... how would I get it to stop at (0,0,0) rather than wrap around? If I continue the loop for a long time, I get output that looks like this... (8, 255, 6, 255) (6, 255, 4, 255) (4, 255, 2, 255) (2, 255, 0, 255) (0, 255, 254, 255) (254, 255, 252, 255) (252, 255, 250, 255) (250, 255, 248, 255) Which means I've going to have to check that each time and make sure no wrap around has occured? I might as well loop through every pixel in the image and do this kind of operation myself :P. Thanks! ~Ty
Re: [pygame] Google Summer of Code participation
On Tue, Mar 10, 2009 at 3:26 AM, Marcus von Appen m...@sysfault.org wrote: Done. I added a news entry and a new ideas page at http://pygame.org/wiki/gsoc2009ideas I updated the ideas page to be categorized into Easy, Medium, and Hard projects. Most of the projects are still unsorted, so any help completing and sorting project ideas would be appreciated. Nirav
[pygame] Sprite group drawing with offset
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 #from the sprite (module?) class RenderUpdates(Group): def draw(self, surface, offset): spritedict = self.spritedict surface_blit = surface.blit dirty = self.lostsprites self.lostsprites = [] dirty_append = dirty.append for s in self.sprites(): r = spritedict[s] newrect = surface_blit(s.image, s.rect.move(offset)) if r is 0: dirty_append(newrect) else: if newrect.colliderect(r): dirty_append(newrect.union(r)) else: dirty_append(newrect) dirty_append(r) spritedict[s] = newrect return dirty
