OpenGL Texturing has been re-invented multiple times, with different hardware implementations each time. As a developer, you need to be comfortable with all of them.
The newest (and preferred) system is provided by the Fragment Shader itself. People often don’t bother to name it, but technically it’s “procedural texturing”. This is fast, extremely configurable, and has potentially infinite resolution. It’s the most general-purpose scheme (in GL ES, the other texturing systems are partly built on top of it). But if you google for it, you’ll get hits almost exclusively on the hardcore “niche-within-a-niche” of advanced procedural techniques.
For instance, browse the awesome ShaderToy.com. ShaderToy demos nearly always use procedural texturing to some extent. The most impressive ones use an extreme form that eschews polygons completely, and converts the whole of OpenGL into a pseudo-ray-tracer. I’m not going to explain it, but if you’re interested, ShaderToy’s author wrote an article that explains the basics of that approach.
The oldest system is “texture-mapping”, that uses raw images (e.g. PNG – but could be simple byte-arrays of data) and wraps them onto a surface. OpenGL tutorials often start with this because it’s the one GL coders have used for longest, even though it’s harder to use and less powerful.
The first two posts will cover different approaches to Texturing, the third one will cover simple special effects:
- Part 5. Textures 1 of 3: Texturing Triangles using Shaders
- Part 6. TBD: Textures 2 of 3: Texture-Mapping Triangles using Bitmaps
- Part 7. TBD: Textures 3 of 3: Animating Textures using Uniforms
But before we go further, we need to understand where Texturing comes from…
Resolution
Whenever you draw an image to screen in 2D, artists and programmers have to agree on two things. 3D has some extra worries, but in 2D it’s simply:
- Image format (PNG? JPG? etc)
- Image resolution (320×240? 100×100? 32×32? etc)
Working together, there are two techniques you can use to define resolution:
- Start from “what percentage of screen size (%) I want”, and work backwards
- Start from “what image-size I want (pixels, voxels)”, and work forwards
You choose one approach or the other based on what the app is doing with the image. If the image is a background, you’ll want the former: “100% of the width and height of the screen / window”.
But if the image is a sprite (e.g. an ememy spaceship), you usually want the latter: a fixed pixel size. Of course, this causes larger monitors to show more of the game-area. Usually this is a desirable side-effect: Players bought bigger screens so they would see more!
