[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [pygame] Some problem with WinXP Home and PyGame 1.7.1



> If I recall correctly, you can't have an interpreted session of pygame
> unless you type really fast, because XP thinks your app has locked up and
> helpfully does stuff for you...

All right, I found the "bug". Thanks for your tip - indeed, doing it all in 
a manual session just doesn't work. It has to be done in a script (poor 
Windows users... ;-) ).

Going back to the point - I was initializing the display with the following 
code:

pygame.display.set_mode( (x,y), flags, depth )

where flags were set to FULLSCREEN, DOUBLEBUF and HWSURFACE. The screen was 
being updated with the following code:

pygame.display.update( list_of_rects_to_update )

On my GNU/Linux box it has worked fine, but it failed to work on my Windows 
box. When I changed the update code to:

pygame.display.flip()

it finally ran. Not fine (there are some small issues), but I finally got 
something on the screen.

To sum it up: the problem was with my lack of understanding the differences 
between GNU/Linux systems and Windows. Now, one problem is behind me, but 
there is another one to fix.

The problem is with FPS. On my GNU/Linux box I get almost 300 FPS (without 
double buffering and hardware surfaces, I persume!), while on my Windows 
box only 20 FPS. Well - I suppose that it's due to updating all the screen 
with the pygame.display.flip() function instead of updating only those 
areas that actually have been modified.

So my problem is now 20 FPS on my Windows box. So far I haven't been able to 
find out how to update the screen in more efficient way. I took a look at 
some other people's sources, but all of them used this 
pygame.display.flip() function.

How can I get more that 20 FPS under Windows? How should I code animation 
and not update the whole screen?

(Perhaps I still have a problem with understanding how hardware, duble 
buffered surfaces work?)