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