How are Rotate speed and move speed measured?

Hi all,

Just working on a project where I need to time some actor rotations exactly with some horizontally moving actors, and it got me wondering...

How exactly are rotation speeds measured? Is it degrees per second...or some other measurement?
How exactly are move speeds measured? is it pixels per second, or some ratio based on screen dimension etc?

Im not sure Ive ever seen the question asked before, and couldn't bring up much with a quick search...

Normally its just been a case of what looked right for me in the past... but for this particular project i need to get things matched up exactly, so figured it would be best to understand fully how the rotate and move speeds were measured/calculated :)

Sorry if its a bit of a newbie question... Ive just never needed to know it in the 5 years I've been using GameSalad! :neutral:

Comments

  • SocksSocks London, UK.Member Posts: 12,822

    @Chunkypixels said:
    How exactly are rotation speeds measured? Is it degrees per second...or some other measurement?

    Yep, degrees per second.

    How exactly are move speeds measured? is it pixels per second, or some ratio based on screen dimension etc?

    Pixels per second.

  • ChunkypixelsChunkypixels Member Posts: 1,114

    Cheers... @Socks ... pretty much how I expected then... probably why I've never really needed to ask over the past 5 years :)

    So its probably just my maths and rounding down to the nearest number thats not quite right, and why Im getting a couple of things not matching up quite perfect!

  • SocksSocks London, UK.Member Posts: 12,822

    @Chunkypixels said:
    So its probably just my maths and rounding down to the nearest number thats not quite right, and why Im getting a couple of things not matching up quite perfect!

    It should be easy to convert between the two, I suppose it depends on the relationship between the two.

  • ChunkypixelsChunkypixels Member Posts: 1,114

    @Socks Im rotating a compass at a rotate speed of 30, and moving a corresponding set of 4x 1024 images that connect to show a 360 panorama mountain range.

    So if Im rotating at speed 30 it takes 3 seconds to rotate 90 degrees, and each of my 1028 pixel sections covers a 90 degree segment of my panorama, then my average math skills tell me I need to move at 1024 divided by 3.. which comes out at 341.333

    So to get the images matching the compass direction exactly, I should be moving the mountains at a speed of 341.333 to match up. At that speed, its almost right..but starts to get wrong by a few pixels after a couple of rotations on the compass... I tried rounding it to both 341 and 342 and it still errors after a few rotations.

    I'll keep tinkering at it.... :)

  • SocksSocks London, UK.Member Posts: 12,822
    edited June 2015

    @Chunkypixels said:
    So if Im rotating at speed 30 it takes 3 seconds to rotate 90 degrees, and each of my 102[4] pixel sections covers a 90 degree segment of my panorama, then my average math skills tell me I need to move at 1024 divided by 3.. which comes out at 341.333

    So to get the images matching the compass direction exactly, I should be moving the mountains at a speed of 341.333 to match up. At that speed, its almost right..but starts to get wrong by a few pixels after a couple of rotations on the compass... I tried rounding it to both 341 and 342 and it still errors after a few rotations.

    I'll keep tinkering at it.... :)

    Sounds like a rounding error, 1024/3 should be 341.33333333333333 [. . . . .] rather than 341.333 (as I'm sure you know), so 341.333 will be out by a little, accumulatively so after a while, and 341 and 342 will be going in the wrong direction, you should be making the math more accurate rather than less ! :smile: But there are probably other factors at play.

    Personally I'd just constrain the image's x position to the compasses rotation, that way they cannot slip out of sync.

  • SocksSocks London, UK.Member Posts: 12,822

    Here's a demo project, the big white BG actor's X is constrained to the red square's rotation * 2.84444444444444, so rounding errors cannot pull them out of sync (they are aligned to the same value on every processor cycle).

    To illustrate this I have the red square swinging back and forth.
    A white X flashes when the red square hits 0° and 360° (its two extremes)
    A red X flashes when the white BG hits 1024 and 2048 (its two extremes)

  • ChunkypixelsChunkypixels Member Posts: 1,114

    @Socks adding the extra 3s on the end seems to have tidied it up. There I was thinking it didn't need to be so accurate down to so many digits... :)

Sign In or Register to comment.