Hi James,
...Thanks to all who responded with advice. Right now I don't see a solution.
I am aware that the components of the location are integers. But in the line:
Set the loc of graphic "ball" to theXYcoordinates
RR will truncate the components of theXYCoordinates and set the loc of the graphic to the integer poitns.
In my applications, the coordinates are computed, for example the x and y coordinates of a planet moving around the sun and will therefore not generally be integers.
Unfortunately the move command requires integer input. (I have asked, as a feature request, that RR do the truncation in the engine as
sorry, but it looks like i am not getting the point...?
Why not use the "round" function to supply integers for your handler?
it does for set loc. I don't know if this has been implemented in RR 2.5.) If I were to use the "move" command it would be necessary to include a truncation step in the handler and this shows things up quite a bit. But even with integers, the move command is much slower than set loc.
???
Setting the loc is "instantly", moving includes a REAL movement, even if the distance is ridiculously small ;-)
AND "move" depends on the current "movespeed", if not used with "in... xx time" see below...
For example:
on mouseUP put the ticks into tstart set the loc of grc "ball" to 100, 100 put 1 into dx put 1 into dy put the loc of grc "ball" into tBallLoc repeat 500 add dx to item 1 of tBallLoc add dy to item 2 of tBallLoc set the loc of grc "ball" to tBallLoc -- Takes 34 ticks --move grc "ball" to tBallLoc without messages-- Takes 266 ticks --wait 1 millisec --using this and set loc takes 84 ticks end repeat set the loc of grc "ball" to 100,100 put the ticks - tStart & return after field "data" end mouseUP
But I think Malte has the answer. Yes, I am using one of the first G4 PowerBooks. But it may be something much more sinister than just a poor graphics card.
I put some busy work into the repeat loop to see if this would give RR time to make the display. For example
Repeat 1000 times add 1 to temp end repeat
But the motion was still herky-jerky, and displayed the graphic only at a few screen locs.
I'm getting in way over my head here, but I wonder whether there may be a problem in RR in the screen refresh. When I insert the wait 1 millisec line into the repeat loop, the graphic is displayed uniformly throughout the motion. But the busy work above does not create the same effect. Is it possible that there is a screen refresh after a wait command but perhaps not after a set loc command? As I say, I am in over my head here.
Why not use:
...
set the loc of grc "ball" to 100, 100
put 1 into dx
put 1 into dy
put the loc of grc "ball" into tBallLoc
add 500 to item 1 of tBallLoc
add 500 to item 2 of tBallLoc
move grc "ball" to tBallLoc in 973 millisecs
## or 1.2 secs or whatever...
## this will be equal on ANY machine, since "move... in..." will try to compensate the different
## CPU speeds! May look a bit jerky on slower machines but the graphic will "arrive in time" ;-)
...
Jim
I may overseeing something obvious! Maybe not ;-)
Regards
Klaus Major [EMAIL PROTECTED] http://www.major-k.de
_______________________________________________ use-revolution mailing list [email protected] http://lists.runrev.com/mailman/listinfo/use-revolution
