🚀 go-pugleaf

This thread is being cross-posted to rec.games.programmer... if you're
going to talk about amiga-specific stuff, please either not cross-post
or attempt to make your articles more general: "The Amiga's blitter,
for example, can handle X sprites of width Y, etc."

Thanks.




In article <61@pdxgate.UUCP> griffith@eecs.cs.pdx.edu (Michael Griffith) writes:
>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. |


--
"Perhaps I'm commenting a bit cynically, but I think I'm qualified to."
                                              - Dan Bernstein