Polygon rotation is too fast compared to objects rotation

Started by
35 comments, last by manderin87 11 years, 4 months ago
The issue pops up even if i dont use deltaTime at all, that was my attempt to limit the amount of updates, but even without it, the polygon still rotates slow and fast.


I think your code is increasing mDegree by 0.5 each frame, and mDegree is the amount that you're rotating your object each frame. So after 100 frames you're rotating by 50 degrees per frame. Eventually, you're rotating so fast that it's starting to slow down and reverse.


This is what the polygon is doing, but I dont know how to fix it. The degree is the current degree, should it just be the incremented amount instead?

mDegree is the current degree of the object and is increased by .5 every frame.
Advertisement

mDegree should be how much to rotate by this frame. It should not grow with time. What rotate() is doing is increase the rotation speed.

EDIT: Wait... I think I see what the others are seeing now. Is it possible that mOrigins and mPoints are actually the same thing?

FURTHER EDIT: What does this line do?
Point npoint = mPoints.get(i);

[/quote]

There are two lists of points inside the polygon class. The original points mOrigin and the current points mPoints. mPoints changes and mOrigin does not with the rotation.

That code takes the point i from mPoints and updates it.

The rotate method just applies the .5f to increase the degree... The speed never increases, its always .5f and mDegree is increased by that amount each update.

That code takes the point i from mPoints and updates it.

But since you are going to set x and y, why do you bother reading the old value?

mDegree is the current degree of the object and is increased by .5 every frame.

In case my previous post got skipped, you DON'T WANT to establish a "per frame" rate, as you can't necessarily control the varying length of time it takes to process each frame. Ex: your player is facing a wall that takes up 95% of their view and isn't moving. That frame only takes 2ms to process. Then they turn around, facing 2000 props, 12 animated enemies, and dozens of particle streams. That frame takes 17ms to process. Your triangle would be spinning like crazy at the 2ms/frame, and then slow down considerably at the 17ms/frame.

Rotate at a fixed time rate, not frame rate. That's why you want to use deltaTime, correctly, and why when you weren't bothering to use deltaTime it sped up and slowed down.

Hazard Pay :: FPS/RTS in SharpDX (gathering dust, retained for... historical purposes)
DeviantArt :: Because right-brain needs love too (also pretty neglected these days)

I don't think it's an issue with the frame rate. The only suspicious part in how the code in the first post handles the frames is that there is a call to drawBounding() inside of the loop that updates the state, which seems wrong. Either the update happens independently of the drawing or --if update() is responsible for drawing-- the drawing should only happen once, at the end of the function.

In case my previous post got skipped, you DON'T WANT to establish a "per frame" rate, as you can't necessarily control the varying length of time it takes to process each frame. Ex: your player is facing a wall that takes up 95% of their view and isn't moving. That frame only takes 2ms to process. Then they turn around, facing 2000 props, 12 animated enemies, and dozens of particle streams. That frame takes 17ms to process. Your triangle would be spinning like crazy at the 2ms/frame, and then slow down considerably at the 17ms/frame.

Rotate at a fixed time rate, not frame rate. That's why you want to use deltaTime, correctly, and why when you weren't bothering to use deltaTime it sped up and slowed down.


That certainly sounds like what is going on, should i just multply the rotation speed by the deltatime? The behaivor happened even when deltaTime wasnt there.


I don't think it's an issue with the frame rate. The only suspicious part in how the code in the first post handles the frames is that there is a call to drawBounding() inside of the loop that updates the state, which seems wrong. Either the update happens independently of the drawing or --if update() is responsible for drawing-- the drawing should only happen once, at the end of the function.


The drawBounding() was relocated from the rendering loop so i could see if it had any effect. Its been moved back since, but the behaivor never changed.
I added to the rotate method

[source lang="java"]mDegree += mRotationSpeed * deltaTime[/source]

This fixed the polygon rotation a little, it doesnt rotate as fast as it did, but it still rotates much faster than the object.


if(isActive()) {
rotate();
mBounding.rotate(mPosition.x, mPosition.y, mDegree);
drawBounding();
}


The mRotation should reflect the rotated polygos exactly,
As they're both assigned in the same scope, mutually dependent on the framerate.

Maybe showing some more code will help us in finding the issue?
I dont know if it makes a difference but I am using libgdx to draw everything.

This fixed the polygon rotation a little, it doesnt rotate as fast as it did, but it still rotates much faster than the object.

What does the code in mBounding.rotate(params) look like? Or wait, no, it looks like that's what you showed us above. What does rotate() look like?

Ideally you want the image and the object rotating at the same rate (I'll smack myself for stating the obvious), meaning you would pass them both the same rotation amount. I'd think it would be easier to calculate the rotation degree value (degrees += rotationRate * timeDelta; degrees %= 360; ) once for the frame, then pass that rotation value to both items needing a rotation calculation.

Hazard Pay :: FPS/RTS in SharpDX (gathering dust, retained for... historical purposes)
DeviantArt :: Because right-brain needs love too (also pretty neglected these days)

This topic is closed to new replies.

Advertisement