Home/ Questions/Q 8204157
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-07T07:48:35+00:00

I’m working on a game for iOS and I’m having some trouble with a

  • 0

I’m working on a game for iOS and I’m having some trouble with a texture using glDrawArrays (using cocos2D v1.0.1, with OpenGL ES 1.1). I first create an array of CGPoints that define the top and bottom of a hill, along with an array for the texture coordinates:

hillVertices[nHillVertices] = CGPointMake((topLeftVertexX)*CC_CONTENT_SCALE_FACTOR(), topLeftVertexY*CC_CONTENT_SCALE_FACTOR());
hillTexCoords[nHillVertices] = CGPointMake((topLeftVertexX)/textureSize.width, 0.0);
nHillVerticies++;
hillVertices[nHillVertices] = CGPointMake((bottomLeftVertexX)*CC_CONTENT_SCALE_FACTOR(), bottomLeftVertexY*CC_CONTENT_SCALE_FACTOR());
hillTexCoords[nHillVertices] = CGPointMake(topLeftVertexX)/textureSize.width, 1.0);
nHillVerticies++;

and then draw using…

glBindTexture(GL_TEXTURE_2D, groundSprite.texture.name);
glVertexPointer(2, GL_FLOAT, 0, hillVertices);
glTexCoordPointer(2, GL_FLOAT, 0, hillTexCoords);
glDrawArrays(GL_TRIANGLE_STRIP, 0, (nHillVertices-1));

In the beginning of the game (when the “topLeftVertexX” value is small), the hills look good…
Hills with a small x offset

But as the game continues, the x offset value (topLeftVertexX) increases, and things start to get worse…
middle x offset

And near the end, it gets bad…
x offset large

I think the problem is that in the beginning of the game, the “topLeftVertexX” value is small, so the result of

(topLeftVertexX)/textureSize.width

in 

hillTexCoords[nHillVertices] = CGPointMake((topLeftVertexX)/textureSize.width, 0.0);

is small. However, as the game continues and the x values increase, I think the value is getting large enough to cause some sort of corruption. The textureSize is 512×512, and the “topLeftVertexX” begins at 0 at the beginning of the game, and goes up to about 200,000.

I have tried increasing the number of triangles (including adding additional strips), but that doesn’t help. I also tried using @jpsarda’s CCSpriteBiCurve class, and got the same result. I also tried using the glHints (such as GL_LINE_SMOOTH_HINT with GL_NICEST), but I haven’t found anything that helps.

Any ideas how I might fix this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    It’s not getting corrupted, you’re just losing floating point precision as the magnitude of your number increases.

    As your number gets larger and larger, the delta between each successive point gets larger as well.

    In IEEE754, the difference between 1.f and the next larger number is 0.0000001

    At 200,000, the next larger number is 200,000.02. (courtesy of IEEE754 converter). I’m not even 100% positive what kind of FP precision GLSL uses (the quick ref card indicates it might be 14-bit mantissa in the fragment shader?). So in reality it could be even worse.

    If you’re just looking at a small window of a large number, then the error will continue to grow. I suspect that as the precision goes down, your texture starts to look more and more ‘blocky’.

    The only thing I can think of to do is to design your code such that the number does not have to grow unbounded forever. Is there a smarter way you could wrap the number over so that it doesn’t have to get so large?

    • 0