Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!apple!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!uvaarpa!murdoch!astsun7.astro.Virginia.EDU!gl8f From: gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) Newsgroups: comp.sys.amiga.tech Subject: Re: Animation Speed & Redraw Message-ID: <1990Sep11.220430.5202@murdoch.acc.Virginia.EDU> Date: 11 Sep 90 22:04:30 GMT References: <4265@crash.cts.com> <61@pdxgate.UUCP> Sender: news@murdoch.acc.Virginia.EDU Followup-To: poster Organization: Department of Astronomy, University of Virginia Lines: 68 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