So far my adventures have been going well, no fatalities to report. As I continue forward, the more and more I want to keep going, this stuff is truly fascinating. Once I can get to the point of making pointless RPG games for my Nexus 7, I will be in a good spot, haha.
So lets being. This is what I have covered thus far; I will try to expand on my own notes a bit, so you can better follow along. Any questions, please leave a comment below, and I will try to answer as best as I can. Remember, I am just learning. :P
What is OpenGL?
When looking at graphics programming with Android, the standard Canvas API can only do so much. It is a very simply solution to very, very simple graphics based applications. With that, we can look toward OpenGL for the ability to not be limited in the 2D realm, and enter the world of 3D, with a lot of power at our disposal.
OpenGL ES is an industry standard for 3D graphics programming, that is mantained by the Khronos Group, a conglomerate made up of ATI, NVIDIA, and Intel. Together, they define and extend the industry standard for OpenGL, and other vital aspects of technology, all in a rather successful attempt of connecting software to silicone.
When it comes to using OpenGL ES with Android, we must take a special note when it comes to what version of OpenGL ES we want to use:
- OpenGL ES 1.0: Supported by all Android devices, old and new
- OpenGL ES 1.1: Supported by most newer Android devices
- OpenGL ES 2.0: Only supported by Android 2.3 and higher
Now why is this? Well, OpenGL ES 1.X follows a fixed-function pipeline, where all functions used are pre-defined and more or less, cannot be directly altered. This is perfectly fine for the majority of games that one may develop. OpenGL ES 2.0 adds shaders, which is a standard part of standard OpenGL. This allows for programmatically defined parts of the rendering pipeline. Since OpenGL 1.X is most supported, and is perfectly fine for our purposes, it will be used.
Understanding OpenGL ES - An Analogy
The best way to explain the OpenGL ES programming model is with the whole camera analogy. You can think of OpenGL ES as working like that of a camera. When you are going to snap a picture, you have to go to the scene you wish to photograph. This scene is made up of objects, all of which maintain some sort of position and orientation relative to your camera. Though some of these object maybe moving, when you press the shutter release, you catch a still image of the scene, and thus, you get a still image of all of the objects, with their relative position, orientation, etc, at that exact moment.
This whole idea is a very abstract, high level look into how OpenGL ES is modled. To better understand how this applies, we need to define some things:
- Objects (or models) - Made up of geometry, color, texture, and material. Geometry is defined by a set of triangles, each of which has a position in 3D space (x, y, z). Color follows the standard RBG triple, and texture can be thought of as an image that covers the object.
- Lights - Mathematical objects with positions and/or directions in 3D space, with color attributes, etc.
- Camera - Mathematical object with position and orientation in 3D space. Controls what is actually seen, much like a real camera (starting to connect to our analogy). This defines a viewing area, or view frustum.
- Viewport: Defines the size and resolution of the final image
While this may seem a little abstract, simply remember this: OpenGL ES can construct a 2D bitmap of everything in our scene from the camera's point of view. This is all done via projection.
