Game Development Reference
In-Depth Information
There are basically two ways in which the render() method works. In the first
case, it will simply call the render() method of the currently set screen. This
holds true as long as no next screen is set, which implicates no ongoing transition
effect. Otherwise, it is assumed that there is an ongoing transition. In this case, t is
increased by the current delta time to let the transition effect progress correctly in
time. After this, the current and the next screens are rendered to their designated
FBOs. Then, the resulting two textures are eventually passed on to the transition
effect's render() method to do something fancy with it. Finally, the screens are
switched and the input processor is reactivated as soon as the value of t has reached
the transition effect's duration. Also, nextScreen is set back to null so that the first
way of rendering is used again.
The delta time in the render() method of our new DirectedGame class
is constrained to a maximum value of one-sixth of a second to ensure
semifixed time steps in all our screens. We will use this from now on to
avoid potential time-related problems that may arise from using variable
time steps, which we used before.
For a thorough explanation about various time stepping strategies,
check out the following article on Glen Fiedler's blog http://
gafferongames.com/game-physics/fix-your-timestep/ .
After this, add the following code to the same class to implement the remaining parts
of the ApplicationListener interface:
@Override
public void resize (int width, int height) {
if (currScreen != null) currScreen.resize(width, height);
if (nextScreen != null) nextScreen.resize(width, height);
}
@Override
public void pause () {
if (currScreen != null) currScreen.pause();
}
@Override
public void resume () {
if (currScreen != null) currScreen.resume();
}
@Override
public void dispose () {
 
Search WWH ::




Custom Search