Performance, frame rate, and judging

[Dean Brettle]

Hi all,

First, many thanks to the developers for creating such a fun game!  I
might actually get some regular exercise now... :-)

At the moment I'm trying to play PyDance on a 400 MHz K6-III (running
Fedora Core 2 with psyco and i586-optimized SDL).  I realize that my
processor is less than the "acceptable" P3-500 mentioned in the manual,
but I'd rather spend some time improving performance than upgrading my
processor.  

I get an average FPS for 6Jan02 (Basic) of 12.  The FPS ranges from 9 to
16 depending on how many arrows are on the screen.  Visually, I can live
with that frame rate.  The problem is that the low frame rate hurts my
score because the dance() function only polls the pad once per frame. 
At 12 FPS, the pad only gets polled about once every 83ms.  By default
the judge won't give anything better than a "Great" unless I step within
45ms of the beat, so getting "Perfect" and "Marvelous" marks is almost
entirely luck. :-(  Moreover, to get "Marvelous" marks based entirely on
skill I'd need a machine capable of doing 44 FPS.  

I tried changing the code so that the display updates and pad-polling
were done in separate threads, but Linux wouldn't context switch
regularly enough to fix the problem.  The only other option I see is to
sprinkle pad polling strategically around the rest of the code. 
Specifically, this would involve:

1. Splitting the call to pygame.display.update() into multiple calls
(with non-overlapping rectangles), and adding polling between the calls.
2. Adding polling inside some loops in player.py
3. Perhaps, adding some polling in arrows.py.

Given that the HACKING file says "We should not sacrifice code clarity
for speed except in extreme cases", would a patch which makes the above
sorts of changes be considered for inclusion in a future release?

On a related note, it might help improve the accuracy of the judging to
assume that the player stepped halfway between the time of the previous
poll and the time of the current poll.  At the moment, it looks like the
code assumes that the player stepped at the time of the current poll. 
That means a player that always steps exactly on the beat will be judged
as stepping up to 1 frame late (never early).

--Dean