rlm@4
|
1 package com.aurellem.capture;
|
rlm@4
|
2
|
rlm@4
|
3 import com.jme3.system.Timer;
|
rlm@4
|
4
|
rlm@54
|
5 /**
|
rlm@54
|
6 * A standard JME3 application that extends SimpleApplication or
|
rlm@54
|
7 * Application tries as hard as it can to keep in sync with
|
rlm@54
|
8 * user-time. If a ball is rolling at 1 game-mile per game-hour in the
|
rlm@54
|
9 * game, and you wait for one user-hour as measured by the clock on
|
rlm@54
|
10 * your wall, then the ball should have traveled exactly one
|
rlm@54
|
11 * game-mile. In order to keep sync with the real world, the game
|
rlm@54
|
12 * throttles its physics engine and graphics display. If the
|
rlm@54
|
13 * computations involved in running the game are too intense, then the
|
rlm@54
|
14 * game will first skip frames, then sacrifice physics accuracy. If
|
rlm@56
|
15 * there are particularly demanding computations, then you may only
|
rlm@56
|
16 * get 1 fps, and the ball may tunnel through the floor or obstacles
|
rlm@56
|
17 * due to inaccurate physics simulation, but after the end of one
|
rlm@54
|
18 * user-hour, that ball will have traveled one game-mile.
|
rlm@54
|
19 *
|
rlm@54
|
20 * When we're recording video or audio, we don't care if the game-time
|
rlm@54
|
21 * syncs with user-time, but instead whether the time in the recorded
|
rlm@54
|
22 * video (video-time) syncs with user-time. To continue the analogy,
|
rlm@54
|
23 * if we recorded the ball rolling at 1 game-mile per game-hour and
|
rlm@54
|
24 * watched the video later, we would want to see 30 fps video of the
|
rlm@54
|
25 * ball rolling at 1 video-mile per user-hour. It doesn't matter how
|
rlm@54
|
26 * much user-time it took to simulate that hour of game-time to make
|
rlm@54
|
27 * the high-quality recording. If an Application uses this IsoTimer
|
rlm@54
|
28 * instead of the normal one, we can be sure that every call to
|
rlm@54
|
29 * simpleUpdate, for example, corresponds to exactly (1 / fps) seconds
|
rlm@59
|
30 * of game-time. This lets us record perfect video and audio even on
|
rlm@54
|
31 * a slow computer.
|
rlm@54
|
32 *
|
rlm@54
|
33 * @author Robert McIntyre
|
rlm@54
|
34 *
|
rlm@54
|
35 */
|
rlm@54
|
36
|
rlm@4
|
37 public class IsoTimer extends Timer {
|
rlm@4
|
38
|
rlm@62
|
39 private long framerate;
|
rlm@62
|
40 private int ticks;
|
rlm@4
|
41
|
rlm@62
|
42 public IsoTimer(float framerate){
|
rlm@62
|
43 this.framerate = (long) framerate;
|
rlm@62
|
44 this.ticks = 0;
|
rlm@62
|
45 }
|
rlm@62
|
46
|
rlm@62
|
47 public long getTime() {
|
rlm@62
|
48 return this.ticks;
|
rlm@62
|
49 }
|
rlm@62
|
50
|
rlm@62
|
51 public long getResolution() {
|
rlm@69
|
52 return framerate;
|
rlm@62
|
53 }
|
rlm@62
|
54
|
rlm@62
|
55 public float getFrameRate() {
|
rlm@69
|
56 return framerate;
|
rlm@62
|
57 }
|
rlm@62
|
58
|
rlm@62
|
59 public float getTimePerFrame() {
|
rlm@69
|
60 return (float) (1.0f / framerate);
|
rlm@62
|
61 }
|
rlm@62
|
62
|
rlm@62
|
63 public void update() {this.ticks++;}
|
rlm@62
|
64
|
rlm@62
|
65 public void reset() {this.ticks = 0;}
|
rlm@4
|
66
|
rlm@4
|
67 }
|