GLART week 9: Timing

Assigment: Reading: Motion Examples: GLART_9_timing.java -- control animation speed Requires font_tahoma.png and GLImage.java Resources: NeHe: Introduction To Physical Simulations -- tutorial on building a physics simulation NOTES: ================================================================= Since cpu performance varies, program execution speed can vary from one computer to another. If you move an animation a fixed amount in each render() the animation will move at different rates on different computers, as render() is called more often on the faster cpu. VSync also affects the framerate. Display.setVSyncEnabled(true) will synchronize OpenGL frame updates with the monitor refresh rate. Most monitors refresh the screen 60 or 75 per second, and VSync will force Display.update() to wait till the monitor is ready to draw. This controls the refresh rate somewhat, but monitors can have different refresh rates, and slower graphics cards will slow this down the refresh rate. To insure that animations run at the same rate across various computers, you need to move animations according to actual time elapsed, not frame renders. Check how much time has elapsed since the last frame rendered, then "step" the simulation forward by that amount of time. The simulation advances in proportion to the time elapsed, and keeps track of how much time has elapsed within the simulatulation. Java's time function, System.currentTimeMillis(), does not measure time accurately below 10 milliseconds, and will not give accurate results when measuring time elapsed between frames. Functions: Sys.getTime() LWJGL's hardware timer returns the time in cpu 'ticks' very accurate for small durations Sys.getTimerResolution() LWJGL function to get ticks per second varies on different computers NOTE: Java's time function, System.currentTimeMillis() is not accurate for small durations Use double data type for highest accuracy when measuring ticks and small time durations.