How OpenGL ES Works with Android

Open GL ES communicates with the graphic hardware in a much more direct manner than a core Android call. This means that you are sending data directly to the hardware that is responsible for processing it. A core Android call would have to go through the core Android processes, threads, and interpreter before getting to the graphics hardware. Games written for the Android platform can only achieve an acceptable level of speed and playability by communicating directly with the GPU (Graphics Processing Unit).

Current versions of Android have the ability to use either OpenGL ES 1 or OpenGL ES 2 / 3 calls. There is a big difference between the two versions, and which one you use will play a role in determining who can run your game, and who will not be able to.

OpenGL ES facilitates this interaction between your game and the graphics hardware in one of two different ways. The type of GPU employed in the Android device running your game will determine which version of OpenGL ES you use, thus how OpenGL will interact with the hardware. There are two major kinds of graphics hardware in the market, and because they are very different, two different versions of OpenGL ES are required to interact with them.

The two different types of hardware are those with a fixed-function pipeline, and those with shaders. The next few sections quickly review OpenGL ES and fixed-function pipelines, and OpenGL ES and shaders.  Keep in mind, OpenGL ES version 1 runs on fixed-function piplelines, while OpenGL ES 2 / 3 runs on shaders.

private float myVertices[] = {
0.0f, 0.0f, 0.0f,
   1.0f, 0.0f, 0.0f,
   1.0f, 1.0f, 0.0f,
   0.0f, 1.0f, 0.0f,
};

//Other OpenGL and game stuff//

gl.glMatrixMode(GL10.GL_MODELVIEW)
gl.glLoadIdentity();
gl.glTranslatef(0f, 1f, 0f);

private final String vertexShaderCode =
        "uniform mat4 uMVPMatrix;" +
        "attribute vec4 vPosition;" +
        "attribute vec2 TexCoordIn;" +
        "varying vec2 TexCoordOut;" +
        "void main() {" +
        "  gl_Position = uMVPMatrix * vPosition;" +
        "  TexCoordOut = TexCoordIn;" +
        "}";

    private final String fragmentShaderCode =
        "precision mediump float;" +
        "uniform vec4 vColor;" +
        "uniform sampler2D TexCoordIn;" +
        "varying vec2 TexCoordOut;" +
        "void main() {" +
        "  gl_FragColor = texture2D(TexCoordIn, TexCoordOut);" +
        "}";

A Basic Game Loop

At the core of every video game is the game engine, and part of that game engine is the game loop. As the name suggests, the game engine is the code that powers the game. Every game, regardless of the type of game—whether it is an RPG, a first-person shooter, a platformer, or even an RTS—requires a fully featured game engine to run.

The game engine typically runs on its own thread, giving it as many resources as possible. All of the tasks that a game needs to run, from graphics to sound, are taken care of in the game engine.

One very popular multipurpose game engine is the Unreal engine. The Unreal engine, first developed around 1998 by Epic for its first-person shooter, Unreal, has been used in hundreds of games. The Unreal engine is easily adaptable and works with a variety of game types, not just first-person shooters. This generic structure and flexibility make the Unreal engine popular with not only professions but casual developers as well.

Chances are, in your game development, you might have used a third-party game engine. There are many free and fee-based ones available for Android. This book will be of far greater help to you, though, if you are looking to build your own game engine.

Many of the processes in third-party game engines become obfuscated, and you might not have access to the debugging capability or you might not be able to modify the code within the engine. When you have a problem, you will generally have to turn to the company that developed the engine, and it could take time for the original developer to fix it—if they even fix it at all. This can be a major drawback if you are thinking about using a third-party game engine.

There is no substitute for the experience of building your own game engine. This book assumes that you are doing just that. Many of the problems that will be tackled in the rest of this book assume you are attempting to write a game engine on Android and are running into some common problems.

So what exactly does the game engine do? The game engine handles all of the grunt work of the game execution, anything from playing the sound effects and background music to rendering graphics onto the screen. The following is a partial list of the functions that a typical game engine will perform.

• Graphics rendering
• Animation
• Sound
• Collision detection
• Artificial intelligence (AI)
• Physics (non-collision)
• Threading and memory management
• Networking
• Command interpreter (IO)

At the core of the game engine is the game loop. While the engine can handle anything from setting up one-time vertices buffers and retrieving images, the game loop serves up the actual code execution of the game.

All games are executed in a code loop. The faster this loop can execute, the better the game will run, the quicker it will react to the player, and the smoother the action will appear on the screen. All of the code necessary to build drawing on the screen, move the game objects, tally the score, detect the collisions, and validate or invalidate items is executed within the game loop.

A game loop is exactly that, a group of code that is executed on a continuous loop. The loop is started when the game begins, and does not stop executing—with some exceptions—until the game is stopped. Let’s take a look at all of the things a game loop can be expected to do on every one of its iterations. A typical game loop can do the following:

• Interpret the commands of an input device
• Track the characters and/or the background to make sure none move where they should not be able to move to
• Test for collisions between objects
• Move the background as needed
• Draw a background
• Draw any number of stationary items
• Calculate the physics of any mobile objects
• Move any weapons/bullets/items that have been repositioned
• Draw weapons/bullets/items
• Move the characters independently
• Draw the characters
• Play sound effects
• Spin off threads for continuous background music
• Track the player’s score
• Track and manage networked or multiple players

This is not be a comprehensive list, but it is a fairly good list of all of the things expected to be done within the game loop.

It is very important to refine and optimize all of your game code. The more optimized you can make your code in the game loop, the faster it will execute all of the calls it needs to make, thus giving you the best possible gaming experience. In the next section, we will take a look at how Android, as a platform, handles game engines and game loops.

Android and Game Engines

Android is packaged with a powerful, fully featured graphics API called OpenGL ES. But is OpenGL ES absolutely necessary for game development? Rather than go through the trouble of learning a fairly low-level API, such as OpenGL ES, can you just write a game with core Android API calls?

The short answer is that for a game to run efficiently, it cannot rely on the core Android API calls to do this kind of heavy duty work. Yes, most Android does have core calls that could take care of every item on this list. However, the rendering, sound, and memory systems of Android are built for generic tasks and adapt to any number of unpredictable uses, without specializing in any one. Unpredictability means one thing: overhead. The core Android API calls that could take care of the jobs needed to run a game come with a lot of extraneous code. This is acceptable if you are writing business applications, but not if you are writing games. Overhead adds slowness to your code, and games require something with a little more power.

For a game to run smoothly and quickly, the code will need to bypass the overhead that is inherent in core Android API calls; that is, a game should communicate directly with the graphics hardware to perform graphics function, communicate directly with the sound card to play sound effects, and so on. If you were to use the standard memory, graphics, and sound systems that are available to you through core Android API, your game could be threaded with all of the other Android applications that are running on the system. This would make for a choppy looking game that would run very slowly.

For this reason, game engines and game loops are almost always coded in low-level languages or specific API, such as OpenGL ES. As we will touch on in Chapter 2, low-level languages offer a more direct path to the hardware of the system. A game engine needs to be able to take code and commands from the engine and pass them directly to the hardware. This allows the game to run quickly and with all of the control that it needs to be able to provide a rewarding experience.