RB Game Experts,
I am using REALbasic 2005 on a MacMini running OS X 10.3.9 with a 1.25GHz
PowerPC G4 processor, 256MB RAM, 40GB hard drive, and ATI Radeon 9200
graphics processor with 32MB of DDR video memory.
I am trying to get precise control of the duration of Sprites on a
SpriteSurface. Duration is the time that two separate 50x50 sprites are
visible within a 600x600 spritesurface; smallest duration I need is 1 frame
at a 60 Hz frame rate.
The built-in double-buffering seems to be doing its job correctly most of
the time. Occasionally, a 50x50 sprite - that is displayed for 1 frame - is
displayed partially, with uneven brightness, or in some rare instances not
at all. It seems that the display is getting updated during the vertical
blanking interval which, in turn, means that double-buffering isn't always
working or maybe it isn't working at all.
If I do a simple test program where all I do is move the sprite right and
down by 1 pixel each frame, there is a "hiccup" or "tear" (jerky motion,
jagged edges) about once every 3 times (for a 3 second duration) but whether
or not it occurs seems to be random. It seems like there is a background
process that is interrupting the spritesurface timing (Would adjusting the
thread priority help?). The example program I am using has a PushButton1
and a SpriteSurface1. Here is code for PushButton1 Action event (add
properties to window1: i as integer, S as sprite, SmallPicture as picture
which is 50x50):
i=0
S = SpriteSurface1.NewSprite(SmallPicture,-50,0)
SpriteSurface1.Run
In SpriteSurface1 NextFrame event (SpriteSurface1 width and height are 300):
if i=1 then S.x=0
if i=250 then
S.x=-50
S.y=0
me.stop
end
i=i+1
S.x=S.x+1
S.y=S.y+1
I am aware that the screen only updates AFTER the NextFrame event has
completed. Does that mean that RB waits for the beginning of a retrace
cycle, then updates the display with the changes made in the just-completed
NextFrame event? Shouldn't this guarantee that the display is only updated
during the blanking interval? What happens if the updates take longer than
1 frame to complete? In any event, in my case at least, something seems to
be interfering with this.
Is there any way to read the vertical retrace status bit directly? This
approach might work better (for me) but not sure it would solve the problem
(even if it is possible.
Thanks in advance for your help.
Ken
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
|