Animation

Animation

Post by Todd P. Whites » Thu, 18 Apr 1991 18:54:36




[ stuff deleted ]

Quote:>       My question is, is my basic ideas/techniquie correct? Am I using
>the wrong method for fast shape manipulation. OR am I using the correct
>method and I should just try to improve upon my code and optimise where
>I can?

Your method is reasonable, but the time-wasters are pretty obvious. Read on.

Quote:>      For simplicity I only let shapes move by 2 pixels so that they
>always fall on a byte boundary. Also, I am usin the 320x200 resolution.

Time-waster #1: loops. If you are looping through the picture data and the
mask then you are spending a non-trivial amount of time in the loop overhead.
Unrolling consists of coding a long string of instructions with the offsets
hardcoded as the addresses; the index register(s) are used to hold the low
word of the data address. You can do truly evil things this way if you map
the SHR buffer to the stack (better disable interrupts temporarily though!):

        lda     0,x     ;dp points to object location on screen
        and     |0,y    ;DBR/Y points to mask
        ora     |$1000,y        ;suppose the image is 4K past the mask
        sta     0,x
        lda     1,x
        and     |0,y
        ora     |$1000,y
        sta     1,x
        ...

Note that the above example does assume the mask and image start at a fixed
distance from each other. It is a speed vs. memory tradeoff.

Time-waster #2: rectangular objects. Depending on the types of objects you want
to animate, it may actually help to pack the image and its mask so that dead
space in the object rectangle is replaced by offset/length values for each
line of the object. This is almost always a win.

Time-waster #3: the mask itself. If you can afford to let the mask be per
byte and not per pixel, you can get even more speed but at real memory
expense -- you hardcompile each object into code that draws it by simply
storing it (using the index w/ hardcoded offset technique from above).
If you want EVEN MORE speed you can use the stack to push bytes directly
onto the picture (this looks sick but is actually pretty easy to do once
you know what's involved). What's cool about stack-romping is that you
can push arbitrary words with PEA's, repeat values and one-byte values
with pha/phx/phy, and skip bytes with a sbc #xxxx; tcs; sequence (if you
let A accumulate the hops that is -- a simple way to do this would be to
pass the location of the object as the byte address of its last byte, so
the object draw code can start with a tcs). The major drawback here is
that you have hardcompiled code PER OBJECT -- I haven't tried to do this
yet but I suspect that the code is about as large as the image & mask data
so you are losing a bit of mask resolution but not much else.

Time-waster #4: the shadowing itself. If you are going to be drawing over
objects a lot then you should turn off shadowing while you are drawing the
scene and then turn it back on and do a single romp copy of the bank 1 SHR
buffer onto itself -- this can be done by remapping memory, the stack & dp,
and issuing a series of
        pei $fe
        pei $fc
        ...
        pei $2
        pei $0
and hopping the dp register after each page.

I am not positive but I strongly suspect that both #3 and #4 are used by
the FTA Space Harrier demo.

Todd Whitesel

 
 
 

Animation

Post by Shane Kelvin Richar » Thu, 18 Apr 1991 15:10:57


        Hello. I am hoping someone can help me. I am developing a set of
animation routines for the //GS. So far its okay, BUT things are becoming
a tad slow when many objects are on the screen. Heres how I am doing it..

        If I want to put a shape on the screen, I go through a loop pulling
off each background byte (that the shape will be using) anding it with the
shapes mask (using a mask makes it really easy to have "see-through" holes
in the shapes and so that the background moves around the shape if the
background and shape happen to fall in the same byte) then I ora the shape
byte and place this calculated byte back on the screening (and yes I am
using the shadow screen in bank $01 for faster reads). So this is the
basic process. It slows down quite considerably but I can't think of any
other way of doing what  am trying to do. This is the place the shape
down on top of the background nicely (so that it doesn't get jaggies if
I had for instance just Stored the shape directly on the screen.

       My question is, is my basic ideas/techniquie correct? Am I using
the wrong method for fast shape manipulation. OR am I using the correct
method and I should just try to improve upon my code and optimise where
I can?

      For simplicity I only let shapes move by 2 pixels so that they
always fall on a byte boundary. Also, I am usin the 320x200 resolution.

        Any ideas, what other techniques are there?

--
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Shane Richards

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

 
 
 

Animation

Post by timothy lee meeki » Thu, 18 Apr 1991 22:10:35



Quote:

>    Hello. I am hoping someone can help me. I am developing a set of
>animation routines for the //GS. So far its okay, BUT things are becoming
>a tad slow when many objects are on the screen. Heres how I am doing it..

>    If I want to put a shape on the screen, I go through a loop pulling
>off each background byte (that the shape will be using) anding it with the
>shapes mask (using a mask makes it really easy to have "see-through" holes
>in the shapes and so that the background moves around the shape if the
>background and shape happen to fall in the same byte) then I ora the shape
>byte and place this calculated byte back on the screening (and yes I am
>using the shadow screen in bank $01 for faster reads). So this is the
>basic process. It slows down quite considerably but I can't think of any
>other way of doing what  am trying to do. This is the place the shape
>down on top of the background nicely (so that it doesn't get jaggies if
>I had for instance just Stored the shape directly on the screen.

>       My question is, is my basic ideas/techniquie correct? Am I using
>the wrong method for fast shape manipulation. OR am I using the correct
>method and I should just try to improve upon my code and optimise where
>I can?

>      For simplicity I only let shapes move by 2 pixels so that they
>always fall on a byte boundary. Also, I am usin the 320x200 resolution.

>    Any ideas, what other techniques are there?

If all your shapes are the same size, then try unrolling all your loops
in the shape drawing functions. Something like:

;
; On entry, X points to shape, Y points to screen
; Assume shape (for this example) is 8 bytes by 8 pixels.
;
DrawShape       phb             ;Set to bank 1
                pea     $0101
                plb
                plb

                lda     $2000+0*160+0,y
                and     >masktbl+0*8+0,x
                ora     >shapetbl+0*8+0,x
                sta     $2000+0*160+0,y

                lda     $2000+0*160+2,y
                and     >masktbl+0*8+2,x
                ora     >shapetbl+0*8+2,x
                sta     $2000+0*160+2,y

                ...

                lda     $2000+6*160+6,y
                and     >masktbl+6*8+6,x
                ora     >shapetbl+6*8+6,x
                sta     $2000+6*160+6,y

                plb
                rts

It will take slightly more memory, but the speedup will be very noticable.

If you don't re-map the bank, and use long address for the screen instead,
you'll have to interchange the functions of the X & Y registers.

>--
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>Shane Richards

>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

--
+---------------------------S-U-P-P-O-R-T-----------------------------------+
|/ Tim Meekins                  <<>> Snail Mail:           <<>>  Apple II  \|


 
 
 

Animation

Post by timothy lee meeki » Thu, 18 Apr 1991 22:16:00



Quote:>;
>; On entry, X points to shape, Y points to screen
>; Assume shape (for this example) is 8 bytes by 8 pixels.
>;

whoops! That should have read 8 bytes wide, 8 SCANLINEs high.

--
+---------------------------S-U-P-P-O-R-T-----------------------------------+
|/ Tim Meekins                  <<>> Snail Mail:           <<>>  Apple II  \|


 
 
 

Animation

Post by Philip J Stephe » Tue, 23 Apr 1991 16:08:09


Quote:Shane Kelvin Richards writes:

>    If I want to put a shape on the screen, I go through a loop pulling
>off each background byte...anding it with the shapes mask...then I ora the
>shape byte and place this calculated byte back on the screen.

  The technique is correct; it's just the implementation that might be
slowing you down.  That is, if you're using indirect indexing to
load and store bytes to and from the screen, you may wish to change
this to absolute indexing and self-modify the base address for each
new row.  The same applies if you're using indirect indexing for
accessing the shape tables.  Self-modifying the code is always faster
when dealing with large amounts of data.
  Also, use a table of row and shape addresses to get the new base from
rather than using some form of computation.  That should shave off a
few more cycles per row.
  If you're really stuck, I could e-mail you an example of a faster
routine for you.  

<\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/><\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\>
<  Philip J. Stephens                ><   "Many views yield the truth."       >
<  Hons. student, Computer Science   ><   "Therefore, be not alone."          >
<  La Trobe University, Melbourne    ><   - Prime Song of the viggies, from   >
<  AUSTRALIA                         ><   THE ENGIMA SCORE by Sheri S Tepper  >
</\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\></\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/>

 
 
 

Animation

Post by John MacLe » Sat, 27 Apr 1991 14:40:27



>    Hello. I am hoping someone can help me. I am developing a set of
>animation routines for the //GS. So far its okay, BUT things are becoming
>a tad slow when many objects are on the screen. Heres how I am doing it..
> [LDA / AND / ORA / STA instruction sequence deleted]
>       My question is, is my basic ideas/techniquie correct? Am I using
>the wrong method for fast shape manipulation. OR am I using the correct
>method and I should just try to improve upon my code and optimise where
>I can?
>      For simplicity I only let shapes move by 2 pixels so that they
>always fall on a byte boundary. Also, I am usin the 320x200 resolution.
>    Any ideas, what other techniques are there?
>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
>Shane Richards

>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

At this level there is nothing wrong with the technique you are using.
One thing you can do is use the //ec softswitches, and to move zero page
up to the super hires screen.
Of course, this can be a bit * if your using GS/OS / interrupts / etc.
Make sure you're using the most optimal addressing modes, you have
the data bank set to bank 1 etc, etc.

It is also a good idea to base your animation on VBL interrups / so that
your code does not slow down as you add more and more shapes - just set
a limit that has acceptable speed, and update every 3,4,5 VBLs -
whatever seems reasonable.

John MacLean.
--

That net: uunet!fawlty.towers.oz!johnmac                Fax:   +61 2 427 7072
Snail:    Tower Technology, Unit D 31-33 Sirius Rd,     Home:  +61 2 960 1453
          Lane Cove, NSW 2066, Australia.