Trouble with graphics display in OS X

[Klaus Major]

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
klaus at major-k.de
http://www.major-k.de