Re: [pygame] Optimization, double buffered pygames

[Syver Enstad <syver-en@online.no>]

Pete Shinners <pete@visionart.com> writes:
> 
> hmm, perhaps the windowed version is using a faster display depth than
> 
> fullscreen? the windowed mode is 16bit, while the fullscreen is 32bit?
> 
> usually this is the other way around though, since the fullscreen mode
> 
> can run at any depth, and the windowed mode is forced to match the
> desktop depth.

I have run it in different display depths which doesn't seem to matter
much for framerate. I usually just run the game code without asking
for a bit depth, and that means I am using 32 bit colors, but I tried
switching to 8 bit and 16 bit but that didn't help. Maybe it has
something to do with how my graphics card works? It's a fairly old
Nvidia card (GeForce Pro, the first GeForce they made).  


> 
> try running fullscreen without the HWSURFACE and DOUBLEBUF flags?
> this will probably run slower for both windowed and fullscreen, but
> i'm wondering how the speeds will compare for that?  obviously the
> fullscreen and windowed displays are being setup differently, i'm
> just wondering what that difference might be. you can get a bit of
> information about the display mode by doing this.

Huh, mighty strange, sending just 0 (SWSURFACE) pops up from 18 and
something to 38 something in fullscreen mode. In windowed mode it
seems much the same. Setting only the DOUBLEBUF flag sets it back to
18 and something, only HWSURFACE gets the same low frame rate the same
but adds some unsightly flickering when DOUBLEBUF is not used.

I think I am a victim of the syndrome described in one of the
instructions for pygame, which says something like this : HWSURFACE
that sounds fast, I'll use that. DOUBLEBUF, that sounds fast I'll use
that. Maybe it is something that I am doing wrong, that makes the
DOUBLEBUF mode perform badly. I can describe the way I do things now,
maybe someone has an idea if I am doing something wrong.

To begin with, the program I am making has not been optimized for
speed, I am just exploring computer game concepts, and I know that I
can speed up many things, but my focus here is to understand why
doublebuf is so slow.

I make a screen that is 600x400.

I make two subsurfaces of that screen, one for a status panel, one for
the game display. 

For each frame I blit a bitmap onto the status panel
surface, fill the game display with a single color.

Then I loop through the game's objects which are bricks, a bat and a
ball, and tell them to draw themselves. As the objects have a simple
appearance I just use the fill method on the surface.

That's it graphics wise. Again, I know that it's slow to have each
brick call fill on the surface but why so much slower for DOUBLEBUF?


Btw, I rewrote some parts of the moveit demo to use
screen = pygame.display.set_mode((640, 480),
HWSURFACE|DOUBLEBUF|FULLSCREEN)

removed the code in moveit that deletes the sprites and replaced the
update call(s) with a single call to pygame.display.flip()

It runs very smooth indeed at 75 fps. 

I have made some more measurements.

If I disable the blitting for each frame to the stats panel subsurface
I get about 37 fps with DOUBLEBUF and HWSURFACE (which is the same
frame rate as when running with a software surface and no doublebuf),
Running without the status panel subsurface blitting with just SWSURFACE gives a
modest speedup from 37 fps to 41 fps. Interesting!?

-- 

Vennlig hilsen 

Syver Enstad


____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org