[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?)