Errata

Bone generation of indexes is incorrect in the case when there are 9 matrix units (1st gen iPod) - in which case the { i0++;i1++;} code can overflow and produces '9' as a result in some cases.

The result is some vertices are skinned to the wrong position and thus a somewhat distorted stick figure.

Note from the Author or Editor:
Yes, the skinning example does not work properly with OpenGL ES 1.1. Unfortunately this is due to a fundamental flaw in the code, so the fix is too involved to be conveyed here. For the second edition, we will remove the ES 1.1 variant of this sample.

This is the sentence which I think has the error.

Replace the OpenGL Initialization comment with Example 1-3.

I do not see a comment which says "OpenGL Initialization" anywhere in the previous text.

Note from the Author or Editor:
On page 16, the comment that says "Initialize code..." should say "OpenGL Initialization".

EAGLRenderingAPI api = kEAGLRenderingAPIOpenGLES2;
m_context = [[EAGLContext alloc] initWithAPI:api];

I think this code should change to:

EAGLRenderingAPI api = kEAGLRenderingAPIOpenGLES2;
if ( !ForceES1)
m_context = [[EAGLContext alloc] initWithAPI:api];

If device supports ES 2.0 and the ForcesES1 is set true, EAGLContext object with ES2 API is allocated but not used.

Note from the Author or Editor:
Yes, this results in a minor memory leak. Good catch!

The array size is incorrect.

vec2 vertices[6] = { vec2(0, 0), vec2(0, 1), vec2(1, 0), vec2(1, 1) };
=> vec2 vertices[4] = { vec2(0, 0), vec2(0, 1), vec2(1, 0), vec2(1, 1) };

The description following this code is also wrong.

That's only 48 bytes,
=> That's only 32 bytes,

Note from the Author or Editor:
Good catch! Your corrections are spot on.

Using strstr isn't quite kosher. For example, checking for GL_ARB_shadow with strstr will bite you if you have GL_ARB_shadow_ambient.

(The explanation of the constant GL_FUNC_ADD)
Adds the source operand to the source operand; this is the default.
=>
Adds the source operand to the destination operand; this is the default.

Note from the Author or Editor:
Good catch Kazuya.

There is no need to call glRenderbufferStorageOES as the space has already been allocated by the associated texture object. Thanks to Douglass Turner for catching this.

the GPU can take the cross product of two edges

should go:

the GPU can take the dot product of two edges

because a cross product results in a vector which has no sign. The GPU should take the dot product of the two edges producing a scalar value which represents the angle between them.

Note from the Author or Editor:
It's true that this sentence needs clarification, but a dot product would be incorrect. The actual correction is changing "if the resulting sign is positive" to "if the resulting sign of the Z component is positive".

I had posted earlier in this errata that there was a rendering difference between the ES1 and ES2 versions of the example programs, and I explained how to illustrate this difference by setting up constants for the HelloCone project that make the discrepancy more obvious. I believe I have since figured out the root of the problem. In the function listed in the appendix:

static Matrix4<T> Frustum(T left, T right, T bottom, T top, T near, T far)

The last statement should be m.w.w = 0; NOT m.w.w = 1 (as the book and online appendix state). When I made this change, the ES1 and ES2 renderings were identical, instead of there being slightly off clipping and zooming in the ES2 version.

I am almost positive that this is correct as my program confirms it. I hope the author has a chance to read this over and confirm it himself so that I can move forward from chapter 2, confident that I have made the right change!

Note from the Author or Editor:
In Matrix.hpp (listed in the Appendix), change the Frustum method so that it sets m.w.w to zero rather than one.