[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] raw_input() and pygame.event.get()
Mike Wyatt wrote: Pete Shinners wrote: On Sun, 2006-12-10 at 22:12 -0600, Mike Wyatt wrote: Oops, I forgot to mention that. I'm using raw_input() because I want to focus on getting my game working before putting time into writing a GUI. Without a GUI, the only way I can get user input is with raw_input(). I'm working on my networking code, so I need to have each game instance ask the user (i.e. myself) to host a new game or join an existing game. Use the pygame event filtering to block certain event types. Turn this off and on around your input_raw call. http://pygame.org/docs/ref/event.html#pygame.event.set_blocked pygame.event.set_blocked(pygame.KEYDOWN | pygame.KEYUP) value = raw_input() pygame.event.set_blocked(None) That code doesn't block the events. They still appear in the next call to pygame.event.get(). Here is a script you can run to verify this: * import pygame pygame.init() displaySurface = pygame.display.set_mode( (400, 300), 0 ) while True: for event in pygame.event.get(): print event if event.type == pygame.KEYDOWN and event.key == pygame.K_s: pygame.event.set_blocked(pygame.KEYDOWN | pygame.KEYUP) value = raw_input(Type some stuff (include the 's' character): ) pygame.event.set_blocked(None) print You typed, value pygame.display.flip() * pygame.display.flip() didn't have the appropriate indentation. It should be corrected now (above). Has anyone run this and confirmed my problem?
