Hi all,

Because I batch my sprites I rotate them not using glrotate etc.
Instead a more conventional:

new_x = cos(rotate)*(x_width - t.x) - sin(rotate)*(y_height - t.y) + t.x;
new_y = sin(rotate)*(x_width - t.x) + cos(rotate)*(y_height - t.y) + t.y;

The problem is as my quad is actually 2 tri's it 'wobbles' especially on the edge (i.e. where the 2 tri's meet).
Is there anyway to get opengl to perhaps ignore the rounding errors (which I presume are causing the problem)?
After-all using glrotate on a supposed quad does produce a 'smooth' (i.e. wobble free) rotation.

thanks in advance

Mark

(Nov 19, 2010 05:58 AM)markhula Wrote:  Is there anyway to get opengl to perhaps ignore the rounding errors (which I presume are causing the problem)?

If your coords are off because of rounding error on your side, I don't see how the GL is going to know how to "fix" them for you.

Hi,

I guess my coords are not 'off' and it's how GL render's the 2 tri's i.e. their coordinates on 2 points should be identical.
Perhaps there is some GL render state I need to set that I am unaware of.

Mark

I'm using fixed point math to compute vertex positions for rotated quads (two triangles), and never had this problem.

Are you definitely passing the same vertex positions, for the 2 matching vertexes on each triangle? I'd be tempted to double-check that first. Other than that, is there anything in OpenGL relating to the blending mode on edges of triangles?

(Nov 19, 2010 08:05 AM)markhula Wrote:  Hi,

I guess my coords are not 'off' and it's how GL render's the 2 tri's i.e. their coordinates on 2 points should be identical.
Perhaps there is some GL render state I need to set that I am unaware of.

Mark

Are you using GLfloat's? If so, the GL will draw them where you say to draw them. If not, well then there's your problem.

The easiest way to ensure that your vertices are really coincident is to repeat indices in drawelements.

Only calculating each vertex once and then reusing it should work though...

There has to be something else going on here. Are you assigning a float to an int somewhere maybe? That would produce some pretty gross looking "wobble" as the corners snap to different integer values at different times.

Hi all,

Thanks for the replies.
The coordinates are definitely the same; because I only compute 4 and 'copy' the shared 2; making the required 6 in total.
My glVertexpointer is GL_SHORT so no floats for the render.
The wobble is especially noticeable at slow speeds i.e. the 2 halves of the image just 'wobble' at the point they meet.

cheers

---

OK!,
Fixed it.
It was my fault (obviously!); I had GL_SHORT's instead of GL_FLOAT's for my vertexpointer. Rotation now smooth.
I guess therefore this is obviously slower; so should I use GL_SHORT for non-rotated sprites and GL_FLOAT for rotated sprites???; of
course this now messes up my sprite batching.
Is the speed penalty really that bad?!?!???

Cheers

The correct answer was yes. Again the problem is that you are performing a nice precise correct rotation using floating point math, then storing the result into an int and throwing all the subpixel accuracy of the calculation away. As the corners of your quad snap to different grid points at different times, it's going to give you really really nasty wobbly looking rotations. Even if things aren't being drawn anti-aliased, the extra sub-pixel accuracy of floats does make a difference to how the line is drawn.

You could fix it by using fixed point (bad bad idea), or just use GL_FLOAT for your vertex arrays.

Thanks!

I guess my question now is whats the speed penalty for using GL_SHORT over GL_FLOAT?
i.e. is it worth my having a separate draw list for rotation (i.e. GL_FLOAT); but that means texture changes.

Is the penalty really that bad?!?

Cheers

I've never heard of such a penalty myself, but the only way to be sure is to observe it for yourself. The recommendation you'll probably hear around here is not to try to optimize something until you've implemented a working solution, empirically measured it, and found a bottleneck that's causing your game's performance to suffer unacceptably. Increasing your code's complexity without hard data or prior direct experience telling you it's necessary for performance is usually wasted effort.

Floats are twice the amount of data to send to the GPU as shorts, so yeah, there will be a performance penalty. How much of a penalty? Probably not much.

Practically speaking, I use floats everywhere. If I happen to notice I can use shorts somewhere instead, without causing me a hassle, I will use shorts. Otherwise I've learned that it's not worth losing sleep over those details until/unless it becomes necessary.

Batching can be particularly helpful, but I don't even design for that ahead of time anymore. Just draw the stuff, and if it's too slow, then consider things like batching, or change the game design to Draw Less Stuff™.

Thanks-all!
Will keep with FLOATS for now.
And as pointed out; when it does all start slowing down there are probably a million other things to optimise before resorting to meddling with floats to shorts :-)

Cheers!