Game Development Reference
In-Depth Information
public void setScreen(Screen newScreen) {
if (screen == null )
throw new IllegalArgumentException("Screen must not be null");
this .screen.pause();
this .screen.dispose();
newScreen.resume();
newScreen.update(0);
this .screen = newScreen;
}
public Screen getCurrentScreen() {
return screen;
}
}
The rest of the class works as before. In case we accidentally try to access the standard
Graphics instance, we throw an exception, as it is not supported by GLGame . Instead, we'll work
with the GLGraphics method we get via the GLGame.getGLGraphics() method.
Why did we go through all the pain of synchronizing with the rendering thread? Well, it will make
our Screen implementations live entirely on the rendering thread. All the methods of Screen
will be executed there, which is necessary if we want to access OpenGL ES functionality.
Remember, we can only access OpenGL ES on the rendering thread.
Let's round this out with an example. Listing 7-4 shows how our first example in this chapter
looks when using GLGame and Screen .
Listing 7-4. GLGameTest.java; More Screen Clearing, Now with 100 Percent More GLGame
package com.badlogic.androidgames.glbasics;
import java.util.Random;
import javax.microedition.khronos.opengles.GL10;
import com.badlogic.androidgames.framework.Game;
import com.badlogic.androidgames.framework.Screen;
import com.badlogic.androidgames.framework.impl.GLGame;
import com.badlogic.androidgames.framework.impl.GLGraphics;
public class GLGameTest extends GLGame {
public Screen getStartScreen() {
return new TestScreen( this );
}
class TestScreen extends Screen {
GLGraphics glGraphics;
Random rand = new Random();
Search WWH ::




Custom Search