Game and Graphics Programming for iOS and Android with OpenGL ES 2.0

Chapter 2

Setting Up Your Graphic Projections

WHAT’S IN THIS CHAPTER?

• Understanding how the different types of projection matrices work, how to use them, and when
• Getting familiar with the template application that comes with the SDK and learning how to customize it for your specific needs
• Building your first practical application — learning how to set it up and use the different types of projections

Before you can draw any graphics onscreen, you first need to create a projection matrix. The type of graphics you plan to use will have a direct impact on the creation of this matrix. Whether it is 2D, 2.5D, or 3D, each type of projection matrix will require a different initialization, allowing you to create the necessary perspective for your specific needs.

In this chapter, you will learn about the three primary types of projections used in modern mobile games and how to use them.

In addition, this chapter will teach you how to work with this book’s template project and walk you through three progressive exercises. In these exercises, you will learn how to manipulate the most common types of graphic projections and draw simple geometry onscreen; handle vertex and fragment shaders and link them to a shader program; manipulate vertex attributes and uniform variables; translate, rotate, and scale basic geometry; and create a simple camera look-at matrix.

THE THREE BASIC TYPES OF PROJECTIONS

When drawing using OpenGL ES, you always have to keep in mind the sequence of your drawings and in which perspective space you want to draw. Needless to say, this sequence will directly affect the type of projection and the sequence of creation of your projection’s matrix.

For example, if you want to draw a heads-up display (HUD) that contains your character data on top of your scene, you first need to set up a 2D, 2.5D, or 3D perspective (depending on the type of game you are working on), and then draw your game scene. After your scene is rendered in the color buffer, you need to render your character life bar, ammo, etc. on top of it. Simply scaling your HUD graphics onscreen to fit the current drawing perspective would deteriorate their overall aspect ratio, eventually making them distorted. Knowing this, the right way to draw the HUD of your game would be to create a projection matrix that has a ratio of 1 unit to 1 pixel. Since your HUD consists of multiple 2D graphics, and it is important to respect their ratio onscreen, a 1:1 2D projection will allow you to draw them consistently onscreen.

There are three distinct types of projections that can be used in any game genre:

• Orthographic 2D Projection: This type of projection is used to draw any HUD, as in the example described previously. This type of projection was also used in the “old school” side-scroller genre and other types of games, such as the classic Tetris and older grid-based role-playing games. As mentioned, this type of projection will have a 1:1 ratio onscreen, which means that the size of your drawing is directly affected by the size in pixels of the squares (quads) that you are sending to the GPU (graphical processing unit). In a more modern usage, this types of projection is mostly used only to draw menus, text, HUD, or other types of static (or semi-dynamic) 2D information onscreen. Since a third level of dimension is not available, and because the depth range is limited from −1 to 1 (with −1 being the nearest point onscreen and 1 the farthest), the use of the depth buffer is basically obsolete and should be turned off. In addition, the rendering sequence should be done from back to front to avoid overwriting pixels.
• Orthographic (Ortho) Projection: This type of projection allows you to draw in a semi-2D environment while still considering a third level of dimension, where the perspective is strictly based on the current screen ratio. This type of projection is the one used by every modern 2D/2.5D shoot ’em up-type game and real-time strategy games. When using this type of projection, you can still have access to a third level of dimension and make full use of the depth buffer. Figure 2-1 shows an example of a game that uses a 2D orthographic projection in conjunction with the depth buffer.

  FIGURE 2-1: Ragdoll Launcher by SIO2 Interactive

• Perspective Projection: This type of projection matrix is the one that you see at work inside all fancy 3D games that render in real-time dynamic and realistic 3D worlds onscreen. With this kind of projection, you can simulate what a 3D world would look like from a real human-eye perspective. In addition to the screen aspect ratio, this sort of projection takes into consideration the field of view of the camera looking at the scene, as in the futuristic car game for iOS shown in Figure 2-2.

  FIGURE 2-2: Sky Racer by SIO2 Interactive

ORTHOGRAPHIC 2D PROJECTION

Now it’s time to get your hands dirty and start looking at the necessary code to set up a 2D orthographic projection matrix.

In this section, you will create from scratch a simple program using the template project from this book’s SDK. Your first app will use a screen projection to draw a scaled colored quad onscreen in absolute pixel coordinates.

Before diving into the code, first duplicate the template project directory located at the root of the SDK. In order to do this, simply right-click on it and create a local copy of the folder, and then rename it chapter2-1. Once the project is loaded into your favorite IDE, locate the templateApp.cpp source file and open it in the code editor.

The first step for you to get started with the tutorials of this chapter is to adjust your newly created template project by removing the callback functions that you will not need for the exercises in this chapter.

You will concentrate your efforts on the templateAppInit and the templateAppDraw function callbacks, so you can remove the rest of the callbacks and code comments and have a clean template to start working on. Modify the code so you get the following result:

Program and Project Initialization

The following steps will guide you through the necessary procedure in order to set up global variables used by your first program. In addition, you will learn about the different types of structures provided in this book’s SDK that will help you manipulate different aspects of your programs, such as shaders and loading assets from disk. You will also learn how to create your first 2D screen projection matrix, using the API provided in the SDK.

1. At the top of the templateApp.cpp source file (on the line just before the templateAppInit function declaration), define your vertex and fragment shader filenames as follows:

2. Declare a flag to toggle ON (1) or OFF (0) the shader debugging functionalities. No debugging usually means faster shader compilation, but no errors will be reported, and the result is undefined if an error does occur. Therefore, you should keep this flag toggle ON while you are developing your program.

3. Create an empty PROGRAM structure for managing all your shader programs, as follows:

The PROGRAM structure is the one that you are going to use throughout this book to handle shader programs. The full source code of the implementation is available inside the SDK/common/program.cpp and program.h source files. The code of the SHADER structures linked to the PROGRAM can be found inside the shader.cpp and shader.h source files, which are also located inside the SDK/common directory of the book’s source code package. Basically, this pre-made structure handles all interactions between the vertex and fragment shaders and the main shader program. This allows you to compile your shaders and link them to a shader program automatically. In addition, this structure provides you with an easy-to-use way to gain access to uniform variable(s) and vertex attributes that are automatically assigned by the GPU. It also provides an easy-to-use callback mechanism that allows you to access, set, and modify these uniform variables in real time.

4. Declare a MEMORY structure pointer as follows:

This object is also part of the SDK and basically behaves like FILE in C, with the exception that all the work is done in memory. On mobile devices, the system memory is the fastest way to deal with data. In this exercise, you are going to use this structure to read your shader files from disk. As a general rule, you should avoid disk access if possible. By using this structure instead, you will get a better loading speed and more flexibility when...