Question

I am studying OpenGL ES 2.0 shaders from this cool raywenderlich tutorials and I was wondering why a Sprite is said to have 4 vertices. Are there cases with more than 4 vertices?

I know it sounds silly, but I was expecting it to have to have as many vertices as required to form the border of the visible part of the sprite. In other words, I thought that the alpha channel was a way to delimit the sprite.

I then checked the bullet collision methods in my game (I used a template to start with it) and they use the sprite bounding box. Box mean four vertices :), so I should not be suprised.
But still, I was expecting Cocos2D to have a way to detect the non visible pixels.

Could anyone help me clarifying this a bit more? Are there more ways to do bullet collision detection that detect only the visible pixels? [I found some answer but wasn’t accepted and it seems to take many steps, I thought there could be a built in Cococs2d method].

Or is this something I will have to figure out after having learnt shaders in OpengGL ES 2.0?

Answer 1

Sprites are textures displayed on screen, with properties like scaling, rotation, position, color, etc applied to it.

Textures are rectangles because they’re in-memory images. To draw a rectangle you need 4 vertices. Historically, GPUs only worked with quadractic, power-of-two textures because that was the simplest to implement in hardware. Later textures could be any rectangle and on more modern iOS devices (iPhone 3GS I think) you can also use NPOT texture (non-power of two). But overall, textures are and will always be rectangular.

To make a texture partially transparent, it has an alpha channel. This acts like one of the 3 RGB channels except it controls how transparent a pixel is. In some texture formats the alpha channel only stores on or off (1-Bit alpha).

So when the GPU renders the texture to the screen, all pixels with an associated alpha value of 0 are not drawn at all, allowing the background pixels to show through.

Tracing the visible parts of an image to get the collision polygon requires running a relatively complex algorithm. For example PhysicsEditor employs such a mechanism to generate physics collision information from images (see video at 0:15).

GPUs don’t use that technique because:

• the initial tracing is costly
• the resulting polygon would be complex (100+ vertices)
• the polygons would greatly vary in complexity depending on the image, which would make it hard to optimize rendering

Essentially it’s a lot easier and faster to go over the entire texture and not render 0 alpha pixels rather than concentrating on finding, storing and rendering only the visible pixels.