[pygame] Embedding pygame into wxPython
Hi I'd like to embed a pygame surface into a wxPython-Panel. With the code from [1] it's no big deal. The attached code works on WinXP and W2k with Python 2.4.2 and pygame 1.7.1. And it works on WinXP with Python 2.3.5 and pygame 1.6. But on W2k it crashes with Python 2.3.5 and pygame 1.6 with the following error: ---snip--- Pygame Parachute Traceback: File simple_pygame.py, line 15, in __init__ Fatal Python error: (pygame parachute) Segmentation Fault abnormal program termination ---snap--- Of course it doesn't crash, if I remove line 12 os.environ['SDL_WINDOWID'] = str(wndCam.GetHandle()) If I remove line 15 pygame.display.set_mode((640, 480)) it gives this error: ---snip--- Pygame Parachute Traceback: File C:\PROGRA~1\Python23\Lib\site-packages\wx-2.6-msw-un icode\wx\_core.py, line 8731, in Show ---snap--- If I remove the lines 1521 pygame.display.set_mode((640, 480)) ... frame.Show() it doesn't give a error, but of course than the app doesn't show anything. Is there any reason, why there is no precompiled version of pygame 1.7.1 for python 2.3? And how do I unfailing embed a pygame surface into a wxPython-app with Python 2.3? Are there other obstacles that I have to respect? Thanks for your help cu boesi [1] http://wiki.wxpython.org/index.cgi/IntegratingPyGame PS: I'm using wxPython 2.6.3.2 on all systems simple_pygame.py Description: Binary data
Re: [pygame] pygame.display.set_caption() not setting window icon
On Sun, 9 Jul 2006 21:24:28 -0700, Brian Fisher [EMAIL PROTECTED] said: On 7/9/06, David Mikesell [EMAIL PROTECTED] wrote: I'm using Pygame 1.7.1 on Windows XP. set_icon sets the icon when the window is collapsed, set_caption sets the caption, and get_caption shows the correct file name of the icontitle. Anyone else having problems with this? I don't think set_caption is supposed to set the icon... the icontitle is not a path to an icon, it's a title when iconified from the pygame docs: If the display has a window title, this function will change the name on the window. Some systems support an alternate shorter title to be used for minimized displays. Wierd. My caption title is used for both the minimized and expanded window title, even though I specifically set the icon title to something different.
[pygame] BUG: display.get_caption
Undocumented behaviour: if the title is not set (set to empty string, or
display mode not set), the function returns a tuple of length 0. I
think reasonable behaviour here would be to return ('', '') rather than
(). If changing this would break something then it should be documented.
Alex.
[pygame] BUG: pygame.event.peek
An additional undocumented signature is available: pygame.event.peek(): return Event The function returns the next event instead of a bool if no arguments are given. The returned event is filled with nonsense (uninitialized) values if no event is in the queue. Suggest it return None in this case instead, or that the undocumented functionality be removed entirely. Alex.
[pygame] BUG: pygame.event.set_blocked and set_allowed
Both functions behave incorrectly when passed None. For set_blocked, lines 823-824 of event.c read: else if(type == Py_None) SDL_EventState((Uint8)0, SDL_IGNORE); should be: else if(type == Py_None) SDL_EventState((Uint8)0xff, SDL_IGNORE); For set_allowed, lines 790-791 read: else if(type == Py_None) SDL_EventState((Uint8)0xFF, SDL_IGNORE); should be: else if(type == Py_None) SDL_EventState((Uint8)0xFF, SDL_ENABLE); Alex.
Re: [pygame] BUG: pygame.event.peek
Alex Holkner wrote: An additional undocumented signature is available: pygame.event.peek(): return Event The function returns the next event instead of a bool if no arguments are given. The returned event is filled with nonsense (uninitialized) values if no event is in the queue. Suggest it return None in this case instead, or that the undocumented functionality be removed entirely. Alex. Having just looked at the pygame.event.post() code: it is possible to crash pygame (or at the very least, get garbage values) by posting a user event with a dictionary, then peeking that event more than once (or peeking it and then getting it). User event dictionaries are freed when requested, so if peek() with no arguments is desired, user_event_getobject needs to be modified to not free userobj when peeking, only when getting. Alex.
Re: [pygame] Embedding pygame into wxPython
On Mon, 2006-07-10 at 08:55 +0200, Alexander 'boesi' Bösecke wrote: I'd like to embed a pygame surface into a wxPython-Panel. With the code from [1] it's no big deal. The attached code works on WinXP and W2k with Python 2.4.2 and pygame 1.7.1. And it works on WinXP with Python 2.3.5 and pygame 1.6. But on W2k it crashes with Python 2.3.5 and pygame 1.6 with the following error: ---snip--- Pygame Parachute Traceback: File simple_pygame.py, line 15, in __init__ Fatal Python error: (pygame parachute) Segmentation Fault abnormal program termination ---snap--- On windows, when you set the SDL_WINDOWID environment variable. Also set SDL_VIDEODRIVER to windib. The directx backend crashes pretty good when embedded. I think the newest of the new SDL's defaults to windib instead of directx. I think it was generally agreed apon that the directx mode (using directx 5) was a bit crusty.
RE: [pygame] pygame website - request for suggestions
I've noticed a few bugs with the Pygame documentation on the site. I'm far from a pygame-pro so these may be deprecated features or me just misunderstanding things, not knowing where to look, etc., but I've noticed the following: #1 The Scrap topic link doesn't show up in the header on this page: http://www.pygame.org/docs/ But it will appear when you click any of the other topic links in the header (pygame, font, draw, etc.). #2 Googling for certain keywords, I can find the two links below (color constants), but I can't find any way to navigate to these pages from the main documentation link (http://www.pygame.org/docs/) http://www.pygame.org/docs/ref/pygame_color.html http://www.pygame.org/docs/ref/pygame_constants.html #3 There is some potential for odd formatting when a method's documentation contains a link to another method (ex: the docs for pygame.mixer.init refer to pygame.init, pygame.mixer.pre_init and pygame.mixer.quit). It looks like the method that is referred to gets its short description copied into the text with a smaller font after the method name. Good idea, but this can be difficult when reading along. Hard to tell what is plain text and what is the referenced method's short description. Can you put the short description in parenthesis or something to make it clear that the short description isn't meant to be read along with the sentence? Certain browser settings format the short description almost identically to the regular documentation (I usually use Opera and it is difficult to tell at a glance the text is different. IE does a bit better). This makes it even more difficult to differentiate between the two. FWIW, looking at the html source, these references are enclosed in tt tags with the short description getting a font size=-1. Hope that makes sense. Feel free to ask for clarification if necessary... Great site! Keep it up! I'd be lost w/out this site! -Scott Hey, It's been one year since I launched the new pygame website. I hope to have a bit of time during the next month to do some updates to it. So if anyone has: - bug reports - feature requests - etc To suggest, now's the time! If anyone makes a feature request that you think is great, please reply to their message and say so -- the more people want a feature the more likely I'll be to implement it.
[pygame] Subtle Memory Bug
I've just solved a tricky bug (I think) whose solution might help others who encounter a similar problem. I was playing with cellular automata, a bunch of tribes that move and grow as squares on a grid. Each tribe was stored in a game object, in a dictionary, by an ID number. I had a loop that made each tribe take an action, like so: for tribe in self.alltribes.values(): ## Line 1 ## Make sure tribe is still in play before activating. if tribe.ID in self.alltribes.keys(): ## Line 2 tribe.Go() self.age += 1 Some events would cause a tribe to merge with another, deleting both and creating a new tribe with a new ID value. Other events would create a new tribe. I was getting a strange error in which a tribe would try to move from coordinates that it wasn't actually at, crashing the program. I narrowed down that this only happened when a tribe was deleted, and then another tribe was randomly created with the same ID in the same turn. The reason seems to be this. Line 1 creates a list of tribes when the loop begins, _containing the tribe objects themselves_. When a game event deletes a tribe, it's still present in memory until the end of the loop... so the loop checks the deleted tribe's ID, sees that there's still a tribe with that ID (the newly created one), and runs _the deleted tribe_, which shouldn't happen. So I changed line 2 to: if tribe in self.alltribes.values(): ## Line 2b This way, the tribe is checked not as an ID#, but as a Python object, against the list of objects in self.alltribes.values. If the tribe is deleted, it won't show up in the list when it's checked, so the test will fail as it should. Anyway, I learned something from this problem about the persistence of objects in memory. Perhaps this will help someone else. Kris ...Defeated the Bug and got 1 experience points!
Re: [pygame] Subtle Memory Bug
On Jul 10, 2006, at 2:27 PM, Kris Schnee wrote: I've just solved a tricky bug (I think) whose solution might help others who encounter a similar problem. I was playing with cellular automata, a bunch of tribes that move and grow as squares on a grid. Each tribe was stored in a game object, in a dictionary, by an ID number. I had a loop that made each tribe take an action, like so: for tribe in self.alltribes.values(): ## Line 1 ## Make sure tribe is still in play before activating. if tribe.ID in self.alltribes.keys(): ## Line 2 tribe.Go() self.age += 1 Some events would cause a tribe to merge with another, deleting both and creating a new tribe with a new ID value. Other events would create a new tribe. I was getting a strange error in which a tribe would try to move from coordinates that it wasn't actually at, crashing the program. I narrowed down that this only happened when a tribe was deleted, and then another tribe was randomly created with the same ID in the same turn. The reason seems to be this. Line 1 creates a list of tribes when the loop begins, _containing the tribe objects themselves_. When a game event deletes a tribe, it's still present in memory until the end of the loop... so the loop checks the deleted tribe's ID, sees that there's still a tribe with that ID (the newly created one), and runs _the deleted tribe_, which shouldn't happen. So I changed line 2 to: if tribe in self.alltribes.values(): ## Line 2b This way, the tribe is checked not as an ID#, but as a Python object, against the list of objects in self.alltribes.values. If the tribe is deleted, it won't show up in the list when it's checked, so the test will fail as it should. Well, I'm not sure I'd say that's a good solution either way. You should think *really* carefully about iterating over a dictionary you're also mutating. It also seems like a really strange way to do cellular automata, since you're letting the hash order of the dictionary influence the algorithm. The way you're using the dict is really strange too, foo in dict.keys() is an order of magnitude slower than foo in dict.. and checking existence in values() is a pretty good sign you're doing something wrong or using the wrong kind of data structure. I'd create a new alltribes dict on every generation. It'd be faster than what you're doing now, be more deterministic, and a lot easier to get right. I wouldn't classify this as a memory bug either. It doesn't really have anything to do with memory. -bob
Re: [pygame] Subtle Memory Bug
If you're using ID numbers, they really should be unique.On 7/10/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Jul 10, 2006, at 2:27 PM, Kris Schnee wrote: I've just solved a tricky bug (I think) whose solution might help others who encounter a similar problem. I was playing with cellular automata, a bunch of tribes that move and grow as squares on a grid. Each tribe was stored in a game object, in a dictionary, by an ID number. I had a loop that made each tribe take an action, like so: for tribe in self.alltribes.values(): ## Line 1 ## Make sure tribe is still in play before activating. if tribe.ID in self.alltribes.keys(): ## Line 2 tribe.Go() self.age += 1 Some events would cause a tribe to merge with another, deleting both and creating a new tribe with a new ID value. Other events would create a new tribe. I was getting a strange error in which a tribe would try to move from coordinates that it wasn't actually at, crashing the program. I narrowed down that this only happened when a tribe was deleted, and then another tribe was randomly created with the same ID in the same turn. The reason seems to be this. Line 1 creates a list of tribes when the loop begins, _containing the tribe objects themselves_. When a game event deletes a tribe, it's still present in memory until the end of the loop... so the loop checks the deleted tribe's ID, sees that there's still a tribe with that ID (the newly created one), and runs _the deleted tribe_, which shouldn't happen. So I changed line 2 to: if tribe in self.alltribes.values(): ## Line 2b This way, the tribe is checked not as an ID#, but as a Python object, against the list of objects in self.alltribes.values. If the tribe is deleted, it won't show up in the list when it's checked, so the test will fail as it should.Well, I'm not sure I'd say that's a good solution either way. You should think *really* carefully about iterating over a dictionaryyou're also mutating. It also seems like a really strange way to docellular automata, since you're letting the hash order of thedictionary influence the algorithm. The way you're using the dict is really strange too, foo in dict.keys() is an order of magnitudeslower than foo in dict.. and checking existence in values() is apretty good sign you're doing something wrong or using the wrong kind of data structure.I'd create a new alltribes dict on every generation. It'd be fasterthan what you're doing now, be more deterministic, and a lot easierto get right.I wouldn't classify this as a memory bug either. It doesn't really have anything to do with memory.-bob-- Andrew Ulysses Bakerfailrate
Re: [pygame] Subtle Memory Bug
It's probably not the uniqueness of ID numbers that's breaking his code, it's the fact that he has two different generations in the same data structure. That's simply not how you should do what he's trying to do.-bobOn Jul 10, 2006, at 4:51 PM, andrew baker wrote:If you're using ID numbers, they really should be unique.On 7/10/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Jul 10, 2006, at 2:27 PM, Kris Schnee wrote: I've just solved a tricky bug (I think) whose solution might help others who encounter a similar problem. I was playing with cellular automata, a bunch of "tribes" that move and grow as squares on a grid. Each tribe was stored in a game object, in a dictionary, by an ID number. I had a loop that made each tribe take an action, like so: for tribe in self.alltribes.values(): ## Line 1 ## Make sure tribe is still in play before activating. if tribe.ID in self.alltribes.keys(): ## Line 2 tribe.Go() self.age += 1 Some events would cause a tribe to merge with another, deleting both and creating a new tribe with a new ID value. Other events would create a new tribe. I was getting a strange error in which a tribe would try to move from coordinates that it wasn't actually at, crashing the program. I narrowed down that this only happened when a tribe was deleted, and then another tribe was randomly created with the same ID in the same turn. The reason seems to be this. Line 1 creates a list of tribes when the loop begins, _containing the tribe objects themselves_. When a game event deletes a tribe, it's still present in memory until the end of the loop... so the loop checks the deleted tribe's ID, sees that there's still a tribe with that ID (the newly created one), and runs _the deleted tribe_, which shouldn't happen. So I changed line 2 to: if tribe in self.alltribes.values(): ## Line 2b This way, the tribe is checked not as an ID#, but as a Python object, against the list of objects in self.alltribes.values. If the tribe is deleted, it won't show up in the list when it's checked, so the test will fail as it should.Well, I'm not sure I'd say that's a good solution either way. You should think *really* carefully about iterating over a dictionaryyou're also mutating. It also seems like a really strange way to docellular automata, since you're letting the hash order of thedictionary influence the algorithm. The way you're using the dict is really strange too, "foo in dict.keys()" is an order of magnitudeslower than "foo in dict".. and checking existence in values() is apretty good sign you're doing something wrong or using the wrong kind of data structure.I'd create a new alltribes dict on every generation. It'd be fasterthan what you're doing now, be more deterministic, and a lot easierto get right.I wouldn't classify this as a memory bug either. It doesn't really have anything to do with memory.-bob-- Andrew Ulysses Baker"failrate"
[pygame] Frantic memory usage
I found some image filmstrips I was not unloading after they're cut up into image arrays, and it freed up a decent amount of memory, but my game is still a hog. I totalled the amount of disk space for all images used by the starship (different weapons, explosions, thruster, etc.), and it's 600Kb. However, when I comment out the line that loads the starship_manager, the memory usage drops by a whopping 17Mb. It's even worse for the first enemy, which is loaded when the first level begins. 355Kb of images, but the memory usage skyrockets another 40Mb when it loads on the first level. I'm doing something braindead somewhere, just haven't tracked it down yet. The code is spread across dozens of source files, but if anyone's interested it's at http://medievalelks.com/code.zip. I honestly don't expect anyone to take the time to look at such a volume, but I've been requested several times to post it so there it is. I didn't include any data files, just code. Anyway, I'm making some progress. Oh, and I scaled down the game to 640x480, which also helps the performance. Removed some redundant-sounding music loops, too. Download size is now a svelte 13Mb :-).
Re: [pygame] Subtle Memory Bug
Oh, absolutely. However, they should be unique, otherwise there's no point in having them :DOn 7/10/06, Bob Ippolito [EMAIL PROTECTED] wrote:It's probably not the uniqueness of ID numbers that's breaking his code, it's the fact that he has two different generations in the same data structure. That's simply not how you should do what he's trying to do. -bobOn Jul 10, 2006, at 4:51 PM, andrew baker wrote:If you're using ID numbers, they really should be unique. On 7/10/06, Bob Ippolito [EMAIL PROTECTED] wrote: On Jul 10, 2006, at 2:27 PM, Kris Schnee wrote: I've just solved a tricky bug (I think) whose solution might help others who encounter a similar problem. I was playing with cellular automata, a bunch of tribes that move and grow as squares on a grid. Each tribe was stored in a game object, in a dictionary, by an ID number. I had a loop that made each tribe take an action, like so: for tribe in self.alltribes.values(): ## Line 1 ## Make sure tribe is still in play before activating. if tribe.ID in self.alltribes.keys(): ## Line 2 tribe.Go() self.age += 1 Some events would cause a tribe to merge with another, deleting both and creating a new tribe with a new ID value. Other events would create a new tribe. I was getting a strange error in which a tribe would try to move from coordinates that it wasn't actually at, crashing the program. I narrowed down that this only happened when a tribe was deleted, and then another tribe was randomly created with the same ID in the same turn. The reason seems to be this. Line 1 creates a list of tribes when the loop begins, _containing the tribe objects themselves_. When a game event deletes a tribe, it's still present in memory until the end of the loop... so the loop checks the deleted tribe's ID, sees that there's still a tribe with that ID (the newly created one), and runs _the deleted tribe_, which shouldn't happen. So I changed line 2 to: if tribe in self.alltribes.values(): ## Line 2b This way, the tribe is checked not as an ID#, but as a Python object, against the list of objects in self.alltribes.values. If the tribe is deleted, it won't show up in the list when it's checked, so the test will fail as it should.Well, I'm not sure I'd say that's a good solution either way. You should think *really* carefully about iterating over a dictionaryyou're also mutating. It also seems like a really strange way to docellular automata, since you're letting the hash order of thedictionary influence the algorithm. The way you're using the dict is really strange too, foo in dict.keys() is an order of magnitudeslower than foo in dict.. and checking existence in values() is apretty good sign you're doing something wrong or using the wrong kind of data structure.I'd create a new alltribes dict on every generation. It'd be fasterthan what you're doing now, be more deterministic, and a lot easierto get right.I wouldn't classify this as a memory bug either. It doesn't really have anything to do with memory.-bob-- Andrew Ulysses Bakerfailrate -- Andrew Ulysses Bakerfailrate
