Xref: utzoo rec.games.programmer:2199 comp.sys.amiga.tech:14397
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!orc!inews!iwarp.intel.com!psueea!pdxgate!eecs!griffith
From: griffith@eecs.cs.pdx.edu (Michael Griffith)
Newsgroups: rec.games.programmer,comp.sys.amiga.tech
Subject: Re: Animation Speed & Redraw
Message-ID: <61@pdxgate.UUCP>
Date: 11 Sep 90 19:35:12 GMT
References: <4265@crash.cts.com> <T&B%'T@masalla.fulcrum.bt.co.uk>
Sender: news@pdxgate.UUCP
Lines: 52

S.J.Raybould@fulcrum.bt.co.uk (Simon Raybould) writes:

>In article <4265@crash.cts.com> uzun@pnet01.cts.com (Roger Uzun) writes:
>>between frames.  On a system like the amiga, this makes no sense, 
>>since hardware sprites can be reused and you get 128 pixels of 
>>sprite per scanline, and you DO NOT need to save the background

>WHAT ? I thought that the width of hardware sprites was restricted to 16
>pixels.

Well, with eight sprites you could make a combined width of 128 pixels. Also,
you can reuse sprites. However, when reusing sprites you need at least one
line of buffer if you are going to change its colors. Fortunately, sprites
can be as high as you like. I think the real problem hear is the four color
limitation. I mean, sure, you can combine sprites for more colors but then
you lose the width. Perhaps the following might work: Divide the sprites
into two groups of four using evens and odds, so that each group of four can
access the full 16 color registers that sprites can access. Combine these
on screen to form at 32 pixel wide area that can be moved faster than the
blitter. Make sure their priority is higher than the same data which is going
to go underneath. Then, without regards to scanline position, blit the data
from the sprites to the screen area underneath, while at the same time still
scrolling the screen right or left. The fact that you can blit at any time
should add some extra speed. Or perhaps, synch it to the raster but you won't
have to worry about the scan line catching up. All you have to do is beat
the vertical retrace. Then disable the sprites, move them to the new location
and point the sprite pointers to the new data. I'm still a bit confused
though. You see, it takes almost as much time to blit into the sprites
anyways. Hmmm. Okay, well if you limit the colors available to each layer
that is scrolling (I assume you are talking about scrolling as in Shadow of
the Beast) perhaps the key would lie in scrolling the sprites at different
rates, so that you could simulate the layers early on, before you had time
to actually set the screen data up. I don't know. Anyone from Psygnosis care
to tell us the full details? BTW: You might notice that in Shadow of the
Beast II, it appeared as though all of the moving characters were sprites,
but I don't think this was the case in Shadow of the Beast. Why the switch?
You could have had your cake and ate it too, so to speak. Of course the
characters might have been slightly slower but the scrolling could have been
as fast and as good as the first one. I just wonder why the switch? I must
say that Beast II suffered as a result. I mean, holes in the rocks, the
single bit-plane (with a custom copper list, apparently) background that
while underground was still showing mountains and cities in the distance. I
hate to say it, but Shadow of the Beast I was better. Just my $0.02. I think
the intro animation was nice, but did it affect the size of the game? I
would prefer an extra disk if that was the case. I'd rather pay for the
extra disk and get a great game. Well, sorry for rambling on and on... As
for paragraphs, well, who knows, maybe someday.


| Michael Griffith                     | If I had an opinion it certainly   |
| griffith@eecs.ee.pdx.edu             | wouldn't be the same one as        |
| ...!tektronix!psueea!eecs!griffith   | Portland State University anyways. |