Trouble with graphics display in OS X

[James Hurley]

>
>
>Message: 14
>Date: Wed, 12 Jan 2005 16:32:17 +0100 (CET)
>From: malte.brill at t-online.de
>Subject: Re: Trouble with graphics display in OS X
>To: use-revolution at lists.runrev.com
>Message-ID: <1105543323.41e5409ba803b at modem.webmail.t-online.de>
>Content-Type: text/plain; charset="iso-8859-1"
>
>Hi James,
>
>>I am running RR 2.2.1 and OS X 2.3 on a PowerBook G4
>
>I suspect it¥s one of the first Powerbooks G4 (am I right?)
>
>The problem in this case is the built in graphics card and the way Os X
>deals with displaying graphics. I¥ve seen this with libRMC moved
>objects (and  also useing the move command) too on older Powerbooks or
>desktop Macs with graphic cards that had <=32 MB... If one wants to do
>smooth animation useing Rev and OsX allways recommend a graphics card
>as much RAm as is reasonable (32 MB is the minimum, best will be 64 MB
>or more)
>
>Regards,
>
>Malte
-----

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 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. 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.

Jim