Re: [pygame] Re: Problem with mouse going back to the center of the screen
Are you sure that it's not working as designed? Did you check how sdl does it? Don't throw the b word around lightly, people will think you're a wolf-crier. Sent from my iPhone On Jul 21, 2010, at 11:03 AM, SurferIX wrote: > You can clearly see it if you add this code in the event handler: > > 293 elif event.key == K_a: > 294 pygame.mouse.set_visible(False) > 295 elif event.key == K_z: > 296 pygame.mouse.set_visible(True) > > At the very beginning i do pygame.event.set_grab(False) > then if you try to press key z to show the mouse, then mouse it, press > a to hide it: you'll see the "virtual input" mode is activated. > I'm pretty sure this is a bogue. > Please tell me if you can reproduce it under Linux, thanks a lot! > > > Olivier Pons > > On 21 juil, 17:39, SurferIX wrote: >> Ok you were right. >> Here is the summary: with Linux: >> >> pygame.event.set_grab() >> pygame.mouse.set_visible() : >> >> grab => False, visible => False => "virtual input" mode >> grab => True, visible => False => "virtual input" mode >> >> grab => False, visible => True => normal mode >> grab => True, visible => True => normal mode >> >> So as long as the mouse is not visible, it's considered "virtual >> input" mode >> I'm pretty sure this is a bug. >> I hope someone will try this my code under Linux and tell me if it's >> the same problem or not. >> >> You cant get the whole sourcecode >> here:http://olivierpons.com/einstein.tar.bz2 >> >> By the way, Enigma (the only fullscreen SDL game I've tested under >> Linux) has exactly the same problem. >> >> On 21 juil, 05:36, Brian Fisher wrote: >> >> >> >>> The only time I know of where that maybe is supposed to happen, is when the >>> mouse is both grabbed by the window, and invisible. SDL takes that to mean >>> you want "virtual input" mode, where the mouse is moved back to the center >>> so you can keep getting relative mouse movement infinitely in all >>> directions, so it can behave like a trackball. This is documented >>> here:http://www.pygame.org/docs/ref/mouse.html >> >>> If this is your case. and relative mouse movement is fine, try using the >>> mouse event's .rel member instead of it's .pos member, or using >>> pygame.mouse.get_rel instead of .get_pos >> >>> if this is your case, but virtual input is not desireable, reconsider >>> whether pygame.event.set_grab(true) and pygame.mouse.set_visible(false) are >>> actually functions you want to call. >> >>> if this is not your case, it's a bug, and a minimal sample to reproduce >>> would be appreciated. >> >>> On Tue, Jul 20, 2010 at 2:32 PM, SurferIX wrote: Hi! >> I've got a problem with the mouse: it's going back to the center of the screen! I don't know where it could come from because it does this only in full screen. It's exactly the same problem with the game Enigma. >> It seems there's a problem either with SDL or with my computer. But if it's with my computer why only in full screen? Did you have any trouble like that? Thanks a lot!
[pygame] Announcing: San Francisco Game Developer's Workshops!
Hello Bay Area Game Developers, Do you want more players for your games this year? How about more engaged players that spend more in each play session? Are you worried about this not happening? We have all heard the less than optimistic coverage on game revenues. According to the NPD group/Gamasutra US retail video game industry sales January 2010 sales decreased 13% from the same time last year. Even social game viral growth, a major buzz area over the last few years, is not as easy with Facebook virality changes and the rise of game companies with massive user bases and large marketing muscle. How do you prevent yourself from being part of these statistics? How do you arm yourself for the next wave of successful games? Join us August 10th at 7pm to get an hear Joe Dunn and Josh Rose give you a brain dump download of how they win in the market so you can too. They will cover how they combine: creative design new technology platform agnostic virality to create game experiences players crave, share, and keep coming back for. There will be a brief interactive Q&A; between each speaker, so designers and developers can get a chance to get some direct opinions or strategies on some of their own games and businesses Do you want to network grow your business and have a good time? Come party with us after the event to brainstorm, chill, or simply share a beer with awesome fellow game developers, designers, artists, and deal makers. This event will sell out! We have 94 seats left, as of a 4 days ago we had 200! Join us! Your going to want to be at this event to grow your business this year! Sana Choudary and Japheth Dillman REGISTRATION LINK & Details: http://bayareavideogamedevelopermeetup.eventbrite.com/ When: August 10th, 7-9pm Afterparty: 9-10pm Where: Art Institute of California, 4th floor, 1130 Market Street, 10 UN Civic Center Plaza, San Francisco, CA 94102 Afterparty: from 9-10pm, location Jillians, 101 4th Street #1070, San Francisco, CA 94103 REGISTRATION LINK & Details: http://bayareavideogamedevelopermeetup.eventbrite.com/
RE: [pygame] are individual midi instruments sounds copyrighted
You guys are working much too hard at this. All you have to do is download the Furniture Genuine Advantage patch from Microsloth.com. Then you will have the comfort of knowing that your furniture is truly your own property and not a pirated copy of someone else's furniture. You will also be able to move the furniture around within the house any time you like. Just don't plan on remodeling your house. If the furniture notices any structural changes in the house that might suggest that it is not actually the same house, it will immediately refuse to let you sit on it, dine on it, or use it in any other way. But, hey, all 'advantages' have to come at some small cost, right? _ From: owner-pygame-us...@seul.org [mailto:owner-pygame-us...@seul.org] On Behalf Of B W Sent: Wednesday, July 21, 2010 7:15 AM To: pygame-users@seul.org Subject: Re: [pygame] are individual midi instruments sounds copyrighted Relocating the furniture voids the warranty. If you need to move the furniture under warranty to a new location, you'll either need to contract an authorized, insured mover, or get the furniture re-certified by an authorized representative of the manufacturer at the new location. These expensive services are not covered under the maintenance agreement. Gumm On Tue, Jul 20, 2010 at 6:38 PM, Greg Ewing wrote: Thiago Chaves wrote: Sorry. Evidently you'll be able to buy "professional broadcaster" versions of the furniture, which is pretty much the same thing, but incredibly more expensive. Also, if you want other members of your family to be able to use the furniture, they will have to buy their own furniture, or you will have to get a special "household" furniture licence. And don't even think about letting visitors sit on your sofa... -- Greg
[pygame] Re: Problem with mouse going back to the center of the screen
You can clearly see it if you add this code in the event handler: 293 elif event.key == K_a: 294 pygame.mouse.set_visible(False) 295 elif event.key == K_z: 296 pygame.mouse.set_visible(True) At the very beginning i do pygame.event.set_grab(False) then if you try to press key z to show the mouse, then mouse it, press a to hide it: you'll see the "virtual input" mode is activated. I'm pretty sure this is a bogue. Please tell me if you can reproduce it under Linux, thanks a lot! Olivier Pons On 21 juil, 17:39, SurferIX wrote: > Ok you were right. > Here is the summary: with Linux: > > pygame.event.set_grab() > pygame.mouse.set_visible() : > > grab => False, visible => False => "virtual input" mode > grab => True, visible => False => "virtual input" mode > > grab => False, visible => True => normal mode > grab => True, visible => True => normal mode > > So as long as the mouse is not visible, it's considered "virtual > input" mode > I'm pretty sure this is a bug. > I hope someone will try this my code under Linux and tell me if it's > the same problem or not. > > You cant get the whole sourcecode here:http://olivierpons.com/einstein.tar.bz2 > > By the way, Enigma (the only fullscreen SDL game I've tested under > Linux) has exactly the same problem. > > On 21 juil, 05:36, Brian Fisher wrote: > > > > > The only time I know of where that maybe is supposed to happen, is when the > > mouse is both grabbed by the window, and invisible. SDL takes that to mean > > you want "virtual input" mode, where the mouse is moved back to the center > > so you can keep getting relative mouse movement infinitely in all > > directions, so it can behave like a trackball. This is documented > > here:http://www.pygame.org/docs/ref/mouse.html > > > If this is your case. and relative mouse movement is fine, try using the > > mouse event's .rel member instead of it's .pos member, or using > > pygame.mouse.get_rel instead of .get_pos > > > if this is your case, but virtual input is not desireable, reconsider > > whether pygame.event.set_grab(true) and pygame.mouse.set_visible(false) are > > actually functions you want to call. > > > if this is not your case, it's a bug, and a minimal sample to reproduce > > would be appreciated. > > > On Tue, Jul 20, 2010 at 2:32 PM, SurferIX wrote: > > > Hi! > > > > I've got a problem with the mouse: it's going back to the center of > > > the screen! > > > I don't know where it could come from because it does this only in > > > full screen. > > > It's exactly the same problem with the game Enigma. > > > > It seems there's a problem either with SDL or with my computer. But if > > > it's with my computer why only in full screen? > > > Did you have any trouble like that? > > > Thanks a lot!
[pygame] Re: Problem with mouse going back to the center of the screen
Ok you were right. Here is the summary: with Linux: pygame.event.set_grab() pygame.mouse.set_visible() : grab => False, visible => False => "virtual input" mode grab => True, visible => False => "virtual input" mode grab => False, visible => True => normal mode grab => True, visible => True => normal mode So as long as the mouse is not visible, it's considered "virtual input" mode I'm pretty sure this is a bug. I hope someone will try this my code under Linux and tell me if it's the same problem or not. You cant get the whole sourcecode here: http://olivierpons.com/einstein.tar.bz2 By the way, Enigma (the only fullscreen SDL game I've tested under Linux) has exactly the same problem. On 21 juil, 05:36, Brian Fisher wrote: > The only time I know of where that maybe is supposed to happen, is when the > mouse is both grabbed by the window, and invisible. SDL takes that to mean > you want "virtual input" mode, where the mouse is moved back to the center > so you can keep getting relative mouse movement infinitely in all > directions, so it can behave like a trackball. This is documented > here:http://www.pygame.org/docs/ref/mouse.html > > If this is your case. and relative mouse movement is fine, try using the > mouse event's .rel member instead of it's .pos member, or using > pygame.mouse.get_rel instead of .get_pos > > if this is your case, but virtual input is not desireable, reconsider > whether pygame.event.set_grab(true) and pygame.mouse.set_visible(false) are > actually functions you want to call. > > if this is not your case, it's a bug, and a minimal sample to reproduce > would be appreciated. > > > > On Tue, Jul 20, 2010 at 2:32 PM, SurferIX wrote: > > Hi! > > > I've got a problem with the mouse: it's going back to the center of > > the screen! > > I don't know where it could come from because it does this only in > > full screen. > > It's exactly the same problem with the game Enigma. > > > It seems there's a problem either with SDL or with my computer. But if > > it's with my computer why only in full screen? > > Did you have any trouble like that? > > Thanks a lot!
Re: [pygame] are individual midi instruments sounds copyrighted
Relocating the furniture voids the warranty. If you need to move the furniture under warranty to a new location, you'll either need to contract an authorized, insured mover, or get the furniture re-certified by an authorized representative of the manufacturer at the new location. These expensive services are not covered under the maintenance agreement. Gumm On Tue, Jul 20, 2010 at 6:38 PM, Greg Ewing wrote: > Thiago Chaves wrote: > >> Sorry. Evidently you'll be able to buy "professional broadcaster" >> versions of the furniture, which is pretty much the same thing, but >> incredibly more expensive. >> > > Also, if you want other members of your family to be able > to use the furniture, they will have to buy their own > furniture, or you will have to get a special "household" > furniture licence. > > And don't even think about letting visitors sit on your > sofa... > > -- > Greg >
[pygame] Re: Sprite Surface very slow to draw
Hi, Thanks for your answer, I wasn't looking yet for speed & optimization, but hey your advice will soon be used :) :) I'm re-creating the game Einstein : http://games.flowix.com/en/index.html which is full open source, and *very* nice. I just needed to learn python and to do a full game 100 % Windows / Linux compatible. pyGame seems one of the best way to go. And python is amazing how your develop quick (compared to Php and all other languages). Regards, Olivier Pons On 20 juil, 10:59, stas zytkiewicz wrote: > On Tue, Jul 20, 2010 at 10:39 AM, SurferIX wrote: > > If found the solution! > > The problem is that the documentation needs examples (or maybe I > > didn't find good ones): > > You should look at the pygame reference > doc:http://www.pygame.org/docs/ref/index.html > > > I was using: > > 40 self.image.convert_alpha() > > I should have done: > > 40 self.image.convert_alpha(self.image) > > (which I don't understand btw) > > See the docs: > > Surface.convert_alpha > > change the pixel format of an image including per pixel alphas > Surface.convert_alpha(Surface): return Surface > Surface.convert_alpha(): return Surface > > Creates a new copy of the surface with the desired pixel format. > The new surface will be in a format suited for quick blitting to the > given format with per pixel alpha. If no surface is given, the new > surface will be optimized for blitting to the current display. > > > I guess it's quicker to convert the existing surface than to create a new one. > But it's thing that's slows your code down. > The problem is in you event loop: > > 71 going = True > 72 while going: > 73 clock.tick(60) > First ask your self if you need a framerate of 60 per second. > Most of the time 30 p/s is enough, that alone will cut the stuff todo in half. > Now you do alll the below stuff 60 times per second > > 74 for event in pygame.event.get(): > 75 if event.type == QUIT: > 76 going = False > 77 elif event.type == KEYDOWN: > 78 if event.key == K_ESCAPE: > 79 going = False > 80 elif event.key == K_q: > 81 going = False > 82 elif event.key == K_RETURN: > 83 going = False > This doesn't take much time. > But the stuff below does. > > 85 group_sprites.update() > 86 screen.blit(background, (0, 0)) > You blit the complete screen 60 times per second ! > > The rest depends on how many sprites you have in your class. > 87 group_sprites.draw(screen) > 88 for sprite in group_sprites: > 89 if isinstance(sprite, Contour): > 90 if sprite.done: > 91 group_sprites.remove(sprite) > 92 pygame.display.flip() > > Most of the times you have speed troubles the problem lies in to many > things in the mainloop. > You should for example only blit the rect on the screen that needs > erasing, not the complete screen. > > From the docs: > > Surface.blit > > draw one image onto another > Surface.blit(source, dest, area=None, special_flags = 0): return Rect > > An optional area rectangle can be passed as well. This > represents a smaller portion of the source Surface > to draw. > . > > If you do: > dirty = [ ] > > rect = sprite_to_erase.get_rect() > dirty.append(screen.blit(background, rect, rect)) > > Than instead of pygame.display.flip use: > pygame.display.update(dirty) > > Taken from the docs: > > pygame.display.update > > update portions of the screen for software displays > pygame.display.update(rectangle=None): return None > pygame.display.update(rectangle_list): return None > > This function is like an optimized version of > pygame.display.flip - update the full display Surface to the > screen > for software displays. It allows only a portion of the screen to > updated, instead of the entire area. > > Your loop will be way faster. > > Greetings, > Stas > > -- > Free-source educational programs for > schoolshttp://www.schoolsplay.org andhttp://wiki.laptop.org/go/Schoolsplayhttp://gvr.sf.netandhttp://wiki.laptop.org/go/Guido_van_Robot
[pygame] Re: Problem with mouse going back to the center of the screen
You cant get the whole sourcecode here: http://olivierpons.com/einstein.tar.bz2 just launch einstein.py This is the beginning of an einstein's game re-write. The gen.py is the puzzle generator, and the shapes.py contains the shapes. What is strange is that under Windows there's no problem at all. Olivier On 21 juil, 00:10, Ian Mallett wrote: > Hi, > > Some simple example code to reproduce it would be nice. > > I suppose you might try grabbing the events (pygame.event.set_grab(True)). > Probably won't fix anything. > > Ian
[pygame] Re: convert access violation
Thanks! "There may be a bug in Pygame triggered when the newly converted image is immediately deleted. (although that does not seem likely)" That's exactly something like that I wanted to read: an explanation (or the beginning). I hope that if a pyGame developper reads this, maybe he/she will try to reproduce the bug. It's very easy to reproduce: under Windows XP, install the package Python26 (with numpy-1.4.1 (it's included I think)) then pygame-1.9.1. Then try to run with my simple sprite example. On 21 juil, 09:07, Peter Shinners wrote: > On 07/19/2010 01:12 AM, SurferIX wrote: > > > > > Hi! > > > I'm using pygame for the first time. > > I've developped a game, everything works fine but one thing I can't > > explain. > > Using Windows, python 2.6, here's what I was doing: > > > 18 class Shape(pygame.sprite.Sprite): > > 20 def __init__(self,width,height): > > 21 pygame.sprite.Sprite.__init__(self) > > 23 self.width = width > > 24 self.height = height > > 27 self.rect = pygame.Rect(0, 0, 6*5*20, 6*5*20) > > 28 self.image = pygame.Surface( (self.rect.width, > > self.rect.height) ) > > 29 self.image.fill((255, 255, 255)) > > 30 self.image.convert() > > > the line #30 was *always* generating access violation. > > I just added modified to: > > 30 self.image = self.image.convert() > > and now everything works fine. > > > But there shouldn''t have any problem at all with this simple line: > > 30 self.image.convert() > > even though it does nothing (well i guess it does nothing). > > > I'm not the kind of people who thinks "it works let's go on". I want > > to understand why it didn't work before going further. Can someone > > please explain me why this raised an Access Violation? > > I can't explain the access error. But you'll want line 30 to look like this. > > self.image = self.image.convert() > > You may try changing the code and seeing if it still dies. There may be > a bug in Pygame triggered when the newly converted image is immediately > deleted. (although that does not seem likely)
Re: [pygame] convert access violation
On 07/19/2010 01:12 AM, SurferIX wrote: Hi! I'm using pygame for the first time. I've developped a game, everything works fine but one thing I can't explain. Using Windows, python 2.6, here's what I was doing: 18 class Shape(pygame.sprite.Sprite): 20 def __init__(self,width,height): 21 pygame.sprite.Sprite.__init__(self) 23 self.width = width 24 self.height = height 27 self.rect = pygame.Rect(0, 0, 6*5*20, 6*5*20) 28 self.image = pygame.Surface( (self.rect.width, self.rect.height) ) 29 self.image.fill((255, 255, 255)) 30 self.image.convert() the line #30 was *always* generating access violation. I just added modified to: 30 self.image = self.image.convert() and now everything works fine. But there shouldn''t have any problem at all with this simple line: 30 self.image.convert() even though it does nothing (well i guess it does nothing). I'm not the kind of people who thinks "it works let's go on". I want to understand why it didn't work before going further. Can someone please explain me why this raised an Access Violation? I can't explain the access error. But you'll want line 30 to look like this. self.image = self.image.convert() You may try changing the code and seeing if it still dies. There may be a bug in Pygame triggered when the newly converted image is immediately deleted. (although that does not seem likely)
