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

[pygame] BUG: pygame.time tick()?



Hi all,

Could anyone comment on this problem with the otherwise fantastic
pygame.

pygame 1.8.0
OS Fedora 8 Linux 32-bit
python 2.5.1

Code essentials:-

clock = pygame.time.Clock()
while 1:
  clock.tick(30)
  # various sprite and text blits
  pygame.display.flip()

This code runs really well and looks great on my test systems (thanks
René), however when I transferred to a couple of new computers the
program has been hanging. All the moving sprites, moving text etc freeze
on the screen after a period of time.

I could ssh into the box and everything looked ok. The problem looked to
be that my pygame was hanging somewhere.

I noticed the hangs were occurring exactly on the hour and tracked the
problem to the fact that every hour these machines call ntpdate to set
the system clock.

I ssh'ed into a running computer and was able to reproduce the problem
by running ntpdate manually. The program froze at exactly the time that
I ran ntpdate.

For these machines, the BIOS clock was set to approx 2 hours behind the
current local time and the local time zone is 10 hours in advance of
UTC. Linux is configured for UTC.

So my analysis of the problem is as follows:-

ntpdate was changing the time by approximately 8 hours - quite a large
change. And I suspect that the
clock.tick(30)
statement is hanging at that point.
As I understand the function of clock.tick() it is to slow down the
processing to match the frame rate specified. So clock.tick() will have
a delay loop in it while it waits for the next frame interval to come
around. So it seems likely that the program would have frozen for 8
hours then come back to life.
(however I semi-tested this by changing the time back into the future
via ntpdate and the program did not come back into action again).

The time module is in C which is not a language I know so I have not
been able to diagnose the problem further.

Workarounds: for anyone reading this at a later date and having this
problem, the possible workarounds I can think of are:-
1) setting the UTC date and time correctly in the bios first up
2) setting the date and time using ntpdate on first installation then
rebooting (to set the hardware clock)
3) setting the date and time using ntpdate on first installation and
then using hwclock to write this time back to the BIOS
4) Having done one of the above 3, using ntpd instead of ntpdate to
ensure the time stays correct without major sudden changes.

The problem does not appear to happen now that I have corrected the
times (or has not happened since I corrected the times on those
computers).

It is also worth pointing out that the problem did not occur every time
ntpdate was run with a large time change; I put that down to the fact
that if ntpdate was run when the program was not in clock.tick() then it
was ok, but if it occurred when inside clock.tick() then the problem
could occur. Possibly the reverse could be true.

Does this sound likely?

Regards
John Leach