Re: [pygame] Indie Game Host
I think that was just spam from somebody who saw "game" in the list name and assumed it would be a good place to advertise his website that appears to only support java games. --- James On Fri, Oct 17, 2008 at 04:38:00PM -0500, pymike wrote: >OOC can the pygame games be played in browsers? > >On Fri, Oct 17, 2008 at 3:52 PM, Matt Kremer <[EMAIL PROTECTED]> >wrote: > > Hello pygame users, > > I run a website called GMArcade (http://gmarcade.com). In short, we are > an arcade for indie game developers, where users can post their games. > Here is a list of features: > > -Upload your game with screenshots > -Your game can immediately be played online, without users downloading > (JAVA must be installed). Test this out by clicking this link (just > click "Open" if prompted to download a JNLP file): > > http://gmarcade.com/generatejnlp.php?id=10 > > -Participate in discussions on our forums > -Comment and Rate other games > -Start your own Blog! > -Just hang out and have fun! > > I hope to attract users from PyGame, as well as other game development > tools. It would be great to see some of you on the site :) > > Here's the link again: > > http://gmarcade.com/ > > And if you want to request any new features, just post here: > > http://gmarcade.com/requestafeature/ > > I hope to see you around, thanks again! > -Matt Kremer > http://gmarcade.com/ > >-- >- pymike >"Stop loling into a false sense of hilarity"
Re: [pygame] extending pygame masks
Here are the files. It turns out the actual convolution is much simpler than the one I sent out before, since I learned about the bitmask_draw method and just use that internally. It might be slightly slower, but it's more likely to be correct. As I was coding it up, I realized I'm still not completely happy with the interface. Which of the following two possibilities do people prefer? == Option 1 == Mask.convolve(othermask, outputmask = None, offset = (0,0)): return Mask Returns a mask with the (i-offset[0],j-offset[1]) bit set if shifting othermask so that it's lower right corner pixel is at (i,j) would cause it to overlap with self. If outputmask is not None, then the output is drawn onto outputmask and outputmask is returned. Otherwise a mask of size self.get_size() + othermask.get_size() - (1,1) is created. == Option 2 == Mask.convolve(othermask, outputmask, offset = (0,0)): return Mask Sets the ((i, j) - offset) bit of outputmask if overlap(self, othermask, (i,j)) is true. Returns outputmask. Mask.convolve(othermask): return Mask Creates a mask just big enough to hold the convolution of self and other, and shifts the output so that it fits in the mask. Equivalent to self.convolve(other, Mask(self.get_size() + othermask.get_size() - (1,1)), othermask.get_size() - (1,1)) The difference between the two is how the offset is treated. Both return the same result in the single-argument case, but Option 1 explains the multi-argument variant in terms of the single-argument variant, whereas Option 2 explains the single-argument variant in terms of the multi-argument invariant. I think Option 2 is simpler to explain/understand (the lower-right corner of Option 1 just screams "off-by-one"). Option 1 is slightly more flexible, because you can call it with 2 arguments, although I don't think there would be any reason to do that (except that the unit tests do that). Option 1 is implemented in this tarball, although it would be trivial to switch it to option 2 (and the code might even be infinitestimally nicer). It's splitting hairs I know, but I figure the hairs should be split before the API becomes public. --Mike Nirav Patel wrote: You can use the diff command to generate patches, but if its easier for you, you can just upload or email the files you changed. Nirav convolve.tar.gz Description: GNU Zip compressed data
[pygame] BUG?: clip and Rect anomalies when width or height negative
1. Clip Anomaly: when a surface .set_clip is called with a rect which have negative width or height, seems natural that following fills or blits don't touch at all the surface. But width<0 --> surface.get_clip().width == surface.get_width() height<0 --> surface.get_clip().height == surface.get_height() so if the left,top of the clip area is not too far you get the surface partially blited/filled. The attached clip_test.py demoes this. Use case: resizing the clip area in a loop can get the last loop iteration with a degenerated clip rect. The natural control variable for the loop is not the width. Expectation on set_clip behavior with negative width was that nothing would write to the surface, hence garbage in the screen. Because of unexpected, toke some time to find the problem. there is any rationale for the current behavior ? wouldn't be better my expected behavior ? If the current behavior will be kept, please mention it in the docs for set_clip and get_clip, and maybe blit / fill 2. Rect anomaly when width or height is negative: Look at this: >>> clip_rect = pygame.Rect(1,1,-100,-100) >>> clip_rect.width -100 >>> clip_rect.left 1 >>> clip_rect.right -99 >>> Its reasonable that a Rect can serve a width<0 ? Its reasonable that rect.left>rect.right ? To me, this behavior broke the user expectations. Even if the 1.8.1 docs tells that "The size values can be programmed to have negative values, but these are considered illegal Rects for most operations. " Much better would be: Accept width or height negative, BUT convert to 0 before store it internally. With that, the prev interpreter session would look: >>> clip_rect = pygame.Rect(1,1,-100,-100) >>> clip_rect.width 0 >>> clip_rect.left 1 >>> clip_rect.right 1 >>> As a side effect, opers that uses rects like blit, fill, set_clip... don't need to be extended to the degenerate cases. comments ? -- claxo # clip_test.py begin import pygame from pygame.constants import * def main(): pygame.init() screen = pygame.display.set_mode((800,600)) screen.fill((109,152,6)) dst_surf = pygame.Surface((400,400)) dst_surf.fill((0,0,255)) src_surf = pygame.Surface((200,200)) src_surf.fill((255,0,0)) print 'Initial, undisturbed dst_surf real clip rect:',dst_surf.get_clip() clip_rect = pygame.Rect(0,0,200,100) dst_surf.set_clip(clip_rect) print "After set_clip with a 'good' rect:",dst_surf.get_clip() clip_rect = pygame.Rect(0,0,-100,-100) # not ok , negative width or height ignored print 'setting dst_surf clip rect to:',clip_rect dst_surf.set_clip(clip_rect) print 'results in dst_surf real clip rect:',dst_surf.get_clip() dst_surf.blit(src_surf, (0,0)) screen.blit(dst_surf,(0,0)) pygame.display.flip() bRun = True while bRun: pygame.event.pump() for ev in pygame.event.get(): if (ev.type == pygame.KEYDOWN and ev.key == pygame.K_ESCAPE): bRun = False pygame.quit() if __name__ == '__main__': main() # clip_test.py ends
Re: [pygame] extending pygame masks
You can use the diff command to generate patches, but if its easier for you, you can just upload or email the files you changed. Nirav On Fri, Oct 17, 2008 at 6:57 PM, Michael George <[EMAIL PROTECTED]> wrote: > I added a convolve function with the proposed interface, as well as docs and > a handful of unit tests. How do I generate and submit a patch? > > --Mike > > René Dudfield wrote: >> >> Sounds cool. >> >> Remember to also write unittests :) The mask module is falling >> behind it unittests at the moment. >> >> cheers! >> >> >> On Thu, Oct 16, 2008 at 5:40 AM, Michael George <[EMAIL PROTECTED]> >> wrote: >> >>> >>> Nirav Patel wrote: >>> It's not necessarily a good idea to have stuff that specific to an app in a library. I think it would be good to have the convolution function built into mask, and leave the rest of the implementation up to the user. As for how to deal with the interface for convolving, perhaps it would be useful to have one of the masks specified as being the "world", and the other as the object being moved? Something like: Mask.convolve(world = Mask) returning a mask the size of the world mask. >>> >>> I think it makes more sense to do it the other way - world.convolve(obj) >>> rather than obj.convolve(world). The two are flips of each other anyway, >>> so >>> it's probably not a big deal. In either case, the output needs to be >>> bigger >>> than both of the inputs (the size of the convolution is the sum of the >>> sizes >>> of the inputs, minus one). >>> >>> I guess it's not too hard to compute the rects if you're careful. >>> It would be fairly easy to construct this world mask by using Mask.draw. >>> >>> Yeah, that's probably best. In fact, I was thinking that I might need to >>> do >>> it that way anyway. The only reason to do it for a collection in one go >>> is >>> that you can avoid allocating all of those intermediate masks, and >>> shifting >>> everything twice. I guess masks are pretty small and shifts are pretty >>> fast >>> so it's not such a big deal. >>> >>> So here's a revised proposal: >>> >>> Mask.convolve(other = Mask): return Mask >>> compute the convolution of self and other. The (x,y) bit of the return >>> value will be set if shifting the lower-right corner of other to position >>> (x,y) would cause it to overlap with self. The return value has size >>> equal >>> to self.getsize() + other.getsize() - (1,1). >>> >>> >>> (and possibly) >>> Mask.convolve(other = Mask, world = Mask, offset = (x,y)): return None >>> Functionally the same as world.union(self.convolve(other), offset) but >>> more efficient >>> >>> Then the stuff that computes the rectangles and masks for a sprite group >>> would be up to the application developer (i.e. me). >>> >>> On a side note, does Mask.draw do an "or" or a copy of the two masks? >>> They're probably both useful. Assuming it's a copy, I've used >>> world.union >>> to denote orring the bitmasks. >>> >>> --Mike >>> >>> > >
Re: [pygame] extending pygame masks
I added a convolve function with the proposed interface, as well as docs and a handful of unit tests. How do I generate and submit a patch? --Mike René Dudfield wrote: Sounds cool. Remember to also write unittests :) The mask module is falling behind it unittests at the moment. cheers! On Thu, Oct 16, 2008 at 5:40 AM, Michael George <[EMAIL PROTECTED]> wrote: Nirav Patel wrote: It's not necessarily a good idea to have stuff that specific to an app in a library. I think it would be good to have the convolution function built into mask, and leave the rest of the implementation up to the user. As for how to deal with the interface for convolving, perhaps it would be useful to have one of the masks specified as being the "world", and the other as the object being moved? Something like: Mask.convolve(world = Mask) returning a mask the size of the world mask. I think it makes more sense to do it the other way - world.convolve(obj) rather than obj.convolve(world). The two are flips of each other anyway, so it's probably not a big deal. In either case, the output needs to be bigger than both of the inputs (the size of the convolution is the sum of the sizes of the inputs, minus one). I guess it's not too hard to compute the rects if you're careful. It would be fairly easy to construct this world mask by using Mask.draw. Yeah, that's probably best. In fact, I was thinking that I might need to do it that way anyway. The only reason to do it for a collection in one go is that you can avoid allocating all of those intermediate masks, and shifting everything twice. I guess masks are pretty small and shifts are pretty fast so it's not such a big deal. So here's a revised proposal: Mask.convolve(other = Mask): return Mask compute the convolution of self and other. The (x,y) bit of the return value will be set if shifting the lower-right corner of other to position (x,y) would cause it to overlap with self. The return value has size equal to self.getsize() + other.getsize() - (1,1). (and possibly) Mask.convolve(other = Mask, world = Mask, offset = (x,y)): return None Functionally the same as world.union(self.convolve(other), offset) but more efficient Then the stuff that computes the rectangles and masks for a sprite group would be up to the application developer (i.e. me). On a side note, does Mask.draw do an "or" or a copy of the two masks? They're probably both useful. Assuming it's a copy, I've used world.union to denote orring the bitmasks. --Mike
Re: [pygame] Indie Game Host
OOC can the pygame games be played in browsers? On Fri, Oct 17, 2008 at 3:52 PM, Matt Kremer <[EMAIL PROTECTED]>wrote: > Hello pygame users, > > I run a website called GMArcade (http://gmarcade.com). In short, we are an > arcade for indie game developers, where users can post their games. Here is > a list of features: > > -Upload your game with screenshots > -Your game can immediately be played online, without users downloading > (JAVA must be installed). Test this out by clicking this link (just click > "Open" if prompted to download a JNLP file): > > http://gmarcade.com/generatejnlp.php?id=10 > > -Participate in discussions on our forums > -Comment and Rate other games > -Start your own Blog! > -Just hang out and have fun! > > I hope to attract users from PyGame, as well as other game development > tools. It would be great to see some of you on the site :) > > Here's the link again: > > http://gmarcade.com/ > > And if you want to request any new features, just post here: > > http://gmarcade.com/requestafeature/ > > I hope to see you around, thanks again! > -Matt Kremer > http://gmarcade.com/ > > -- - pymike "Stop loling into a false sense of hilarity"
[pygame] Indie Game Host
Hello pygame users, I run a website called GMArcade (http://gmarcade.com). In short, we are an arcade for indie game developers, where users can post their games. Here is a list of features: -Upload your game with screenshots -Your game can immediately be played online, without users downloading (JAVA must be installed). Test this out by clicking this link (just click "Open" if prompted to download a JNLP file): http://gmarcade.com/generatejnlp.php?id=10 -Participate in discussions on our forums -Comment and Rate other games -Start your own Blog! -Just hang out and have fun! I hope to attract users from PyGame, as well as other game development tools. It would be great to see some of you on the site :) Here's the link again: http://gmarcade.com/ And if you want to request any new features, just post here: http://gmarcade.com/requestafeature/ I hope to see you around, thanks again! -Matt Kremer http://gmarcade.com/
Re: [pygame] Physics, collision detection etc?
Hi Niki! Yes I have, a well a Box2D for Python. Neither or Python extensions and neither will be a permanent part of PyGame. There's already a cool physics module part of PyGame, I'll try to see if we can extend it's API further. /Peter On 2008-10-14 (Tue) 10:59, niki wrote: > Peter Gebauer wrote: >> Hello Ian! >> >> Nice code! I was thinking of exposing some of the code Zhang Fan wrote >> for the physics engine, but as of yet it only handles rectangles. >> There's plenty of code available on the net, but I feel reluctant to >> produce yet another Python extension for PyGame. I'll continue to check >> for reusing already existing projects, most likely fast C code that can >> be easily used to extend Python functionality. > > Have you tried pymunk? > > Niki >
