Re: [pygame] +1 for sdl directx backend on windows (compiled latest pygame to find opengl fullscreen badness)
On Sat, Nov 10, 2007 at 11:51:48AM -0800, Brian Fisher wrote: Thanks to Johnny Popplewell sharing his great work on building pygame and me finally moving over to python 2.5, I was finally able to get a usable pygame built from subversion sources (yay!) Great! snip! P.S. just in case some of this helps other people build pygame from source on windows... I built it with the toolkit compiler, which you can get from the second link on this page: http://npg.dl.ac.uk/MIDAS/download/midassort/midassort_Windows.html Thanks for this link to the toolkit compiler. I failed to find a working link as Microsoft don't host it anymore :-(. I'll add it to my page, cheers, John.
Re: [pygame] dynamic pygame programming
The best situation for this would be to program things very functional. That way you can keep most of the program in an easily reloadable module for when the game is paused. So instead of: class man: def update(self): if not self.touchground(): fall if self.walking(): move You would have something more like this: class man: def update(self): functions.manUpdate(self) #in module functions def manUpdate(self): Then when you unpause the game: reload(functions) - Rebinding functions to existing instances is not pretty :) Another more complex solution, one which I have not personally tried, would be to make everything inherit from one level above where you normally would inherit from. That way you can reload the parent class and all of the methods at least would be reloaded as well: --superclasses.py-- class man: def update(self): if not self.touchground(): fall if self.walking(): move --game.py-- import superclasses class manInstance(superclasses.man): pass Then I think when you reload superclasses, the methods on manInstance will be delegated to the updated superclasses.man class. I'm not so sure about that method. - Also you could use exec to run all of your code. But that is very bad and insecure, and doesn't necessarily solve the problem of instances. On Nov 7, 2007 9:46 AM, Casey Duncan [EMAIL PROTECTED] wrote: On Nov 7, 2007, at 5:28 AM, Lionel Barret De Nazaris wrote: Hi all, I am considering using pygame for a new prototype and I wonder if any of you has any experience with what I call dynamic programming. Basically, I want to launch Ipython, import the main module of the program, run it , then, pause it, modify any module and having them reloaded and relinked. All this without restarting the program. Would that be possible ? if so how ? It's very smalltalkish, but i wonder if it is possible in Python Lionel Yes, absolutely yes. Just please don't ask me to debug it ;^) -Casey
Re: [pygame] .png saving
Brian Fisher wrote:
I've been playing with the latest pygame source code, and it looks
like this is the situation with openGL display surfaces and saving
pngs...
the image module source has a c function in it opengltosdl in it
that was written to use glReadPixels from the pyOpenGL package to get
a surface from the openGL display. It looks like it is used with the
basic image save function and with image.tostring so it should work
with those 2 things - however with PyOpenGL 3.0, glReadPixels now
returns a OpenGL.arrays.ctypesarrays instead of a python string, so
opengltosdl segfaults when trying to copy data from the array into a
surface.
the imagext module has a c function to save a surface to a png, but
it's not in pygame 1.7. it appears to use libpng directly, so it seems
pygame should be able to save a png. However the function uses a blit
in order to convert the surface to a format that is appropriate for
png saving (24 or 32 bit), so the current version of that function
will fail with an opengl display because openGL display surfaces are
created with dummy surface contents, which can be passed to blit
functions, but will not work (apparently they crash in such
instances).
So with PyOpenGL 3.0 and pygame svn as it is, all options to get at
the openGL display will crash...
so does anybody know how to get a string from a ctypes sized array in
python or how to get the void * to a ctypes sized array in extension
source code?
ctypes objects support the buffer interface, and slicing a entire buffer
object as a slice returns a string.
from ctypes import *
A3 = c_short * 3
a = A3(1, 2, 3)
buffer(a)[:]
'\x01\x00\x02\x00\x03\x00'
c_void_p objects and Python integers are pretty much interchangeable, so
you can use addressof(). An array can also be cast to c_void_p.
vp = cast(a, c_void_p)
vp
c_void_p(13711000)
If the array is an array of character then it has a raw attribute.
C5 = c_char * 5
c = C5('a','b','c','d','e')
c.raw
'abcde'
--
Lenard Lindstrom
[EMAIL PROTECTED]
[pygame] New on the mailing list with a strange FPS behavior
Hi there, I subscribed to the mailing list today because I've used pygame for a while now and I begin to be comfortable with it. Today I've come into a strange behavior with my rendering loop. I use dirty rectangles to update the screen so my render function looks like this : def draw(self): self.spritegroup1.clear(self.window,self.background) self.spritegroup2.clear(self.window,self.background) # ... dirty = self.spritegroup1.draw(self.window) + self.spritegroup2.draw(self.window) # ... pygame.display.update(dirty) self.clock.tick (TARGET_FPS) I've measured the time to each call to this draw function and the normal time is 15ms (quite fast) but from time to time, the function takes 500ms to execute !! And of course I see my game freezing... Can anyone tell me where I should look at ? -- Ghislain Lévêque
Re: [pygame] New on the mailing list with a strange FPS behavior
On 11 Nov 2007 at 22:41, Ghislain Leveque wrote: Hi there, I subscribed to the mailing list today because I've used pygame for a while now and I begin to be comfortable with it. Wellcome! Today I've come into a strange behavior with my rendering loop. I use dirty rectangles to update the screen so my render function looks like this : def draw(self): self.spritegroup1.clear(self.window,self.background) self.spritegroup2.clear(self.window,self.background) # ... dirty = self.spritegroup1.draw(self.window) + self.spritegroup2.draw(self.window) # ... pygame.display.update(dirty) self.clock.tick (TARGET_FPS) I've measured the time to each call to this draw function and the normal time is 15ms (quite fast) but from time to time, the function takes 500ms to execute !! And of course I see my game freezing... Can anyone tell me where I should look at ? -- Ghislain Lévêque 1. I don't known if clock.tick() can be to blame, maybe you can try to bypass clock.tick to see if times are irregular. 2. If the size or quantity of sprites have great variations, so can the time. And if the workload is too variable, probably clock.tick can magnify the diference. 3. Memory garbage collection kicks in. you can try to do a explicit garbage collection after each M frames to see if max time is reduced. 4. At each frame you can try to print some stats to see if there something unexpected, by example: print len(dirty), other info that you think is relevant, maybe the total dirty area claxo
Re: [pygame] New on the mailing list with a strange FPS behavior
On Nov 11, 2007 1:41 PM, Ghislain Leveque [EMAIL PROTECTED] wrote: Today I've come into a strange behavior with my rendering loop. I've measured the time to each call to this draw function and the normal time is 15ms (quite fast) but from time to time, the function takes 500ms to execute !! And of course I see my game freezing... Are you 100% sure the problem is the rendering loop, and that it's not something else causing the problem? The reason I ask is you said your draw function usually takes 15ms... if your target fps is 60, then that means drawing is taking more than 90% of your 16.6ms per frame budget. If there was some other external element causing a delay by interrupting your program, it would interrupt your draw 90% of the time, and would make it look like it was the draw's fault. One way to test this is to time all the parts of your game and log them or draw them to a real time display or something. If you see the 500ms delay come in some other component, or you see your game freeze but draw didn't go to 500ms, then you know that you are getting a long delay that draw is not causing. if that's the case, it's probably another app (this can happen with an app that takes 100% cpu, which it sounds like yours does if draw takes 15ms) or some background thread or asynchronous process (I think streaming audio with pygame can do it, or garbage collection like claxo suggested). You can sometimes discover the offender with either a live file access monitoring tool (try filemon if on windows) or by a live cpu use monitor (just see if some other process jumps in every few seconds) If you are 100% sure it's in your draw... then you could maybe try putting in code to time each draw, and do something special if it goes long. You could try doing the draw again and time that to find out if it's due to what how you drew that particular frame or not. If a slow draw is repeatable, then you could run with a debugger and step through the bad draw. If it's not repeatable... well.. good luck to you...
Re: [pygame] New on the mailing list with a strange FPS behavior
Hi! This seems to sound like either an anti-virus program running in the background or something like SKYPE that takes up CPU time and will lock up the computer at an unpredictable time. I think all other programs running in the background should be turned off... Bruce - Original Message - From: claxo [EMAIL PROTECTED] To: pygame-users@seul.org Sent: Sunday, November 11, 2007 9:33 PM Subject: Re: [pygame] New on the mailing list with a strange FPS behavior On 11 Nov 2007 at 22:41, Ghislain Leveque wrote: Hi there, I subscribed to the mailing list today because I've used pygame for a while now and I begin to be comfortable with it. Wellcome! Today I've come into a strange behavior with my rendering loop. I use dirty rectangles to update the screen so my render function looks like this : def draw(self): self.spritegroup1.clear(self.window,self.background) self.spritegroup2.clear(self.window,self.background) # ... dirty = self.spritegroup1.draw(self.window) + self.spritegroup2.draw(self.window) # ... pygame.display.update(dirty) self.clock.tick (TARGET_FPS) I've measured the time to each call to this draw function and the normal time is 15ms (quite fast) but from time to time, the function takes 500ms to execute !! And of course I see my game freezing... Can anyone tell me where I should look at ? -- Ghislain Lévêque 1. I don't known if clock.tick() can be to blame, maybe you can try to bypass clock.tick to see if times are irregular. 2. If the size or quantity of sprites have great variations, so can the time. And if the workload is too variable, probably clock.tick can magnify the diference. 3. Memory garbage collection kicks in. you can try to do a explicit garbage collection after each M frames to see if max time is reduced. 4. At each frame you can try to print some stats to see if there something unexpected, by example: print len(dirty), other info that you think is relevant, maybe the total dirty area claxo
Re: [pygame] BUG: seg fault when loading image from file object
This bug (segfault when loading png from open file with pygame 1.7.1 on python 2.5 or python 2.4) is indeed caused by the SDL dll's (and smpeg.dll) included in the 1.7.1 release being linked against the visual studio 6.0 MSVCRT instead of the Visual Studio 7.1 MSCRT71.dll, like Rene said. So I rebuilt the SDL libraries with the 2003 toolkit compiler. The SDL sources I used were exact same versions as the ones the 1.7.1 package includes, and the SDL libs were linked to their dependencies statically same as in the 1.7.1 release (better for py2exe). So the rebuilt dll's should be functionally identical to the ones in the pygame 1.7.1 installers on pygame.org, except that the load from file object functions now work. I copied them into my site-packages directory and am using them that way - if anybody else wants to use them, they are here: http://thorbrian.com/SDLDependenciesUsingMSVCR71.zip --- ... I'd try to build a pygame 1.7.x installer for python 2.5 with these fixed sdl dlls, but I don't know how to get 1.7.1 sources or how to modify an installer package On Jun 21, 2007 4:24 PM, René Dudfield [EMAIL PROTECTED] wrote: I think this might be because the 1.7.1release for python2.5 didn't link against the correct C library. Files can not be shared amongst the two C libraries. On 6/22/07, Michael George [EMAIL PROTECTED] wrote: Hi, I'm running pygame 1.7.1release against python 2.5.1 on various windows flavors. When loading an image from a file object using pygame.image.load(...) I encounter a segmentation fault. Passing in a file name works fine, but since I also want to use the same code with tar files, I'd prefer to use file objects. To reproduce: import pygame pygame.init() pygame.image.load( file( 'foo.png' ) ) Thanks!
Re: [pygame] New on the mailing list with a strange FPS behavior
Hi all and thanks for your quick answers. First I will explain how I did measure and what make me think it's the draw that stucks : I use a custom MVC model and the main game object sends a cpu_tick event as quick as it can. I this cpu_tick loop, many things happen (objects move, towers fire, lose life, ) and the screen is drawn. In my controller object (the one which receives all the events and send them back to objects, I've a function like this that is called on every event received : def post(self,event): for listener in self.listeners: now = pygame.time.get_ticks() listener.notify(event) self.stats[listener].append((pygame.time.get_ticks() - now,event)) So, as you can see, I measure the time taken by each object to react to each event and the freeze is really created by the draw function. To be sure, I've added in my draw_function : def draw(self): now = pygame.time.get_ticks() # clear stuff # draw stuff self.stats.append(pygame.time.get_ticks() - now) And I can see the freezing. This morning, I tried my game on Windows (I'm developping on Linux) and, on Windows, the game is faster and don't freeze. So maybe RR4CLB is right and I just have another program using some of my CPU on the LInux box... I'll investigate more -- Ghislain Lévêque
Re: [pygame] New on the mailing list with a strange FPS behavior
2007/11/12, claxo [EMAIL PROTECTED]: On 11 Nov 2007 at 22:41, Ghislain Leveque wrote: Today I've come into a strange behavior with my rendering loop. 3. Memory garbage collection kicks in. you can try to do a explicit garbage collection after each M frames to see if max time is reduced. How do I do an explicite garbage collection ? Thanks -- Ghislain Lévêque
