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

["Charlie Nolan" <funnyman3595@xxxxxxxxx>]

clock.tick goes through SDL_Delay, so the relevant source isn't in
pygame, but I'm guessing things look roughly like this:

def delay(ms):
    until = time.time() + ms
    sleep_time = ms
    while sleep_time > 0:
        time.sleep(sleep_time)
        sleep_time = until - time.time()

So what's happening is this:
1. delay is called and goes to sleep for 1/30th of a second.
2. clock is set back X hours.
3. delay wakes up, goes back to sleep for X hours.
4. clock is set forward X hours.
5. delay will still be sleeping for X hours, because it doesn't see
the new time.

Since the loop above is more or less the Right Way to do things, the
answer to your issue is contained in an old joke:
"Doc, you gotta help me."
"What's the matter?"
"My elbow hurts terribly when I do this."  *demonstrates*
"Well, don't do that!"

-FM


On 6/27/08, John Leach <john.leach@xxxxxxxxxxxxx> wrote:
> 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
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>