Mercurial > jmeCapture
diff src/com/aurellem/capture/IsoTimer.java @ 54:6484a820e27d
wrote main documentation.
author | Robert McIntyre <rlm@mit.edu> |
---|---|
date | Sat, 03 Dec 2011 19:15:43 -0600 |
parents | edaa7e7806e4 |
children | afc437f637bd |
line wrap: on
line diff
1.1 --- a/src/com/aurellem/capture/IsoTimer.java Sat Dec 03 13:54:47 2011 -0600 1.2 +++ b/src/com/aurellem/capture/IsoTimer.java Sat Dec 03 19:15:43 2011 -0600 1.3 @@ -2,6 +2,38 @@ 1.4 1.5 import com.jme3.system.Timer; 1.6 1.7 +/** 1.8 + * A standard JME3 application that extends SimpleApplication or 1.9 + * Application tries as hard as it can to keep in sync with 1.10 + * user-time. If a ball is rolling at 1 game-mile per game-hour in the 1.11 + * game, and you wait for one user-hour as measured by the clock on 1.12 + * your wall, then the ball should have traveled exactly one 1.13 + * game-mile. In order to keep sync with the real world, the game 1.14 + * throttles its physics engine and graphics display. If the 1.15 + * computations involved in running the game are too intense, then the 1.16 + * game will first skip frames, then sacrifice physics accuracy. If 1.17 + * there are particularly demanding computations, then you may only get 1.18 + * 1 fps, and the ball may tunnel through the floor or obstacles due 1.19 + * to inaccurate physics simulation, but after the end of one 1.20 + * user-hour, that ball will have traveled one game-mile. 1.21 + * 1.22 + * When we're recording video or audio, we don't care if the game-time 1.23 + * syncs with user-time, but instead whether the time in the recorded 1.24 + * video (video-time) syncs with user-time. To continue the analogy, 1.25 + * if we recorded the ball rolling at 1 game-mile per game-hour and 1.26 + * watched the video later, we would want to see 30 fps video of the 1.27 + * ball rolling at 1 video-mile per user-hour. It doesn't matter how 1.28 + * much user-time it took to simulate that hour of game-time to make 1.29 + * the high-quality recording. If an Application uses this IsoTimer 1.30 + * instead of the normal one, we can be sure that every call to 1.31 + * simpleUpdate, for example, corresponds to exactly (1 / fps) seconds 1.32 + * of game-time. This let's us record perfect video and audio even on 1.33 + * a slow computer. 1.34 + * 1.35 + * @author Robert McIntyre 1.36 + * 1.37 + */ 1.38 + 1.39 public class IsoTimer extends Timer { 1.40 1.41 private float framerate; 1.42 @@ -9,19 +41,24 @@ 1.43 1.44 public IsoTimer(float framerate){ 1.45 this.framerate = framerate; 1.46 - this.ticks = 0;} 1.47 + this.ticks = 0; 1.48 + } 1.49 1.50 public long getTime() { 1.51 - return (long) (this.ticks / this.framerate);} 1.52 + return (long) (this.ticks / this.framerate); 1.53 + } 1.54 1.55 public long getResolution() { 1.56 - return 1000000000L;} 1.57 + return 1000000000L; 1.58 + } 1.59 1.60 public float getFrameRate() { 1.61 - return this.framerate;} 1.62 + return this.framerate; 1.63 + } 1.64 1.65 public float getTimePerFrame() { 1.66 - return (float) (1.0f / this.framerate);} 1.67 + return (float) (1.0f / this.framerate); 1.68 + } 1.69 1.70 public void update() {this.ticks++;} 1.71