![]() ![]() (also, of course, the other reason I forgot to list originally: RDTSC is based upon processor frequency, which changes at run time due to power management features) However, it's usually buffered for several milliseconds in advance even in games, and much of the timing there is handled by the sound hardware and drivers. Sound is a different issue of course, but one I know less about. The human eye also introduces timing limitations, but these are harder to quantify due to variations depending upon which portion of the eye you are using (peripheral vision etc), individual variation between eyes and brains, and the nature of the visual stimuli. ![]() Either issue alone is enough to render sub-millisecond timing irrelevant for synchronizing LCD output. LCDs have different issues, which I'm less familiar with the precise numbers for, but they have multiple sources of timing issues data rates for the digital cables and update rates for the LCs themselves. For instance, CRTs tend to only do a retrace every 8-20 milliseconds, rendering sub-millisecond synchronization for animations displayed on CRTs pointless. However, there's not point in synchronizing them more accurately with real time than the output devices (or the human perceiving them, assuming you're outputting to a human) can track. Timers don't make physics calculations more precise they just make physics more closely synchronized with real time. But it leads to more accurate simulation of physics and other game functions. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |