As it stands right now, if I perform a CopyBits from the screen to theQuote:> Jeff,
> What about making the offscreen world the full width of the background and
> always copy 640 x 480. The source rectangle would then slide through the
screen, it takes ~900 ticks (15 seconds) to move the entire contents of the
screen on my IIci (for right now, I draw an image on the right side of
the screen and I record the time it takes to 'move' the image to the left).
If draw the contents originally to an offscreen GWorld, then move the bits of
the offscreen GWorld via CopyBits, then perform a CopyBits from the
GWorld to the screen, it takes ~950 ticks (it turns out ~325 ticks are
from performing the CopyBits from the offscreen GWorld to the offscreen
GWorld, and ~625 ticks are from performing the CopyBits from the
offscreen GWorld to the window.
Yes, this is a step I am intending to look into. However, since the realQuote:> offscreen buffer instead. If you know the bit depth and other things you
> could probably write a faster bit copy yourself (unrolled loop with lots of
> MOVE.L (a0)+,(a1)+ or perhaps MOVE16 (on '040s)).
bottleneck is drawing to the Window, I expect that this will not improve
performance by thaat much.
That is in fact the very next thing I will be trying out.Quote:
> BTW, have you tried ScrollRect for onscreen scrolling? CopyBits has to take
> care of color tables, scaling and other stuff, but ScrollRect should be
> smarter about scrolling.
Yea, I know what you mean... but I thought I'd at least try. On theQuote:
> Unfortunately I doubt you'll get a full-screen scrolling game running smoothly
> in 640 x 480 on a IIci. Remember, both Solarian and Maelstrom use static
bright side, I tried the test out on a PowerPC and it only took 5 seconds
to scroll the entire screen! I was hoping to get the programs'
requirements down to a 030, but time will tell...