Re: [pygame] pygame.time.get_ticks() vs. time.clock()
On 5/24/07, Mike Wyatt [EMAIL PROTECTED] wrote: I'm working on a synchronized RTS using pygame and Python's socket library, and I've discovered that the values returned by pygame.time.get_ticks() and the time module's clock() method are not consistent. My test results suggest that pygame.time.get_ticks() runs slightly faster than time.clock(). time.clock() is not a good way to measure wall clock time portably. On some systems (unix) it returns cpu time used instead of wall clock time, and on windows it uses the cpu performance counters as source, but does seem to return wall clock time. Use time.time() for getting the time portably, or use get_ticks(). The important thing is that you should use the same source everywhere. Regards, Ulf
Re: [pygame] pygame.time.get_ticks() vs. time.clock()
I don't think you can rely on the time to be accurate - especially across machines, and different CPUs/OS's. Inaccurate to within 10ms is what XP can do. So... what to do? I think maybe use one of the machines as a master clock? Then sync to that? So you could add the master clocks time to every packet... then adjust for latency? I think you'd need something like that if people get a pause in the internet anyway? On 5/24/07, Mike Wyatt [EMAIL PROTECTED] wrote: I'm working on a synchronized RTS using pygame and Python's socket library, and I've discovered that the values returned by pygame.time.get_ticks() and the time module's clock() method are not consistent. My test results suggest that pygame.time.get_ticks() runs slightly faster than time.clock(). In other words, pygame.time.get_ticks() runs faster than real time, assuming that time.clock() is 100% accurate. The difference is pretty small, but it is enough to cause a networked game to go out of sync within a few seconds. My desktop machine (Athlon XP+ 2600, Windows XP sp2) seems more affected by this problem than my laptop (Turion 64 1.6ghz), so they are executing time steps at a slightly different rate, resulting in the stalling. Both machines are running Windows XP service pack 2 with Python 2.4 and PyGame 1.7.1. Here is some source code that will show this behavior: - import pygame, time pygame.init() pygame.display.set_mode( (100, 50) ) quit = False while not quit: for event in pygame.event.get(): if event.type == pygame.QUIT: quit = True t = int(time.clock()*1000) p = pygame.time.get_ticks() print %8s %8s (%8s) % (p, t, t-p) time.sleep(1) - Output on desktop: 11550 ( -1155) 2156 993 ( -1163) 3156 1988 ( -1168) 4160 2987 ( -1173) 5161 3983 ( -1178) 6162 4979 ( -1183) 7164 5974 ( -1190) 8164 6971 ( -1193) 9165 7971 ( -1194) 10170 8968 ( -1202) 11173 9965 ( -1208) 1217310960 ( -1213) 1317311955 ( -1218) 1417312952 ( -1221) 1517313944 ( -1229) As you can see, the difference between the pygame.time.get_ticks() and time.clock() is slowly increasing. The difference is less pronounced on my laptop, though. The values grow apart by only 1 or 2 milliseconds per second. Does anyone else see this behavior? I think a quick fix would be to use time.clock(), but I'd like to hear what other people recommend.
[pygame] pygame.time.get_ticks() vs. time.clock()
I'm working on a synchronized RTS using pygame and Python's socket library, and I've discovered that the values returned by pygame.time.get_ticks() and the time module's clock() method are not consistent. My test results suggest that pygame.time.get_ticks() runs slightly faster than time.clock(). In other words, pygame.time.get_ticks() runs faster than real time, assuming that time.clock() is 100% accurate. The difference is pretty small, but it is enough to cause a networked game to go out of sync within a few seconds. My desktop machine (Athlon XP+ 2600, Windows XP sp2) seems more affected by this problem than my laptop (Turion 64 1.6ghz), so they are executing time steps at a slightly different rate, resulting in the stalling. Both machines are running Windows XP service pack 2 with Python 2.4 and PyGame 1.7.1. Here is some source code that will show this behavior: - import pygame, time pygame.init() pygame.display.set_mode( (100, 50) ) quit = False while not quit: for event in pygame.event.get(): if event.type == pygame.QUIT: quit = True t = int(time.clock()*1000) p = pygame.time.get_ticks() print %8s %8s (%8s) % (p, t, t-p) time.sleep(1) - Output on desktop: 11550 ( -1155) 2156 993 ( -1163) 3156 1988 ( -1168) 4160 2987 ( -1173) 5161 3983 ( -1178) 6162 4979 ( -1183) 7164 5974 ( -1190) 8164 6971 ( -1193) 9165 7971 ( -1194) 10170 8968 ( -1202) 11173 9965 ( -1208) 1217310960 ( -1213) 1317311955 ( -1218) 1417312952 ( -1221) 1517313944 ( -1229) As you can see, the difference between the pygame.time.get_ticks() and time.clock() is slowly increasing. The difference is less pronounced on my laptop, though. The values grow apart by only 1 or 2 milliseconds per second. Does anyone else see this behavior? I think a quick fix would be to use time.clock(), but I'd like to hear what other people recommend.
Re: [pygame] pygame.time.get_ticks() vs. time.clock()
I took the easy path and replaced pygame.time.get_ticks() with int(time.clock()*1000). The game seems to be running much smoother now. I agree that this is not an ideal solution, so I'll make a note to look at modifying my logic to use a network-synced timer value. I actually already have a network-synced clock, but I don't want to spend time converting all my logic to using the network-synced value. Does anyone have any thoughts on my get_ticks() isn't consistent with time.clock()? I'm not sure that it is an issue with the OS clock being inaccurate. I realize that it is not perfectly accurate, but I would at least assume that both methods would return values that consistently increase over time. After roughly 20 minutes of running the posted code on my desktop, the difference between get_ticks() and time.clock() had increased by over 8000 ms. On 5/23/07, René Dudfield [EMAIL PROTECTED] wrote: I don't think you can rely on the time to be accurate - especially across machines, and different CPUs/OS's. Inaccurate to within 10ms is what XP can do. So... what to do? I think maybe use one of the machines as a master clock? Then sync to that? So you could add the master clocks time to every packet... then adjust for latency? I think you'd need something like that if people get a pause in the internet anyway? On 5/24/07, Mike Wyatt [EMAIL PROTECTED] wrote: I'm working on a synchronized RTS using pygame and Python's socket library, and I've discovered that the values returned by pygame.time.get_ticks() and the time module's clock() method are not consistent. My test results suggest that pygame.time.get_ticks() runs slightly faster than time.clock(). In other words, pygame.time.get_ticks() runs faster than real time, assuming that time.clock() is 100% accurate. The difference is pretty small, but it is enough to cause a networked game to go out of sync within a few seconds. My desktop machine (Athlon XP+ 2600, Windows XP sp2) seems more affected by this problem than my laptop (Turion 64 1.6ghz), so they are executing time steps at a slightly different rate, resulting in the stalling. Both machines are running Windows XP service pack 2 with Python 2.4 and PyGame 1.7.1. Here is some source code that will show this behavior: - import pygame, time pygame.init() pygame.display.set_mode( (100, 50) ) quit = False while not quit: for event in pygame.event.get(): if event.type == pygame.QUIT: quit = True t = int(time.clock()*1000) p = pygame.time.get_ticks() print %8s %8s (%8s) % (p, t, t-p) time.sleep(1) - Output on desktop: 11550 ( -1155) 2156 993 ( -1163) 3156 1988 ( -1168) 4160 2987 ( -1173) 5161 3983 ( -1178) 6162 4979 ( -1183) 7164 5974 ( -1190) 8164 6971 ( -1193) 9165 7971 ( -1194) 10170 8968 ( -1202) 11173 9965 ( -1208) 1217310960 ( -1213) 1317311955 ( -1218) 1417312952 ( -1221) 1517313944 ( -1229) As you can see, the difference between the pygame.time.get_ticks() and time.clock() is slowly increasing. The difference is less pronounced on my laptop, though. The values grow apart by only 1 or 2 milliseconds per second. Does anyone else see this behavior? I think a quick fix would be to use time.clock(), but I'd like to hear what other people recommend.
Re: [pygame] pygame.time.get_ticks() vs. time.clock()
Mike Wyatt wrote: the values returned by pygame.time.get_ticks() and the time module's clock() method are not consistent. The difference is pretty small, but it is enough to cause a networked game to go out of sync within a few seconds. Even if this difference didn't exist, relying on the local clocks of two machines to keep them in sync for an extended period of time seems like a bad idea in the first place. There needs to be some kind of communication to synchronise them. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | Carpe post meridiem! | Christchurch, New Zealand | (I'm not a morning person.) | [EMAIL PROTECTED] +--+
