Rotating a graphic 360degrees in 60s

[glenn9]

Hi Everyone,

I'm trying to figure out, and not having much success, of how to have the arc of an oval rotate 360 degrees in 60 seconds, similar to that of the second hand of a clock.

However, I don't want it pause at each second interval, ie it should sweep 360 degrees smoothly in 60s without stopping.

So far I've tried some 'trial and error' amendments to Bernd's clock code below but I've had no successs so far - grateful for any hints or tips.

Kind regards,

Glenn

Code: Select all

-- altered clock code from Bernd
global sRun

on movetime
   if sRun is true then
      
      lock screen
      set the twelvehourtime to false
      put the date && the long time into tDate
      convert tDate to dateItems
      put tDate into tCurrdateItems
      put item 6 of tCurrdateItems into tSeconds
      
      put tSeconds * 6 into tSecondsAngle
      
      put (360-tSecondsAngle + 90) into tSecondsAngle
      
      set the startAngle of grc"seconds" to tSecondsAngle
      
      unlock screen
      
      put 1000 - (char -3 to -1 of the milliseconds) into field"fhundredsmilliseconds"
      put 1000 - (char -3 to -1 of the milliseconds) into tHowManyMilliseconds
      
      send movetime to me in tHowManyMilliseconds milliseconds
   
   else
      break
   end if
   
end movetime

[bn]

I'm trying to figure out, and not having much success, of how to have the arc of an oval rotate 360 degrees in 60 seconds, similar to that of the second hand of a clock.
However, I don't want it pause at each second interval, ie it should sweep 360 degrees smoothly in 60s without stopping.

Hi Glenn,
There are limits to "smooth" movement of the seconds hand.
1. you can only set the startangle of a graphic in 1 degree increments.
Consider 1 second: 360 degrees/60 seconds = 6 steps possible for 1 second.

2. You have to trigger the redraw more often by reducing the interval you are calling "moveTime". Currently with update on every second you basically update the hands every second. To make more steps the interval could be reduced to 1000 milliseconds / 6 steps = 166.66 milliseconds.

With the above in mind you could change the code to

Code: Select all

 -- seconds
      put the seconds mod 60 into tRestSeconds
      put tRestSeconds * 6 into tSecondsAngle --convert to angle in degrees
      put (360 - tSecondsAngle + 90)  into tSeconds -- adjust for clockwise increment and for 0 or 12 being at the top
      -- set the startangle of grc "seconds" to tSeconds
      
      --  the same for "continous" seconds
      put the milliseconds mod 60000 into tMilliRest
      put tMilliRest * 6  into tMilliAngle
      put trunc(tMilliAngle / 1000 ) into  tMilliAngle2
      put  (360 - tMilliAngle2 + 90)  into tSubSeconds
      set the startangle of grc "seconds" to tSubSeconds
      -- end seconds

(I left the old code for jumping seconds and use only the lower for "continuous" seconds

You would have to change

Code: Select all

send movetime to me in tHowManyMilliseconds milliseconds

to

Code: Select all

send moveTime to me in 166 milliseconds

All this will update more frequently but still not move smoothly.

To have a smooth movement you have to update roughly 20 to 30 times per second which is of no use in this case because of the limitations of setting degrees to whole numbers only. It would be a waste of processing time with no better visual experience.

I hope this makes sense.
Kind regards
Bernd

[dunbarx]

There is certainly a way to make a smoother running gadget, but it is a mighty kludge.

If you take a line graphic and change its rect ever so slightly, the resolution of its "angle" will be limited to individual pixels, not the fact that 1/360 is the limit of the startAngle property.

The larger the graphic, the finer the resolution. In other words, if the rect of a line graphic is, say, "100,100,500,500", and you change it to "100,100,501,499, you will get a tiny change in the angle. This can all be calculated to create a very smoothly running second hand, tethered to "100,100".

Now this method is most advantageously exploited with large graphics, because there is so much more "room" to move. That may be a deal killer in any reasonable scenario.

Craig

[dunbarx]

Well, this works even with relatively small line graphics. Make one, and put this into a button script:

Code: Select all

on mouseUp
   set the rect of grc 1 to "300,300,400,400"
   repeat 50
      set the rect of grc 1 to "300,300," & item 3 of the rect of grc 1 + 1 & "," &  item 4 of the rect of grc 1 - 1 
      wait 8
   end repeat
end mouseUp

The sweep is not perfect, because I only spent 30 seconds writing this. But getting the "best" x,y values for items 3 and 4 of the rect is straightforward. The fact that the pixel resolution is pretty fine is a good thing. The fact that each iteration will only approximate the theoretical "correct" new angle probably does not matter.

Craig

[richmond62]

Of course . . .

[AND I am just telling you this because I am an awkward type]

. . . you could have 60 images of your second hand and display them one at a time.

[dunbarx]

Richmond.

you could have 60 images of your second hand and display them one at a time.

That still limits the smoothness of the sweep to 1/60ths. The original quest of the OP was smoothness.

Craig

[richmond62]

Then you could do "it" with a graphic and keep changing its points.

[dunbarx]

Great idea Richmond. You might read something similar just a few posts up in this thread.

Craig

[richmond62]

Great idea Richmond. You might read something similar just a few posts up in this thread.

Nope: does not look similar at all to me.

My diea would be to have the points that define the shape of the graphic "2ndHand" being constantly changed
via an algorithm.

[dunbarx]

Richmond.

Hmmm. I assume this is after you read those couple of posts above.

I thought we might change the points of the graphic in sequence.

You are suggesting that we change the points of the graphic in sequence.

The distinction seems subtle to me, so please explain further.

Craig

[richmond62]

The problem is a bit like Zeno's arrow.

Or, our own perceptions.

1. If Disney could fool all of us all of the time with 25 frames per second LiveCode should be able to fool with that.

1.1. 60 * 25 is one hell of a lot of individual images [ 1500 ]to have to render, import, and then 'shuffle'.

2. Changing the points of a graphic in a series of steps from a list of points might still apear jerky.

3. Changing the points of a graphic using a repeating algorithm, while, also, delivering a set of steps,
might allow us to fine them down to such small increments that the eye is deceived,

[dunbarx]

Richmond.

Have you looked at all at the graphic idea I posited in the third post and actually fabricated in the fourth post in this thread?

My question is this: "what are you proposing that is different"?

Craig

[richmond62]

Probably not much.

[dunbarx]

OK.

I had an idea that I could change the rect of a hidden VERY large line graphic in pixel increments, giving exquisite resolution, and then set the rect of a smaller visible working line graphic to a scaled version of that. But the smaller grc would have to find its own closest end pixel, and so it loses the resolution of the larger.

A limitation of a pixel-based, as opposed to a numerically-based screen representation. Too bad...

Craig

[bn]

Gentlemen,
Here is a little stack that moves the seconds smoothly at a frame rate of about 25.

I do not recomend this for the "clock" because it is very hard to implement.

drawSecondsHandClock.livecode.zip

(1.64 KiB) Downloaded 37 times

Kind regards
Bernd