Fast scrolling on macs

Fast scrolling on macs

Post by Jeff Beeghl » Tue, 14 Feb 1995 03:02:38




Quote:> 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

As it stands right now, if I perform a CopyBits from the screen to 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.

Quote:> 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)).

Yes, this is a step I am intending to look into.  However, since the real
bottleneck is drawing to the Window, I expect that this will not improve
performance by thaat much.

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.

That is in fact the very next thing I will be trying out.

Quote:

> 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

Yea, I know what you mean... but I thought I'd at least try.  On the
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...
 
 
 

Fast scrolling on macs

Post by Peter Matt » Tue, 14 Feb 1995 06:50:45




[SNIP]

Quote:>As it stands right now, if I perform a CopyBits from the screen to 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.

[SNIP]

I think you must be doing something wrong in your CopyBits call (or setting
something up incorrectly). A while back, when I was messing around with
CopyBits and blitting I got 10 frames per second for 320x240 on my IIsi.
Doing the math, this comes out to about 2.5 fps for full screen (640x480).

On a side note, I could never get faster than CopyBits for large copies.
But lots of small copies is a different matter. Plus CopyBits doesn't
allow you to copy every other line and really lags when the source and
dest rectangles aren't the same size. But if you want to copy an offscreen
buffer on screen, your best bet is to go with CopyBits. The apple
programmers really did a job when they programmed that one.

Oh, and to find out how to get the most out of CopyBits, track down
some of the snippets on ftp.apple.com. (I have completely forgotten
the name of the one I'm thinking about, but it shows CopyBits working
with various transfer modes, etc.)

Peter Mattis


 
 
 

Fast scrolling on macs

Post by Jeff Beegh » Tue, 07 Feb 1995 15:46:57


I am an applications programmer, but recently I have had the urge to
write a scrolling shoot-?em-up type of video game.  I know how to program
Mac applications and use graphic calls (like CopyBits), so intricate
graphics are not new to me.  Highly optimized speed/performance however is...

My problem:  I?m currently tinkering with animation scrolling.  
Basically, I?m scrolling the entire contents of the screen (640x480 minus
the menu bar) left 2 pixels on a Mac IIci with a cache card (my goal is
to create a game that will run on slower systems and not to require the
performance of a Qudra).

My first attempt was to fill the contents of the screen up with an image,
then scroll the screen left 100 times

SetRect(&r1, 2, 0, 637, 479);
SetRect(&r1, 0, 0, 635, 479);
for(i=0; i<100; i++)
        CopyBits( &(gMainWindow->portBits), &(gMainWindow->portBits),
                &r1, &r2, srcCopy, nil);
This takes approximately 15 seconds (913 ticks)

Next, I created an offscreen GWorld, copied the image to the offscreen,
then
for(i=0; i<100; i++)
{
        CopyBits(offscreen, offscreen, r1, r2...
        CopyBits(offscreen, window, r2, r2...

Quote:}

This took more time (which makes sense) to draw (934 ticks), but I wanted
to test it out to make sure.

next, I wanted to get some specific performance numbers.  Performing
for(i=0; i<100; i++)
{
        CopyBits(offscreen, offscreen, r1, r2...

Quote:}

took 312 ticks and performing
for(i=0; i<100; i++)
{
        CopyBits(offscreen, window, r2, r2...
Quote:}

took 647 ticks

So I?m back to the drawing board.  The way I see it I can:

A. Reduce the size of the game window.  This would reduce the number of
pixels I need to blit, thus speeding up the scrolling, but I had hoped to
use 640x480.  This is the main reason why games have taken off on the PC
but not on the mac (in my opinion).  In DOS, the program can run in
320x200 x 256 colors and take up the entire screen.  If I only use
320x200 on a 13 monitor on the Mac, the performance would increase by
4x, but I?d only be using a fraction of the screen.  Besides the way I am
intending to set up the game, I need as much screen real estate as possible.

B. Write directly to the screen (or screen memory).  I was originally
planning on doing everything in an off screen GWorld, then blit the
pixels to the window.  As the performance that I have shown illustrates,
using CopyBits is too slow, so I may have to write directly to the
screen.  Are there any ?safe? ways to do this (I?d like a method that
would not only stand up from machine to machine, but one that will work
under System 7.X, 8.X, etc...

C. Increase the number of pixels the screen moves.  In the example above,
I am moving a block of 638x480 pixels left by two each iteration.  I
could move 637x480 left by 3, or 636x480 left by 4, but this becomes too
?blocky? (the scrolling isn?t quite as smooth).

D. Require the game be played on a faster CPU

I?ve thought about using some sort of RLE method - only changing the
pixels that change, but from what I?ve seen, RLE is a good method to use
if the image has large ?solid chunks? of color, but my app will not have
this and my instincts tell me that the performance will be less.

I?ve never programmed a game before and I was wondering if anyone had any
tips/suggestions for me.  Also, does anyone know of any good scrolling
examples/games (with code) on the Internet?

I thought about posting this message to the rec.games.programmer
newsgroup, but most of them are PC guys and I feel this is more of a Mac
hardware/speed/optimization problem.

Thanks in advance,

Jeff

 
 
 

1. Fast scrolling on macs


You should check out CopyBits ColorKarma by Brigham Stevens in Develop 17.
It's a pretty good example of scrolling the entire scroll with sound,
Palette Manager animation and control of the direction of scrolling.

2. Service Delivery Performance

3. Extremely fast, efficient scrolling

4. FAQ - index

5. Question on fast scrolling / animation of lines

6. Windows Default Font Settings??

7. fast scrolling wanted

8. simple Q reg. print filename

9. FAST scrolling of a window?

10. Fast scrolling in Window and How?

11. Fast scrolling a Bitmap with WinG

12. fast window-scrolling

13. How to add vertical scroll bar in dialog and make it scroll?