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