1.1 --- a/org/capture-video.org	Wed Feb 15 10:26:05 2012 -0700
     1.2 +++ b/org/capture-video.org	Wed Feb 15 10:31:51 2012 -0700
     1.3 @@ -12,8 +12,7 @@
     1.4  create a demo video to show off your hard work. Screen capturing is
     1.5  the most straightforward way to do this, but it can slow down your
     1.6  game and produce low-quality video as a result. A better way is to
     1.7 -record a video feed directly from the game while it is
     1.8 -running.
     1.9 +record a video feed directly from the game while it is running.
    1.10  
    1.11  In this post, I'll explain how you can alter your JMonkeyEngine3 game
    1.12  to output video while it is running. The main trick is to alter the
    1.13 @@ -28,62 +27,62 @@
    1.14  ** The built-in =Timer= rushes to keep up.
    1.15  #* Game-time vs. User-time vs. Video-time
    1.16  
    1.17 -Standard JME3 applications use a =Timer= object to manage time
    1.18 -in the simulated world. Because most JME3 applications (e.g. games)
    1.19 -are supposed to happen \ldquo{}live\rdquo{}, the built-in =Timer=
    1.20 -requires simulated time to match real time. This means that the
    1.21 -application must rush to finish all of its calculations on
    1.22 -schedule: the more complicated the calculations, the more the
    1.23 -application is obligated to rush. And if the workload becomes too
    1.24 -much to handle on schedule, =Timer= forces the application to cut
    1.25 -corners: it demands fast, approximate answers instead of careful,
    1.26 -accurate ones.  Although this policy sometimes causes physically impossible
    1.27 -glitches and choppy framerates, it ensures that the user will never be
    1.28 -kept waiting while the computer stops to make a complicated
    1.29 -calculation.
    1.30 +Standard JME3 applications use a =Timer= object to manage time in the
    1.31 +simulated world. Because most JME3 applications (e.g. games) are
    1.32 +supposed to happen \ldquo{}live\rdquo{}, the built-in =Timer= requires
    1.33 +simulated time to match real time. This means that the application
    1.34 +must rush to finish all of its calculations on schedule: the more
    1.35 +complicated the calculations, the more the application is obligated to
    1.36 +rush. And if the workload becomes too much to handle on schedule,
    1.37 +=Timer= forces the application to cut corners: it demands fast,
    1.38 +approximate answers instead of careful, accurate ones.  Although this
    1.39 +policy sometimes causes physically impossible glitches and choppy
    1.40 +framerates, it ensures that the user will never be kept waiting while
    1.41 +the computer stops to make a complicated calculation.
    1.42  
    1.43  Now, the built-in =Timer= values speed over accuracy because real-time
    1.44 -applications require it. On the other hand, if your goal is to record a
    1.45 -glitch-free video, you need a =Timer= that will take its time to
    1.46 -ensure that all calculations are accurate, even if they take a long time. In the next section, we
    1.47 -will create a new kind of =Timer=\mdash{}called =IsoTimer=\mdash{}which
    1.48 -slows down to let the computer finish all its calculations. The result
    1.49 -is a perfectly steady framerate and a flawless physical simulation.
    1.50 +applications require it. On the other hand, if your goal is to record
    1.51 +a glitch-free video, you need a =Timer= that will take its time to
    1.52 +ensure that all calculations are accurate, even if they take a long
    1.53 +time. In the next section, we will create a new kind of
    1.54 +=Timer=\mdash{}called =IsoTimer=\mdash{}which slows down to let the
    1.55 +computer finish all its calculations. The result is a perfectly steady
    1.56 +framerate and a flawless physical simulation.
    1.57  
    1.58  # are supposed to happen \ldquo live \rdquo, this =Timer= requires the
    1.59 -# application to update in real-time. In order to keep up with the real world, JME applications cannot
    1.60 -# afford to take too much time on expensive computations. Whenever the
    1.61 -# workload becomes too much for the computer to handle on schedule,
    1.62 -# =Timer= forces the computer to cut corners, giving fast, approximate
    1.63 -# answers instead of careful, accurate ones. Although physical accuracy sometimes
    1.64 -# suffers as a result, this policy ensures that the user will never be
    1.65 -# kept waiting while the computer stops to make a complicated
    1.66 -# calculation.
    1.67 +# application to update in real-time. In order to keep up with the
    1.68 +# real world, JME applications cannot afford to take too much time on
    1.69 +# expensive computations. Whenever the workload becomes too much for
    1.70 +# the computer to handle on schedule, =Timer= forces the computer to
    1.71 +# cut corners, giving fast, approximate answers instead of careful,
    1.72 +# accurate ones. Although physical accuracy sometimes suffers as a
    1.73 +# result, this policy ensures that the user will never be kept waiting
    1.74 +# while the computer stops to make a complicated calculation.
    1.75  
    1.76  #fast answers are more important than accurate ones. 
    1.77  
    1.78  # A standard JME3 application that extends =SimpleApplication= or
    1.79  # =Application= tries as hard as it can to keep in sync with
    1.80 -# /user-time/.  If a ball is rolling at 1 game-mile per game-hour in the
    1.81 -# game, and you wait for one user-hour as measured by the clock on your
    1.82 -# wall, then the ball should have traveled exactly one game-mile. In
    1.83 -# order to keep sync with the real world, the game throttles its physics
    1.84 -# engine and graphics display.  If the computations involved in running
    1.85 -# the game are too intense, then the game will first skip frames, then
    1.86 -# sacrifice physics accuracy.  If there are particuraly demanding
    1.87 -# computations, then you may only get 1 fps, and the ball may tunnel
    1.88 -# through the floor or obstacles due to inaccurate physics simulation,
    1.89 -# but after the end of one user-hour, that ball will have traveled one
    1.90 -# game-mile.
    1.91 +# /user-time/.  If a ball is rolling at 1 game-mile per game-hour in
    1.92 +# the game, and you wait for one user-hour as measured by the clock on
    1.93 +# your wall, then the ball should have traveled exactly one
    1.94 +# game-mile. In order to keep sync with the real world, the game
    1.95 +# throttles its physics engine and graphics display.  If the
    1.96 +# computations involved in running the game are too intense, then the
    1.97 +# game will first skip frames, then sacrifice physics accuracy.  If
    1.98 +# there are particuraly demanding computations, then you may only get
    1.99 +# 1 fps, and the ball may tunnel through the floor or obstacles due to
   1.100 +# inaccurate physics simulation, but after the end of one user-hour,
   1.101 +# that ball will have traveled one game-mile.
   1.102  
   1.103 -# When we're recording video, we don't care if the game-time syncs with
   1.104 -# user-time, but instead whether the time in the recorded video
   1.105 +# When we're recording video, we don't care if the game-time syncs
   1.106 +# with user-time, but instead whether the time in the recorded video
   1.107  # (video-time) syncs with user-time. To continue the analogy, if we
   1.108 -# recorded the ball rolling at 1 game-mile per game-hour and watched the
   1.109 -# video later, we would want to see 30 fps video of the ball rolling at
   1.110 -# 1 video-mile per /user-hour/. It doesn't matter how much user-time it
   1.111 -# took to simulate that hour of game-time to make the high-quality
   1.112 -# recording.
   1.113 +# recorded the ball rolling at 1 game-mile per game-hour and watched
   1.114 +# the video later, we would want to see 30 fps video of the ball
   1.115 +# rolling at 1 video-mile per /user-hour/. It doesn't matter how much
   1.116 +# user-time it took to simulate that hour of game-time to make the
   1.117 +# high-quality recording.
   1.118  ** COMMENT Two examples to clarify the point:
   1.119  *** Recording from a Simple Simulation
   1.120  
   1.121 @@ -151,10 +150,10 @@
   1.122  the screen, and an additional $\frac{1}{60}$ to encode the video and
   1.123  write the frame to disk. This is a total of $\frac{1}{24}$
   1.124  user-seconds for each $\frac{1}{60}$ game-seconds. It will take
   1.125 -$(\frac{60}{24} = 2.5)$ user-hours to record one game-hour and game-time
   1.126 -will appear to flow two-fifths as fast as user time while the game is
   1.127 -running. However, just as in example one, when all is said and done we
   1.128 -will have an hour long video at 60 fps.
   1.129 +$(\frac{60}{24} = 2.5)$ user-hours to record one game-hour and
   1.130 +game-time will appear to flow two-fifths as fast as user time while
   1.131 +the game is running. However, just as in example one, when all is said
   1.132 +and done we will have an hour long video at 60 fps.
   1.133  
   1.134  
   1.135  ** COMMENT proposed names for the new timer
   1.136 @@ -182,8 +181,8 @@
   1.137  #+include ../../jmeCapture/src/com/aurellem/capture/IsoTimer.java src java
   1.138  
   1.139  If an Application uses this =IsoTimer= instead of the normal one, we
   1.140 -can be sure that every call to =simpleUpdate=, for example, corresponds
   1.141 -to exactly $(\frac{1}{fps})$ seconds of game-time.
   1.142 +can be sure that every call to =simpleUpdate=, for example,
   1.143 +corresponds to exactly $(\frac{1}{fps})$ seconds of game-time.
   1.144  
   1.145  * =VideoRecorder= manages video feeds in JMonkeyEngine.
   1.146  
   1.147 @@ -240,8 +239,9 @@
   1.148  
   1.149  With this, we are able to record video!
   1.150  
   1.151 -However, it can be hard to properly install Xuggle. If you would rather not use Xuggle, here is an alternate class that uses
   1.152 -[[http://www.randelshofer.ch/blog/2008/08/writing-avi-videos-in-pure-java/][Werner Randelshofer's]] excellent pure Java AVI file writer.
   1.153 +However, it can be hard to properly install Xuggle. If you would
   1.154 +rather not use Xuggle, here is an alternate class that uses [[http://www.randelshofer.ch/blog/2008/08/writing-avi-videos-in-pure-java/][Werner
   1.155 +Randelshofer's]] excellent pure Java AVI file writer.
   1.156  
   1.157  =./src/com/aurellem/capture/video/AVIVideoRecorder.java=
   1.158  #+include ../../jmeCapture/src/com/aurellem/capture/video/AVIVideoRecorder.java src java
   1.159 @@ -265,13 +265,14 @@
   1.160  
   1.161  ** Include this code.
   1.162  
   1.163 -  No matter how complicated your application is, it's easy to add
   1.164 -  support for video output with just a few lines of code.
   1.165 +No matter how complicated your application is, it's easy to add
   1.166 +support for video output with just a few lines of code.
   1.167  #  You can also record from multiple ViewPorts as the above example shows.
   1.168  
   1.169 -And although you can use =VideoRecorder= to record advanced split-screen videos with multiple views, in the simplest case, you want to capture a single view\mdash{}
   1.170 -exactly what's on screen. In this case, the following simple =captureVideo=
   1.171 -method will do the job:
   1.172 +And although you can use =VideoRecorder= to record advanced
   1.173 +split-screen videos with multiple views, in the simplest case, you
   1.174 +want to capture a single view\mdash{} exactly what's on screen. In
   1.175 +this case, the following simple =captureVideo= method will do the job:
   1.176  
   1.177  #+begin_src java
   1.178  public static void captureVideo(final Application app, 
   1.179 @@ -302,12 +303,9 @@
   1.180  }
   1.181  #+end_src
   1.182  
   1.183 -This method selects the appropriate =VideoRecorder= class
   1.184 -for the file type you specify, and instructs your
   1.185 -application to record video to the file.
   1.186 -
   1.187 -
   1.188 -
   1.189 +This method selects the appropriate =VideoRecorder= class for the file
   1.190 +type you specify, and instructs your application to record video to
   1.191 +the file.
   1.192  
   1.193  Now that you have a =captureVideo= method, you use it like this:
   1.194  
   1.195 @@ -321,7 +319,8 @@
   1.196  
   1.197    - Choose the output file :: If you want to record from the game's
   1.198         main =ViewPort= to a file called =/home/r/record.flv=, then
   1.199 -       include the following line of code somewhere before you call =app.start()=;
   1.200 +       include the following line of code somewhere before you call
   1.201 +       =app.start()=;
   1.202  
   1.203    #+begin_src java :exports code
   1.204  Capture.captureVideo(app, new File("/home/r/record.flv"));
   1.205 @@ -384,8 +383,9 @@
   1.206    
   1.207  * COMMENT More Examples
   1.208  ** COMMENT Hello Physics
   1.209 -=HelloVideo= is boring. Let's add some video capturing to =HelloPhysics=
   1.210 -and create something fun!
   1.211 +
   1.212 +=HelloVideo= is boring. Let's add some video capturing to
   1.213 +=HelloPhysics= and create something fun!
   1.214  
   1.215  This example is a modified version of =HelloPhysics= that creates four
   1.216  simultaneous views of the same scene of cannonballs careening into a
   1.217 @@ -579,7 +579,7 @@
   1.218  four points of view are simultaneously recorded and then glued
   1.219  together later.
   1.220  
   1.221 - JME3 Xuggle Aurellem video capture
   1.222 +JME3 Xuggle Aurellem video capture
   1.223   
   1.224   
   1.225  * Showcase of recorded videos