Re: [pygame] Weird lag
How is collision testing done? 200 sprites tested against 200 sprites
is a big difference from just testing 2-3 sprites against 200, in particular
if you do the iteration in Python.
/P
On 2009-03-01 (Sun) 08:51, Daniel Mateos wrote:
Hey again,
In a 2d scroller game im making i seem to get FPS drops at random
points, i am using the Clock class to keep it at a constant 60 fps and
it never seems to go above 9%-15% cpu usage so im not sure what could be
causing it.
Seems to run well for 90% of the time with spikes that drop the fps to
10-40 at some points in the level, other times it runs fine at exactly
the same points and its not doing anything extra doing these spikes, im
bliting about 100-200 sprites per frame.
Some quick profiler output, doesnt really tell me much tho:
ncalls tottime percall cumtime percall filename:lineno(function)
1233 10.1770.008 10.1770.008 {built-in method tick}
12334.9820.0044.9820.004 {pygame.display.flip}
1536993.2110.0003.2110.000 {method 'blit' of
'pygame.Surface' objects}
5425200.4240.0000.4240.000
game_level.py:129(CheckOnScreen)
12330.4190.0003.8890.003 game_level.py:56(RenderLevel)
4872870.3120.0000.4190.000
game_level.py:105(CheckCollide)
12330.2910.0000.7570.001
game_level.py:122(CheckCollides)
36150.1600.0000.1600.000 {method 'render' of
'pygame.font.Font' objects}
10.1500.1500.1500.150 {pygame.base.init}
10.1260.126 20.979 20.979 main.py:18(module)
4872870.1070.0000.1070.000 {method 'colliderect' of
'pygame.Rect' objects}
10.0930.0930.1210.121 {pygame.display.set_mode}
493258/4930310.0480.0000.0480.000 {len}
40.0480.0120.0480.012
{pygame.imageext.load_extended}
12330.0420.0000.0420.000 {pygame.event.poll}
12330.0400.0000.0960.000 game_osd.py:79(DrawBar)
40.0340.0080.0340.008 {method 'convert' of
'pygame.Surface' objects}
12330.0330.0000.8050.001 game_level.py:44(update)
10.0170.0170.1250.125 __init__.py:25(module)
12330.0160.0000.0410.000 game_osd.py:106(WriteText)
Any help or suggestions for better profileing/tracking down the lag
would be good :)
--
Daniel Mateos
http://daniel.mateos.cc
Re: [pygame] Weird lag
Peter Gebauer wrote: How is collision testing done? 200 sprites tested against 200 sprites is a big difference from just testing 2-3 sprites against 200, in particular if you do the iteration in Python. At the moment only the player char is checked for collisions so its 1:200. http://github.com/dmateos/paperworld/tree/master is the source if anyone cares enough to take a look. -- Daniel Mateos http://daniel.mateos.cc
Re: [pygame] Weird lag
Your game is spending a little over 60% of its time blitting. About 20% is evaluation, and the rest of the work is overhead. That might seems high given the complexity, but window size really matters when it comes to software rendering. Decrease the window size to 800x500 (for widescreen) or 640x480 and you'll notice a large performance boost. The other thing I noticed is that the control code (or something setting flags that disable it or something) is sort of crappy. It tends to freeze and jitter even when the frame rate holds steady. A quick suggestion might be to drop the onscreen checks for the player and enemies. There won't be that many of them and it takes longer to check than it does to draw them. They're not going to draw, the blitter is coded in C and will figure out much more quickly than your Python code that it doesn't need to draw anything. If you start getting hundreds of sprites offscreen, wherever possible, group them together and test in bulk. Every time you call a function or a method or get an attribute, you accrue overhead. You want as few loops as possible and as few tests inside of them as possible. As a rule in Python, it's almost always faster to do more work unnecessarily than test to see if you need to. For example, there was one portion in my code where I had 3 or 4 sets that I needed to ensure were empty. It was much faster to reassign them to set() than it was to test if they had anything inside of them. Another option is to look at OpenGL for graphics. It won't _speed up_ your drawing without some complex optimization, but it will make sprite size, screen size and number of changed pixels entirely irrelevant. It also gets you scaling, rotation, blending, and color tinting effects for free. Since easy, high-performance sprite code code using Pygame/OpenGL seems pretty hard to come by, I'm thinking of releasing the base classes I've been writing for my game over the past week. I've created a glSprite class and a glSpriteObjectGroup container that holds, updates, and draws OpenGL objects like pygame sprite groups do. If you're interested, I can give you a copy before it's finished, if only as an example, if you decide you want to go the OpenGL route. -Zack On Mar 1, 2009, at 3:24 AM, Daniel Mateos wrote: Peter Gebauer wrote: How is collision testing done? 200 sprites tested against 200 sprites is a big difference from just testing 2-3 sprites against 200, in particular if you do the iteration in Python. At the moment only the player char is checked for collisions so its 1:200. http://github.com/dmateos/paperworld/tree/master is the source if anyone cares enough to take a look. -- Daniel Mateos http://daniel.mateos.cc
Re: [pygame] Weird lag
Zack Schilling wrote: Your game is spending a little over 60% of its time blitting. About 20% is evaluation, and the rest of the work is overhead. That might seems high given the complexity, but window size really matters when it comes to software rendering. Decrease the window size to 800x500 (for widescreen) or 640x480 and you'll notice a large performance boost. The other thing I noticed is that the control code (or something setting flags that disable it or something) is sort of crappy. It tends to freeze and jitter even when the frame rate holds steady. Yeah my control code needs some work :), and i did increase the window size recently and thats probably when i noticed the performance issues so you could be right. A quick suggestion might be to drop the onscreen checks for the player and enemies. There won't be that many of them and it takes longer to check than it does to draw them. They're not going to draw, the blitter is coded in C and will figure out much more quickly than your Python code that it doesn't need to draw anything. If you start getting hundreds of sprites offscreen, wherever possible, group them together and test in bulk. Every time you call a function or a method or get an attribute, you accrue overhead. You want as few loops as possible and as few tests inside of them as possible. As a rule in Python, it's almost always faster to do more work unnecessarily than test to see if you need to. For example, there was one portion in my code where I had 3 or 4 sets that I needed to ensure were empty. It was much faster to reassign them to set() than it was to test if they had anything inside of them. Ah yeah i was aware that blit does that but i wasn't quite sure what would be more efficient, coming from c/c++ its amazing how fast you can get stuff done in python :) but yeah ill have to be more careful with not going to crazy with checks and crap. Another option is to look at OpenGL for graphics. It won't _speed up_ your drawing without some complex optimization, but it will make sprite size, screen size and number of changed pixels entirely irrelevant. It also gets you scaling, rotation, blending, and color tinting effects for free. Since easy, high-performance sprite code code using Pygame/OpenGL seems pretty hard to come by, I'm thinking of releasing the base classes I've been writing for my game over the past week. I've created a glSprite class and a glSpriteObjectGroup container that holds, updates, and draws OpenGL objects like pygame sprite groups do. If you're interested, I can give you a copy before it's finished, if only as an example, if you decide you want to go the OpenGL route. -Zack Yeah OpenGL is what i plan on getting into next after a bit more SDL practice. Thanks for the reply, was very informative. -- Daniel Mateos http://daniel.mateos.cc
[pygame] Redraw under mouse cursor in HWSURFACE mode
I'm noticing a weird little artifact namely that I get left over fragments of a surface i redraw on to screen where the mouse cursor moves. It appears as if my code is interacting with whatever controls cursor redraw. I notice that this only happens when i go to fullscreen mode and enable hardware draw (HWSURFACE (not using double buffer right now since not 'flipping display' but rather controling exactly what rectangles get redrawn). I need HWSURFACE to be on for performance. So seems like in HWSURFACE mode the mouse cursor is run differently and is interacting with my redraws (i.e. fails to let them complete well under it). Anyone familiar with this kind of mouse cursor issue in HWSURFACE mode? Thanks Lin .
[pygame] GMArcade Contest02 One-Month Left!
Hello PyGame users, Just wanted to let you know there is still one month left to get your entry in for GMArcade.com's Time contest. I have yet to hear from any PyGame users on wether they are entering, and there are some pretty neat game development books up for grabs. For more info on the contest visit the contest page: http://gmarcade.com/contest02/ Or the contest forum topic: http://gmarcade.com/joomla/index.php?option=com_fireboardItemid=29func=viewcatid=4id=2016#2016 I hope to see some of you enter! ~Admin Matt from GMArcade http://gmarcade.com ma...@gmarcade.com
Re: [pygame] Redraw under mouse cursor in HWSURFACE mode
are you using the OS cursor, or blit-ing your own? (ie: hide cursor, and draw cursor sprite ) On Sun, Mar 1, 2009 at 5:19 PM, Lin Parkh lpa...@comcast.net wrote: I'm noticing a weird little artifact namely that I get left over fragments of a surface i redraw on to screen where the mouse cursor moves. It appears as if my code is interacting with whatever controls cursor redraw. I notice that this only happens when i go to fullscreen mode and enable hardware draw (HWSURFACE (not using double buffer right now since not 'flipping display' but rather controling exactly what rectangles get redrawn). I need HWSURFACE to be on for performance. So seems like in HWSURFACE mode the mouse cursor is run differently and is interacting with my redraws (i.e. fails to let them complete well under it). Anyone familiar with this kind of mouse cursor issue in HWSURFACE mode? Thanks Lin . -- Jake
Re: [pygame] Weird lag
Are you re-creating the font surface every frame? Or are you cache-ing the
.render() output to .blit() ?
On Sat, Feb 28, 2009 at 4:21 PM, Daniel Mateos dan...@mateos.cc wrote:
Hey again,
36150.1600.0000.1600.000 {method 'render' of
'pygame.font.Font' objects}
Any help or suggestions for better profileing/tracking down the lag
would be good :)
--
Daniel Mateos
http://daniel.mateos.cc
--
Jake
Re: [pygame] Redraw under mouse cursor in HWSURFACE mode
I'm using OS cursor (or whatever pygame defaults to (on windows)). Is that not good practice? - Original Message - From: Jake b To: pygame-users@seul.org Sent: Sunday, March 01, 2009 4:24 PM Subject: Re: [pygame] Redraw under mouse cursor in HWSURFACE mode are you using the OS cursor, or blit-ing your own? (ie: hide cursor, and draw cursor sprite ) On Sun, Mar 1, 2009 at 5:19 PM, Lin Parkh lpa...@comcast.net wrote: I'm noticing a weird little artifact namely that I get left over fragments of a surface i redraw on to screen where the mouse cursor moves. It appears as if my code is interacting with whatever controls cursor redraw. I notice that this only happens when i go to fullscreen mode and enable hardware draw (HWSURFACE (not using double buffer right now since not 'flipping display' but rather controling exactly what rectangles get redrawn). I need HWSURFACE to be on for performance. So seems like in HWSURFACE mode the mouse cursor is run differently and is interacting with my redraws (i.e. fails to let them complete well under it). Anyone familiar with this kind of mouse cursor issue in HWSURFACE mode? Thanks Lin . -- Jake
Re: [pygame] surfarray on 64-bit machines
Marius Gedminas wrote:
Try
pygame.surfarray.user_arraytype('numpy')
at the start. NumPy became the default only recently with 1.9.
Unfortunately, this gives me
AttributeError: 'module' object has no attribute 'user_arraytype'
I've got pygame 1.8.1 here (Ubuntu's 1.8.1release-0ubuntu1 to be precise)
Marius Gedminas
A typo. It should be user_arraytype.
Lenard
--
Lenard Lindstrom
le...@telus.net
Re: [pygame] surfarray on 64-bit machines
hehe, double typo... 'use_arraytype' http://www.pygame.org/docs/ref/surfarray.html#pygame.surfarray.use_arraytype On Mon, Mar 2, 2009 at 1:43 PM, Lenard Lindstrom le...@telus.net wrote: A typo. It should be user_arraytype.
Re: [pygame] Weird lag
hi,
try timing some parts... Then you might be able to see where the lag
is happening.
Each frame you should be able to see that they are similar values. If
they are not, you should be able to debug where your delay is.
Here's your mainloop end part modified to add a couple of timers in...
timer = time.time
t1 = timer()
pygame.display.flip()
t2 = timer()
clock.tick(60)
t3 = timer()
print flip:%s tick:%s: % (t2 - t1, t3 - t2)
You can add similar timing parts for the other sections of your game.
Then add some checks like this...
if t2-t1 0.002:
# dump debug information about game state.
pass
On Mon, Mar 2, 2009 at 11:29 AM, Jake b ninmonk...@gmail.com wrote:
Are you re-creating the font surface every frame? Or are you cache-ing the
.render() output to .blit() ?
On Sat, Feb 28, 2009 at 4:21 PM, Daniel Mateos dan...@mateos.cc wrote:
Hey again,
3615 0.160 0.000 0.160 0.000 {method 'render' of
'pygame.font.Font' objects}
Any help or suggestions for better profileing/tracking down the lag
would be good :)
--
Daniel Mateos
http://daniel.mateos.cc
--
Jake
Re: [pygame] surfarray on 64-bit machines
On Mon, Mar 02, 2009 at 02:06:35PM +1100, René Dudfield wrote:
hehe, double typo...
'use_arraytype'
http://www.pygame.org/docs/ref/surfarray.html#pygame.surfarray.use_arraytype
That works better, thanks!
I've refactored PySpaceWar's fading title code into three classes now,
one that uses plain PyGame, one that uses Numeric, and one that uses
NumPy. The last one will be preferred if available.
Marius Gedminas
--
main(k){float i,j,r,x,y=-16;while(puts(),y++15)for(x
=0;x++84;putchar( .:-;!/)|IH%*#[k15]))for(i=k=r=0;
j=r*r-i*i-2+x/25,i=2*r*i+y/10,j*j+i*i11k++111;r=j);}
/* Mandelbrot in ASCII. */
signature.asc
Description: Digital signature
Re: [pygame] surfarray on 64-bit machines
It's the computer, honest. It keeps changing user to user. Oh no, not again. René Dudfield wrote: hehe, double typo... 'use_arraytype' http://www.pygame.org/docs/ref/surfarray.html#pygame.surfarray.use_arraytype On Mon, Mar 2, 2009 at 1:43 PM, Lenard Lindstrom le...@telus.net wrote: A typo. It should be user_arraytype. -- Lenard Lindstrom le...@telus.net
