Thread View: comp.sys.amiga.tech
7 messages
7 total messages
Started by Kevin Umbach
Thu, 06 Dec 1990 15:53
Animate vs Manual Blitter
Author: Kevin Umbach
Date: Thu, 06 Dec 1990 15:53
Date: Thu, 06 Dec 1990 15:53
14 lines
1089 bytes
1089 bytes
I'm writing a video game for the Amiga that has 6 small men (12 by 11 pixels, 2 planes) running around on the screen. I currently have them defined as animation objects and I'm using the Animate function to move them. Even though I'm only using a 320X200 2plane screen, the anim objects move very slowly. So here's my question: Is it faster to use blitter directly and keep track of all positional information manually, or do I have to be an expert programmer to get things moving faster than Animate? I currently have the program coded using Lattice C. Any hints and tips for speeding up animation would be greatly appreciated.
Re: Animate vs Manual Blitter
Author: Ken Farinsky - CATS
Date: Fri, 07 Dec 1990 16:08
Date: Fri, 07 Dec 1990 16:08
16 lines
1207 bytes
1207 bytes
In article <BZLRT1w163w@ersys.uucp> ersys!kumbach@nro.cs.athabascau.ca (Kevin Umbach) writes:
>I'm writing a video game for the Amiga that has 6 small men (12 by 11
>pixels, 2 planes) running around on the screen. I currently have them
>defined as animation objects and I'm using the Animate function to
>move them. Even though I'm only using a 320X200 2plane screen, the
>anim objects move very slowly.
Why don't you use sprites or vsprites? The objects are small enough,
and you are running on a lores screen, so sprites would work. They
should be a lot faster.
--
--
Ken Farinsky - CATS - (215) 431-9421 - Commodore Business Machines
uucp: ken@cbmvax.commodore.com or ...{uunet,rutgers}!cbmvax!ken
bix: kfarinsky
Re: Animate vs Manual Blitter
Author: Checkpoint Technologies
Date: Fri, 07 Dec 1990 17:06
Date: Fri, 07 Dec 1990 17:06
19 lines
1637 bytes
1637 bytes
In article <BZLRT1w163w@ersys.uucp> ersys!kumbach@nro.cs.athabascau.ca (Kevin Umbach) writes:
>I'm writing a video game for the Amiga that has 6 small men (12 by 11
>pixels, 2 planes) running around on the screen. I currently have them
>defined as animation objects and I'm using the Animate function to
>move them. Even though I'm only using a 320X200 2plane screen, the
>anim objects move very slowly.
It seems your objects are small enough, few enough, and shallow enough
that you could be using sprites. Is there some basic reason why you
aren't? If you switch from Bobs to VSprites, your code won't change
much, and you can get perfectly smooth and flicker-free animation
without double buffering. You will also be able to use different colors
for them than your playfield, though I don't know if that's an issue for
you.
--
First comes the logo: C H E C K P O I N T T E C H N O L O G I E S / /
\\ / /
Then, the disclaimer: All expressed opinions are, indeed, opinions. \ / o
Now for the witty part: I'm pink, therefore, I'm spam! \/
Re: Animate vs Manual Blitter
Author: Jean-Noel MOYNE
Date: Fri, 07 Dec 1990 23:40
Date: Fri, 07 Dec 1990 23:40
24 lines
1602 bytes
1602 bytes
If your objects can be only 8 points wide, and 3 colors
(you can use different colors from the backgroud), then go for sprites ...
You'll be able to animate 8 objects very quickly (and that means in sync
with the display, which is your goal for a game).
Otherwise, you can quite easilly boost the blitter's perfs
by programming it yourself. Remeber the graphics.lib routines where made
for general purposes, you can allways make a specific routine for your
needs, and it'll be a lot faster. The only problem is that the blitter is
not really easy to program by hand, and that you'll have to access it
relatively to _custombase (don't do it otherwise than this way), it's a
little dirty but if you need to modify it for a specific Amiga it can be
do easilly.
If you choose this solution, I strongly recomand you to get
the program blitlab (Radical Eye software, it's PD), and it's
documentation. Next buy some patience too (for the debuging) (-:
JNM
--
These are my own ideas (not LBL's)
" Just make it!", BO in 'BO knows Unix'
Re: Animate vs Manual Blitter
Author: Mike Farren
Date: Tue, 11 Dec 1990 12:27
Date: Tue, 11 Dec 1990 12:27
26 lines
1748 bytes
1748 bytes
ersys!kumbach@nro.cs.athabascau.ca (Kevin Umbach) writes: >I'm writing a video game for the Amiga that has 6 small men (12 by 11 >pixels, 2 planes) running around on the screen. I currently have them >defined as animation objects and I'm using the Animate function to >move them. Even though I'm only using a 320X200 2plane screen, the >anim objects move very slowly. > >So here's my question: > Is it faster to use blitter directly and keep track of all positional > information manually, or do I have to be an expert programmer to > get things moving faster than Animate? My experience with Animate, back when I was doing the port of Crystal Quest to the Amy, was that it was just too slow to do an arcade-game type movement for any significant number of objects (where significant == 3 or more). I whipped up a quick blitter routine in assembly which moved an object as desired (16 X 16 pixels), and it blazed - I could have nearly 50 objects moving around before a noticable speed degradation happened. Of course, I wasn't doing background saves or anything like that, but that would have been easy to add, and wouldn't have hurt the performance all THAT much - six men, 12 X 11, should be a piece of cake. Or, since you're only using 2 planes, how about setting 'em up as sprites, which would take essentially nothing in the way of resources? -- Mike Farren farren@well.sf.ca.us
Re: Animate vs Manual Blitter
Author: Pete Ashdown
Date: Wed, 12 Dec 1990 14:01
Date: Wed, 12 Dec 1990 14:01
18 lines
1347 bytes
1347 bytes
farren@well.sf.ca.us (Mike Farren) writes:
>I whipped up a quick blitter routine in assembly which
>moved an object as desired (16 X 16 pixels), and it blazed - I could
>have nearly 50 objects moving around before a noticable speed degradation
>happened. Of course, I wasn't doing background saves or anything like
>that, but that would have been easy to add, and wouldn't have hurt the
>performance all THAT much - six men, 12 X 11, should be a piece of cake.
Hey Mike, how about a post of that routine?
>Mike Farren farren@well.sf.ca.us
--
"While you are here, your wives and girlfriends are dating handsome American
movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."
-- Baghdad Betty
Pete Ashdown pashdown%javelin@dsd.es.com ...dsd.es.com!javelin!pashdown
Re: Animate vs Manual Blitter
Author: Mike Farren
Date: Wed, 19 Dec 1990 09:47
Date: Wed, 19 Dec 1990 09:47
335 lines
16986 bytes
16986 bytes
pashdown@javelin.es.com (Pete Ashdown) writes:
>farren@well.sf.ca.us (Mike Farren) writes:
>>I whipped up a quick blitter routine in assembly
>Hey Mike, how about a post of that routine?
Sure thing. Here you are:
; This routine draws an object directly to the bitplanes.
;
; The shape data is organized as one large block, for ease of loading via
; a standard "fread" statement. In this case, there are 73 shapes possible,
; and the shape number and location onscreen are passed to the drawshape
; routines.
; There are five arrays, plus the actual shape data. The first two arrays
; are held in the area pointed to by the "shape" pointer, and are
; a series of pointers to the shape and mask data, respectively. The
; next three are held in the area pointed to by the "shapeinfo" pointer,
; and are the width of the shape (in pixels), the height of the
; shape (in lines), and the modulo of the shape (the number of bytes per
; line - with this data being constrained to either two or three bytes).
;
; The shape data is simply the bit patterns of the shape, plane by plane.
; The mask data is used to "cookie-cut" the shape onto the screen, and
; is the bit pattern of the shape, with a set bit whenever the same
; bit in the final shape is not transparent. The first longword in
; the shape data is a length word, indicating the total length of the
; data area - this is for simplicity in loading.
; The basic coordinates are held in a Mac-like "rect" array, which holds
; four words: the leftmost x coordinate, the topmost y coordinate, the
; rightmost x coordinate, and the bottommost y coordinate. This arrangement
; makes it easy to compute collisons between rectangles.
LEFT EQU 0
TOP EQU 2
; The offsets into the big array are precomputed for ease of access
SHOFF EQU 0 ;The offset of the shape data pointers
MOFF EQU 292 ;The offset of the mask data pointers
HEIGHT EQU 584 ;The offset of the height values
WIDTH EQU 146 ;The offset of the width values
MODULO EQU 292 ;The offset of the modulo values
include 'types.i'
include 'custom.i'
include 'blit.i'
include 'dmabits.i'
CSECT data,1
; these are the externals. Mostly self-explanatory, except for "bp",
; which is an array of pointers to the individual bitplanes which make
; up the playfield. In this example, four planes are hardwired in.
XREF _Screen ; The screen structure (playfield)
XREF _custom ; To point to blitter
XREF _shapes ; The shape and mask data
XREF _bp ; a pointer to the bitplane pointers
XREF _shapeinfo ; The shape height, width, and modulo
; these are defined here for debugging purposes only.
XDEF fbltcon0
XDEF fbltcon1
XDEF fbltafwm
XDEF fbltalwm
XDEF fbltcpth
XDEF fbltcptl
XDEF fbltbpth
XDEF fbltbptl
XDEF fbltapth
XDEF fbltaptl
XDEF fbltdpth
XDEF fbltdptl
XDEF fbltsize
XDEF fbltcmod
XDEF fbltbmod
XDEF fbltamod
XDEF fbltdmod
; these are the blitter shadow registers. For some reason, direct writes
; to the blitter register did not work correctly, while indirect writes
; did not. I haven't the slightest idea why - but this works, at the
; cost of one additional set of accesses.
fbltcon0: DC.W 0
fbltcon1: DC.W 0
fbltafwm: DC.W 0
fbltalwm: DC.W 0
fbltcpth: DC.W 0
fbltcptl: DC.W 0
fbltbpth: DC.W 0
fbltbptl: DC.W 0
fbltapth: DC.W 0
fbltaptl: DC.W 0
fbltdpth: DC.W 0
fbltdptl: DC.W 0
fbltsize: DC.W 0
fbltcmod: DC.W 0
fbltbmod: DC.W 0
fbltamod: DC.W 0
fbltdmod: DC.W 0
CSECT text
; drawshape(number, where)
; short number;
; struct Rect *where;
;
; (using Lattice register parameter passing, number is passed in d0,
; the pointer to where in a0.)
;
; eraseshape(number, where)
; parameters as above.
XDEF _drawshape
XDEF _eraseshape
; outside routines used, using Lattice's bindings instead of "OVF" styles.
XREF _OwnBlitter
XREF _DisownBlitter
XREF _WaitBlit
_drawshape:
movem.l d2-d7/a2-a6,-(a7)
lea _custom,a5 ;point to the custom address
;Calculate the bitplane offset for this X,Y value - place into D2, with
;D3 the number of pixels offset from the word boundary
move (a0)+,d2 ;get the Y value
ext.l d2 ;make it a long
asl.l #3,d2 ;d2 = Y*8
move.l d2,d1 ;save it for now
asl.l #2,d2 ;d2 = Y*32
add.l d1,d2 ;d2 = Y*40
move (a0),d3 ;d3 = X
ext.l d3 ;make it long
move.l d3,d1 ;temp save x in d0
andi.l #15,d3 ;d3 = bit shift
ror.w #4,d3 ;move to high order nibble
asr.l #3,d1 ;d0 = words of x
andi #$fffffffe,d1 ;convert to word address
add.l d1,d2 ;d2 = y*40+x
;Extract addresses and dimensions from shapeinfo. Figure address ends up
;in A2, mask address in A3. Height in d4, modulo in d5. Setup some of
;the blitter shadow registers as appropriate.
ext.l d0 ;make the number a fake long
movea.l _shapeinfo,a0 ;point to the shape information
adda.l #4,a0 ;a0 points to shape data offset
movea.l a0,a4 ;save it here, too...
adda.l #HEIGHT,a4 ;a4 points to height data offset
asl.l #1,d0 ;times two (for WORD)
adda.l d0,a4 ;calculate height offset
asl.l #1,d0 ;calculate the offset for data
adda.l d0,a0 ;a0 points to figure data offset
movea.l _shapes,a2 ;get the shape data pointer
movea.l a2,a3 ;into both registers
adda.l (a0),a2 ;a2 now points to figure data
adda.l MOFF(a0),a3 ;a3 now points to mask data
move.w (a4),d4 ;d4 now has the height
move.w MODULO(a4),d6 ;and d6 the modulo
;Setup the blitter shadow registers. Most of these will not change
;from plane to plane, so can be set up now.
move.l a3,fbltbpth ;address of mask data in "B"
move.w #0,fbltamod ;no modulo for figure
move.w #0,fbltbmod ;or mask
move.l #-1,fbltafwm ;setup masks
move.l #$0fe20000,d0 ;save bltcons temporarily
or.l d3,d0 ;or in the "b" shift value
swap d3 ;swap words in shift
or.l d3,d0 ;"or" in the "a" shift value
move.l d0,fbltcon0 ;setup controller
move.w d4,d5 ;calculate the modulo for figure
cmpi.w #3,d6 ;if modulo == 3, setup differs
bne.s notthree ;
asl.w #1,d4 ;height * 4 words
asl.w #2,d5 ;d5 = height * 4
add.w d4,d5 ;d4 = height * 6
asl.w #5,d4 ;d4 = vertical size
or.w #3,d4 ;horizontal size = 3
move.w d4,fbltsize
move.w #34,fbltcmod ;34 byte modulo for this one
move.w #34,fbltdmod ;and this, too.
bra.s domod ;finish it off
notthree:
asl.w #6,d4 ;size = height * 64
asl.w #2,d5 ;size of this bit plane mod.
or.w #2,d4 ;or in the width
move.w d4,fbltsize ;and save it
move.w #36,fbltcmod ;36 byte modulo for screen
move.w #36,fbltdmod ;in both registers
domod:
;Setup the pointer to the bitplanes in a4, and the bitplane counter in
;d7.
ext.l d5 ;make sure d5 is long
lea _bp,a4 ;get pointer to first plane
moveq #4,d7 ;do four planes
PlaneLoop: movea.l (a4)+,a0 ;a0 = bitplane to do
adda.l d2,a0 ;add in offset to first word
move.l a2,fbltapth ;address of data in "A"
move.l a0,fbltcpth ;address of screen in "C"
move.l a0,fbltdpth ;and in "D"
jsr DoRealBlit
adda.l d5,a2 ;point to next line of shape
subq.w #1,d7 ;
bne PlaneLoop ;and the planes
movem.l (a7)+,d2-d7/a2-a6 ;restore registers
rts ;and return
_eraseshape:
movem.l d2-d7/a2-a6,-(a7)
lea _custom,a5 ;point to the custom address
;Calculate the bitplane offset for this X,Y value - place into D2, with
;D3 the number of pixels offset from the word boundary
move (a0)+,d2 ;get the Y value
ext.l d2 ;make it a word
asl.l #3,d2 ;d2 = Y*8
move.l d2,d1 ;save it for now
asl.l #2,d2 ;d2 = Y*32
add.l d1,d2 ;d2 = Y*40
move (a0),d3 ;d3 = X
ext.l d3 ;make it a word
move.l d3,d1 ;temp save x in d0
andi.l #15,d3 ;d3 = bit shift
ror.w #4,d3 ;move to high order nibble
asr.l #3,d1 ;d0 = words of x
andi #$fffffffe,d1 ;convert to word address
add.l d1,d2 ;d2 = y*40+x
;Extract addresses and dimensions from shapeinfo. Mask address ends up
;in A2, height in d4, modulo in d5. Setup some of the blitter shadow
;registers as appropriate.
ext.l d0 ;extend the pointer to a long
movea.l _shapeinfo,a0 ;point to the shape information
adda.l #4,a0 ;a0 points to shape data offset
movea.l a0,a4 ;save it here, too...
adda.l #HEIGHT,a4 ;a4 points to height data offset
asl.l #1,d0 ;times two (for WORD)
adda.l d0,a4 ;calculate height offset
asl.l #1,d0 ;calculate the offset for data
adda.l d0,a0 ;a0 points to figure data offset
movea.l _shapes,a3 ;get the shape data pointer
adda.l MOFF(a0),a3 ;a3 now points to mask data
move.w (a4),d4 ;d4 now has the height
move.w MODULO(a4),d6 ;and d6 the modulo
;Setup the blitter shadow registers. Most of these will not change
;from plane to plane, so can be set up now.
move.l a3,fbltapth ;address of mask data in "A"
move.w #0,fbltamod ;no modulo for figure
move.l #-1,fbltafwm ;setup masks
move.l #$0b0a0000,d0 ;save bltcons temporarily
swap d3 ;swap words in shift
or.l d3,d0 ;"or" in the "a" shift value
move.l d0,fbltcon0 ;setup controller
cmpi #3,d6 ;if modulo == 3, setup differs
bne.s notthreea ;
asl.w #1,d4 ;height * 4 words
asl.w #2,d5 ;d5 = height * 4
add.w d4,d5 ;d4 = height * 6
asl.w #5,d4 ;d4 = vertical size
or.w #3,d4 ;horizontal size = 3
move.w d4,fbltsize
move.w #34,fbltcmod ;34 byte modulo for this one
move.w #34,fbltdmod ;and this, too.
bra.s domoda ;finish it off
notthreea:
asl.w #6,d4 ;size = height * 64
or.w #2,d4 ;or in the width
move.w d4,fbltsize ;and save it
move.w #36,fbltcmod ;36 byte modulo for screen
move.w #36,fbltdmod ;in both registers
domoda:
;Setup the pointer to the bitplanes in a4, and the bitplane counter in
;d7.
ext.l d5 ;make sure d5 is long
lea _bp,a4 ;get pointer to first plane
moveq #4,d7 ;do four planes
PlaneLoopa: movea.l (a4)+,a0 ;a0 = bitplane to do
adda.l d2,a0 ;add in offset to first word
move.l a0,fbltcpth ;address of screen in "C"
move.l a0,fbltdpth ;and in "D"
jsr DoRealBlit
subq.w #1,d7 ;
bne PlaneLoopa ;and the planes
movem.l (a7)+,d2-d7/a2-a6 ;restore registers
rts ;and return
DoRealBlit:
jsr _OwnBlitter
jsr _WaitBlit
move #$8400,dmacon(a5) ;nasty blitter
move fbltcon0,bltcon0(a5)
move fbltcon1,bltcon1(a5)
move fbltafwm,bltafwm(a5)
move fbltalwm,bltalwm(a5)
move.l fbltcpth,bltcpt(a5)
move.l fbltbpth,bltbpt(a5)
move.l fbltapth,bltapt(a5)
move.l fbltdpth,bltdpt(a5)
move fbltcmod,bltcmod(a5)
move fbltbmod,bltbmod(a5)
move fbltamod,bltamod(a5)
move fbltdmod,bltdmod(a5)
move fbltsize,bltsize(a5)
w1: btst #DMAB_BLTDONE-8,dmaconr(a5) ;check it
bne.s w1 ;loop 'til done
jsr _DisownBlitter
rts
end
--
Mike Farren farren@well.sf.ca.us
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads