djh@neuromancer.metaphor.com (Dallas J. Hodgson) (09/05/90)
You know, I've never seen this mentioned anywhere but the question is always in the back of my mind. If you're working on a real-time game that commonly has high numbers of animated objects moving around at all times (using a double-buffered screen) is it faster to clear out the undisplayed screen completely and redraw all the objects vs. restoring the background behind each object and then redrawing? There's a lot of overhead associated with clipping & storing the background behind every object just so it can be restored later. However, even with blitter assist clearing out 32-40K worth of video memory each frame is real-time significant. Not that I'm working on any games currently, but I've always wondered about this. How do you approach bitmap animation when speed is a prime consideration? Games like Datastorm are technological wonders in my book. +----------------------------------------------------------------------------+ | Dallas J. Hodgson | "This here's the wattle, | | Metaphor Computer Systems | It's the emblem of our land. | | Mountain View, Ca. | You can put it in a bottle, | | USENET : djh@metaphor.com | You can hold it in your hand." | +============================================================================+ | "The views I express are my own, and not necessarily those of my employer" | +----------------------------------------------------------------------------+
d6b@psuecl.bitnet (09/06/90)
In article <1401@metaphor.Metaphor.COM>, djh@neuromancer.metaphor.com (Dallas J. Hodgson) writes: > You know, I've never seen this mentioned anywhere but the question is always > in the back of my mind. If you're working on a real-time game that commonly > has high numbers of animated objects moving around at all times (using a > double-buffered screen) is it faster to clear out the undisplayed screen > completely and redraw all the objects vs. restoring the background behind > each object and then redrawing? > > There's a lot of overhead associated with clipping & storing the background > behind every object just so it can be restored later. However, even with > blitter assist clearing out 32-40K worth of video memory each frame is > real-time significant. Not that I'm working on any games currently, but I've > always wondered about this. How do you approach bitmap animation when speed > is a prime consideration? That is actually a very astute question. It isn't just a matter for game designers, either. If you're going to re-write the entire background each time, hardware scrolling becomes superfluous. In fact, although Menace, the first game from DMA Design, used hardware scrolling and saved/restored the spaces where the BOBs were to go, they switched to a software scroll in their next game (Blood Money). Sprites, of course, are a different matter... > Games like Datastorm are technological wonders in my book. I agree. In fact, Datastorm happens to be my favorite Amiga shoot-em-up game. -- Dan Babcock
uzun@pnet01.cts.com (Roger Uzun) (09/06/90)
I have written several commercial games on a variety of systems, and I really
have rarely found it desireable to maintain a 3rd "clean" bitmap around for
starting with a clean background. What you propose requires moving a clean
bitmap with no oibjects in it, into one of the displayable raster maps,
then simply drawing the objects on that clean background, then doing
all over again for the other bitmap after you switch views.
This requires more overhead in almost all instances than saving the
recangular background behind raster objects, the restoring it and redrawing.
I recall on old apple //e stuff, the 3 screen approach was sometimes used,
and I did use it for a while, double buffereing the display but
keeping a "clean" background around for wiping the slate clean
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
since they are not drawn into the raster in any case.
In other systems, the bitmaps are not too irregular (except maybe for
320X200X16 color EGA) and the processor can generally access rectangular
portions of the screen easily, so there is no need to copy the entire
background in each frame, the overhead to do this is generally MUCH
higher than it is to save/redraw many objects, whether they are large/medium
or small. But if the screen bitmap is arranged wierd enough (like the
old apple // or IBM EGA) it is may become worthwhile to just bus in a new
screen each time.
-Roger
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.comstephens@latcs1.oz.au (Philip J Stephens) (09/06/90)
Dallas J. Hodgson writes: > > If you're working on a real-time game that commonly > has high numbers of animated objects moving around at all times (using a > double-buffered screen) is it faster to clear out the undisplayed screen > completely and redraw all the objects vs. restoring the background behind > each object and then redrawing? If you are talking about having a background behind the animated objects, then you going to have to dump the background onto the entire area of the screen after clearing it. Hence if the sum of the areas of the foreground objects is less than the area of the screen, storing and restoring the background behind each object is probably going to be faster. You will have a little bit of overhead calculating the position of the areas to save, but this can be minimized by clever programming. One way to get faster animation is to devide the screen into a grid of identical squares, and then quickly dump shapes into those squares. This gives blindingly fast animation, but of course to animate across squares you need lots of pre-shifted shape tables. There are other considerations as well, but I won't bother you with the details (suffice to say it's the fastest technique I've come across so far). </\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\></\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\> < 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 > <\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/><\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/>
borgen@stud.cs.uit.no (Boerge Noest) (09/06/90)
In article <4265@crash.cts.com> uzun@pnet01.cts.com (Roger Uzun) writes: >I have written several commercial games on a variety of systems, and I really >have rarely found it desireable to maintain a 3rd "clean" bitmap around for >starting with a clean background. What you propose requires moving a clean >bitmap with no oibjects in it, into one of the displayable raster maps, >then simply drawing the objects on that clean background, then doing >all over again for the other bitmap after you switch views. >This requires more overhead in almost all instances than saving the >recangular background behind raster objects, the restoring it and redrawing. Is it just me, or is there actually a faster way: -Redraw all bobs for every new frame -Split the screen into chunks that fits the blitter nicely (16x16) -When you cut in a bob keep a list of which chunks are touched -When you need your new frame restore all touched chunks -Cut in your bobs once more Optimize this as much as you can. Wouldn't this work well? > >-Roger -- _____________________________________________________________________________ |/// borgen@stud.cs.uit.no (Borge Nost) \\\| |// ...and then there was AMIGA... \\| |/ studying at the worlds northernmost university \|
djh@neuromancer.metaphor.com (Dallas J. Hodgson) (09/07/90)
In article <4265@crash.cts.com> uzun@pnet01.cts.com (Roger Uzun) writes: >I have written several commercial games on a variety of systems, and I really >have rarely found it desireable to maintain a 3rd "clean" bitmap around for >starting with a clean background. What you propose requires moving a clean >bitmap with no oibjects in it, into one of the displayable raster maps, >then simply drawing the objects on that clean background, then doing >all over again for the other bitmap after you switch views. >This requires more overhead in almost all instances than saving the >recangular background behind raster objects, the restoring it and redrawing. > No need. What I was talking about in an earlier letter was displaying screen A, while clearing out screen B, rendering objects in B, then swapping. Games w/large backgrounds could replace the "clearing out" step with a "copy the background" step from a third (background) bitmap. No "clean" bitmap copies necessary. >I recall on old apple //e stuff, the 3 screen approach was sometimes used, >and I did use it for a while, double buffereing the display but >keeping a "clean" background around for wiping the slate clean >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 >since they are not drawn into the raster in any case. I think most developers have realized that hardware sprites are a headache. A decent 16-color x 32 pixel wide sprite image requires 4 sprites which can't be reused until the line after the bottom of the image. <other stuff about EGA/Apple-II deleted> So, let's hear it: you can blitter-zap a 320x200x4 screen 7,160,000 / (# words in screen * 4 cycles/word) = 111.875 times a second. If a blitter-copy is performed instead, you have 59.93 frames/second refresh. Theoretical maximums, but still plenty quick. There's high overhead in blitter register setup, and performing many cookie-cut background save/restore operations for each animated object sounds is much higher overhead than just blasting the bitmap. Of course, if there's only a few small objects, then it may not make much difference... So, let's hear from folks that have commercial products with high-speed refresh. How did you do it? +----------------------------------------------------------------------------+ | Dallas J. Hodgson | "This here's the wattle, | | Metaphor Computer Systems | It's the emblem of our land. | | Mountain View, Ca. | You can put it in a bottle, | | USENET : djh@metaphor.com | You can hold it in your hand." | +============================================================================+ | "The views I express are my own, and not necessarily those of my employer" | +----------------------------------------------------------------------------+
rogers@iris.ucdavis.edu (Brewski Rogers) (09/07/90)
>So, let's hear it: you can blitter-zap a 320x200x4 screen >7,160,000 / (# words in screen * 4 cycles/word) = 111.875 times a second. >If a blitter-copy is performed instead, you have 59.93 frames/second >refresh. Doesn't an A->D blitter copy take 4 cycles? This lets you have 112 frames/sec refresh and still have a nice background. You can still get bit shifting with an A->D copy, you just have to be a little more careful... ------------------------------------------------------ Quantum _\/_ 2727 Eel Bruce (6502 RULES!) Rogers |\ Duck ( 0 0) Davis, Ca 95616 Quantum Duck Software, |\ \______/ / \\\ 916-756-2684 rogers@iris.ucdavis.edu |\ < < | \/ Cinnamon, Rock Candy, or Sugar? decisions decisions. \_________/ Quark!
jdresser@altair.uucp (Jay Dresser) (09/07/90)
I can tell you from my experience that it is definately faster to erase each object than to erase the whole screen; blitter or not. The method I use has three screen buffers. Two for double buffering, and the third I call the "pristene screen". The pristene screen contains the background without any objects and is never written to. When I prepare the object to be blitted, I save some of the information (that pertaining to the rectangle that encompasses the object) in a structure for erasing (actually, 2 structures because of double buffering). Then when I erase, I simply copy the reactangle from the pristene screen to the rendering buffer. When I was given the task of speeding up Dark Castle/Atari, it was just this kind of change that brought it from 2 frames/sec to 15f/s, and that was using the CPU. It's a tradeoff of memory for speed. If you can afford the third buffer, this is the way to go. Jay Disclaimer: so, if I didn't have a disclaimer here, would anybody seriously think I was speaking for my company??? yeah, right!
uzun@pnet01.cts.com (Roger Uzun) (09/07/90)
>>Dallas Hodgson wrote: No need for a 3rd bitmap what I was referring to was >>display screen A while clearing out B, then drawing objects into B, >>if you have a large background then you can replace clearing out >>B with copying background into B. That is what a 3rd bitmap is used for! to be a "clean" copy of the background. Most modern games have very detailed backgrounds, and the method you proposed does call for a 3rd bitmap to be maintained, the 3rd bitmap is of a clean background, and is never displayed. Most all developers on the amiga, who develop for the amiga, make use of hardware sprites, they are hardly a headache at all, while not a complete solution, for most games they take much of the load off the processor blitter, 64 pixel width of 16 color object per scanline is not trivial, neither is 128 pixel width of 4 color object (well really 3 and 15 colors but..) The one scanline gap between objects is not a big problem in most cases since sprites can be ANY height. Blood Money uses mostly all sprites. Heart of the Dragon makes extensive use of sprites hardware. With the older agnus, I think you cannot blit a 320X200X4 bit screen is a single pass, but I forget for sure. I have never tried the blast out the background technique (using the 3rd off screen bitmap) on the amiga, but I have on the Apple //, Apple Macintosh II (8 bit video), and Atari computers. It was a total disaster on the Mac II, the processor could easily animate many rectangular objects with shadow masks for cookie-cutter like effects, and copying in the background each time just killed performance, you got like 8 frames/sec using the 3rd bitmap approach. Of course this was a 640X480X8 bit screen. Still in my experience with the Amiga, I do not feel that blitting in the entire background would be as fast, or even nearly so, as using sprites and/or raster objects with shadow masks. Maybe I will do a benchmark and see how it is, for now all I can say is my feeling is that the 3 bitmap approach will be slower. -Roger UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun ARPA: crash!pnet01!uzun@nosc.mil INET: uzun@pnet01.cts.com
peter@sugar.hackercorp.com (Peter da Silva) (09/08/90)
Has anyone else had a look at Steve B. Speier's "VASS" system? It gives you 16-color virtual sprites... -- Peter da Silva. `-_-' <peter@sugar.hackercorp.com>.
gilmore@vms.macc.wisc.edu (Neil Gilmore) (09/08/90)
Most games which I have programmed (on systems which had them) did not tend to use hardware sprites, as there was always too many objects moving around at once. Even using vsprites probably wouldn't work here. I never found scrolling to be a problem. The technique which I would use would scroll the buffered screen and redraw the animated portions with the knowledge that the scroll had taken place. Thus, all I had to do was scroll the screen, draw in those portions of the playfield which had become visible, and renew the animated objects. You can even use the same list of objects for each screen, as the positions, animation frame, etc. still differ by only 1 from the current list (after scroll), even though the positions differ by two from the position on the current drawing screen. +-----------------------------------------------------------------------+ | Kitakaze Tatsu Raito Neil Gilmore internet:gilmore@macc.wisc.edu | | Jararvellir, MACC, UW-Madison bitnet: gilmore@wiscmac3 | | Middle Kingdom Madison, Wi DoD #00000064 (no ints here) | +-----------------------------------------------------------------------+
buffa@sardaigne.inria.fr (Michel Buffa) (09/08/90)
In article <4275@crash.cts.com>, uzun@pnet01.cts.com (Roger Uzun) writes: > > Most all developers on the amiga, who develop for the amiga, make > use of hardware sprites FALSE. Look at most of the arcade games on the amiga. Each object is more than 4 colors (or even 16 in some of them). Only games like datastorm use hardware sprites. Battle squadron doesn't use sprites. Silkworm doesn't use sprites (The object are too numerous and too long to be sprites, Turrican doesn't use sprites: same method as the one used in blood money, see explanations later) > Blood Money uses mostly all sprites. FALSE ! I read a bunch of article in THE ONE (an english magasine), all written by the author of blood money, and he said that there was NO SPRITE at all in blood money. Only Blitter Objects. I recommend reading this magazine: it contains each month some technical articles written by an author of some famous games. During six months they gave almost the entire code of Menace, with full explanations. > With the older agnus, I think you cannot blit a 320X200X4 bit screen > is a single pass, but I forget for sure. Why do you want to do it in a single pass. The blitter is fast enough to do several operations during each vbl (60 times/second) in blood money, the following technique is used (read in the magazine) the scrolling uses both the blitter and the copper. The copper is used to scroll one line every 1/50s, and every 50/16s, the blitter is used to map only a row or a column, with 16x16 basic squares of background. Before pasting an object on the scroll, the followings steps are achieved: -restore previous portions of background (where the objects were in the previous frame) -calculate new positions of the objects, test collisions -save what will be behind the object you are going to paste in the current frame. (a special "save buffer" is associated to each object) -paste the new objects on the background Everything is done with the blitter and the copper (the copper avoids to redraw the full background evry frame, so the blitter is used only to animate the objects, and each 16 frames to map a row or a column in the scrolling background. >
xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) (09/08/90)
gilmore@vms.macc.wisc.edu (Neil Gilmore) writes: >Most games which I have programmed (on systems which had them) did not >tend to use hardware sprites, as there was always too many objects >moving around at once. Hmmm. Any reason not to use sprites for some stuff (bullets, missiles, power bolts, etc.) and blitter objects for others? From what I understand of sprites, doing as much as possible with them seems to be A Good Thing. [My experience with them is limited to AmigaBASIC, though; the less said about that, the better.] >Even using vsprites probably wouldn't work here. >I never found scrolling to be a problem. The technique which I would use >would scroll the buffered screen and redraw the animated portions with >the knowledge that the scroll had taken place. Thus, all I had to do was >scroll the screen, draw in those portions of the playfield which had >become visible, and renew the animated objects. You can even use the >same list of objects for each screen, as the positions, animation frame, >etc. still differ by only 1 from the current list (after scroll), even >though the positions differ by two from the position on the current >drawing screen. I guess I don't understand that. But anyway, fascinating discussion. I have a question, though. In the case (not Amiga specific), where a "pristine" background screen is being kept and the animation overlaid with rectangles from that to restore the background, and then redrawn in the new position, is it really so difficult to synchronize with the vertical trace that double buffering is needed, so you end up with THREE copies of the screen? That seems like a lot of overhead, if avoidable. You've cut the data you have to move by a third this way (overlay old animation with pristine background, draw new animation, versus overlay saved background rectangle, save new background rectangle, draw animation in new rectangle's space), doesn't that give you time to evade the scan line? More generally, do you find yourself always becoming performance bound before you become memory bound, so that this "triple buffering" is a good tradeoff of memory for speed? Kent, the man from xanth. <xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>
gilmore@vms.macc.wisc.edu (Neil Gilmore) (09/09/90)
In article <1990Sep8.081905.18030@zorch.SF-Bay.ORG>, xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes... >gilmore@vms.macc.wisc.edu (Neil Gilmore) writes: >>Most games which I have programmed (on systems which had them) did not >>tend to use hardware sprites, as there was always too many objects >>moving around at once. >Hmmm. Any reason not to use sprites for some stuff (bullets, >missiles, power bolts, etc.) and blitter objects for others? >From what I understand of sprites, doing as much as possible >with them seems to be A Good Thing. Yes, too many things moving around. There are only so many hardware sprites, and even if you multiplex them, there will be situations where you just can't put all them on the screen. >IF< your design can accomodate sprites, then yes, it is usually better to use them. But I won't sacrifice my design just to be able to use them. >>I never found scrolling to be a problem. The technique which I would use >>would scroll the buffered screen and redraw the animated portions with >>the knowledge that the scroll had taken place. Thus, all I had to do was >>scroll the screen, draw in those portions of the playfield which had >>become visible, and renew the animated objects. You can even use the >>same list of objects for each screen, as the positions, animation frame, >>etc. still differ by only 1 from the current list (after scroll), even >>though the positions differ by two from the position on the current >>drawing screen. (my scrolling example deleted) Think of it this way. There is an object currently displayed at 10,10 on the first screen. This object moves right at a speed of 2, while the screen scrolls downward with a speed of 1. Say that previous to this the position of the screen and object were static, so that both screens have the object at 10,10. Now, while the first screen is displayed, the second screen is scrolled down 1. When the object is displayed, the background is restored to 10,11 because of the scroll, then the object is drawn at 12,11 because of the movement. Now the screens are swapped so that the object is displayed at 13,11 using the second screen. The first screen is scrolled >2< down to be consistant, and the background restored to 10,12 because 2 frames have passed since this screen was drawn into. The object is drawn at 14,12, then the screens are swapped, etc. >More generally, do you find yourself always becoming >performance bound before you become memory bound, so that >this "triple buffering" is a good tradeoff of memory for >speed? It depends on the design of the game. For the sort of thigs I write, memory is always tight, because in strategy games there is so much information I'd like to store and use, and in animated games keeping several frames for each type of object is costly. But for animation, performance must be considered, becuase clunky games are no fun. +-----------------------------------------------------------------------+ | Kitakaze Tatsu Raito Neil Gilmore internet:gilmore@macc.wisc.edu | | Jararvellir, MACC, UW-Madison bitnet: gilmore@wiscmac3 | | Middle Kingdom Madison, Wi DoD #00000064 (no ints here) | +-----------------------------------------------------------------------+
S.J.Raybould@fulcrum.bt.co.uk (Simon Raybould) (09/10/90)
In article <1990Sep7.094337@sardaigne.inria.fr> buffa@mirsa.inria.fr writes: >FALSE ! I read a bunch of article in THE ONE (an english magasine), all >written by the author of blood money, and he said that there was NO SPRITE at >all in blood money. Only Blitter Objects. I recommend reading this magazine: >it contains each month some technical articles written by an author of some >famous games. During six months they gave almost the entire code of Menace, >with full explanations. The menace source code was actually in 'Amiga Format' not 'The One'. I have a subscription with Amiga Format and have all of the Menace source. Only the Source for the first level was released, there was no need for more, it shows animation, sound and end of level Guardian. For anyone who's interested, the series was titled 'The whole truth about games programing' and was written by Dave Jones. Cheers SJR
S.J.Raybould@fulcrum.bt.co.uk (Simon Raybould) (09/10/90)
In article <1990Sep7.094337@sardaigne.inria.fr> buffa@mirsa.inria.fr writes: >FALSE ! I read a bunch of article in THE ONE (an english magasine), all >written by the author of blood money, and he said that there was NO SPRITE at >all in blood money. Only Blitter Objects. I recommend reading this magazine: >it contains each month some technical articles written by an author of some >famous games. During six months they gave almost the entire code of Menace, >with full explanations. The menace source code was actually in 'Amiga Format' not 'The One'. I have a subscription with Amiga Format and have all of the Menace source. Only the Source for the first level was released, there was no need for more, it shows animation, sound and end of level Guardian. For anyone who's interested, the ceries was titled 'The whole truth about games programing' and was written by Dave Jones. Cheers SJR
uzun@pnet01.cts.com (Roger Uzun) (09/11/90)
Well, sprites cannot be used exclusively, but they can take a LOT of the
load off of the blitter/cpu, they can have up to 15 colors +
transparent and you 64 pixel width of 15 color sprite object per
scanline, and this can be used in almost ANY design, maybe you need
to supplement the display with raster objects as well, but they
(sprites) are valuable in speeding up/enchancing any game.
-Roger
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.comlphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/11/90)
In <T&B%'T@masalla.fulcrum.bt.co.uk>, 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. That's right. 16 pixels horizontal per sprite, 8 sprites per scan line; 128 pisels of sprite imagery. -larry -- It is not possible to both understand and appreciate Intel CPUs. -D.Wolfskill +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
S.J.Raybould@fulcrum.bt.co.uk (Simon Raybould) (09/11/90)
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. SJR
griffith@eecs.cs.pdx.edu (Michael Griffith) (09/12/90)
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. |
jcs@crash.cts.com (John Schultz) (09/12/90)
In article <T&B%'T@masalla.fulcrum.bt.co.uk> 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. 8x16 = 128. (8 sprites, 16 pixels wide). John
jcs@crash.cts.com (John Schultz) (09/12/90)
In article <T&B%'T@masalla.fulcrum.bt.co.ek> 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. 8x16 = 128. (8 sprites, 16 pixels wide). John
gl8f@astsun7.astro.Virginia.EDU (Greg Lindahl) (09/12/90)
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
uzun@pnet01.cts.com (Roger Uzun) (09/12/90)
You get 8 sprites/scanline each sprite is 128 pixels. If you have
large objects, just use more sprites side by side
-Roger
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.comifarqhar@mqccsunc.mqcc.mq.oz.au (Ian Farquhar) (09/12/90)
In article <61@pdxgate.UUCP> griffith@eecs.cs.pdx.edu (Michael Griffith) writes: >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 My sprite hardware is a little faulty (16th column is unstable), which reveals some very interesting facts about sprite usage. From looking at SotB I, I would say that the whole moving foreground, from side to side (ie. 320 + pixels) is one big sprite object, with (though this bit is only a guess) four sprites side by side being reused again and again in a scanline. I found this surprising. When I looked into this, I got the impression that the one scan line was only necessary to reload the header info. If you were using the copper to move the data directly into the registers, the maybe sprites can be reused on the same line. I haven't had the time to check this, but it sounds feasable... Comments, hardware hackers? I know that someone in Sydney did a demo called "Bones going home" which was a sendup of SotB, but I don't know his/her/its name to contact them and ask. If definately used the same system, as I got the same "bug" effect. -- Ian Farquhar Phone : 61 2 805-7420 Office of Computing Services Fax : 61 2 805-7433 Macquarie University NSW 2109 Also : 61 2 805-7205 Australia EMail : ifarqhar@macuni.mqcc.mq.oz.au
sasjaa@unx.sas.com (Jim Adams) (09/13/90)
In article <1410@metaphor.Metaphor.COM> djh@neuromancer.metaphor.com (Dallas J. Hodgson) writes: > ><other stuff about EGA/Apple-II deleted> > >So, let's hear it: you can blitter-zap a 320x200x4 screen >7,160,000 / (# words in screen * 4 cycles/word) = 111.875 times a second. >If a blitter-copy is performed instead, you have 59.93 frames/second >refresh. So, does anybody have and BITBLT code for the EGA that they would be willing to post? -- +---------------------------------------+-------------------------------------+ |James Adams | Death by any other name would | | ...!mcnc!rti!sas!sasjaa | be a character in a book. | +---------------------------------------+-------------------------------------+
aijpo@castle.ed.ac.uk (Joel Potter) (09/13/90)
In article <T&B%'T@masalla.fulcrum.bt.co.uk> S.J.Raybould@fulcrum.bt.co.uk (Simon Raybould) writes:
WHAT ? I thought that the width of hardware sprites was restricted to 16 pixels.
Each sprite is so limited in width, but you get eight of them.
--
"You *have* a TV licence?!??"
- Global Video Hire SalesPerson.
DarkAngel@uk.ac.edS.J.Raybould@fulcrum.bt.co.uk (Simon Raybould) (09/13/90)
In article <4344@crash.cts.com> uzun@pnet01.cts.com (Roger Uzun) writes: > >Well, sprites cannot be used exclusively, but they can take a LOT of the >load off of the blitter/cpu, they can have up to 15 colors + >transparent and you 64 pixel width of 15 color sprite object per >scanline How do you work this out ???? I was under the understanding that there are 8 Hardware sprites organised as follows: Sprite 0 and 1 Colour Reg 16,17,18,19 = 3 colours + tranparent Sprite 2 and 3 Colour Reg 20,21,22,23 = 3 colours + tranparent Sprite 4 and 5 Colour Reg 24,25,26,27 = 3 colours + tranparent Sprite 6 and 7 Colour Reg 28,29,30,31 = 3 colours + tranparent Total = 12 Colours + 4 transpaerents !! Each sprite has a maximum width of 16 pixels, unlimited height. Using all sprites this gives a maximum of 128 pixels wide. So I make the maximums to be a maximum of 12 colours and a maximum width of 128 pixels per scan line. If any of this info is wrong please let me know as I would like to be clear on this. Cheers SJR +-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-+ | British Telecom Fulcrum | name : Simon John Raybould {^.^} | | Fordrough Lane | path : sie@fulcrum.bt.co.uk \~/ | | Birmingham +-----------+--------------------------| | B9 5LD | // | AMIGA B2000HD 3MB 8088BB | | ENGLAND | \X/AMIGA | Lattice C V5.05 | +-=-=-=-=-=-=-=-=-=-=-=-=-=-=+=-=-=-=-=-=+=-=-=-=-=-=-=-=-=-=-=-=-=-+
peck@ral.rpi.edu (Joseph Peck) (09/14/90)
In article <3AC%%9#@masalla.fulcrum.bt.co.uk> S.J.Raybould@fulcrum.bt.co.uk (Simon Raybould) writes: >In article <4344@crash.cts.com> uzun@pnet01.cts.com (Roger Uzun) writes: >> >>Well, sprites cannot be used exclusively, but they can take a LOT of the >>load off of the blitter/cpu, they can have up to 15 colors + >>transparent and you 64 pixel width of 15 color sprite object per >>scanline > >How do you work this out ???? > >I was under the understanding that there are 8 Hardware sprites organised as >follows: > > Sprite 0 and 1 Colour Reg 16,17,18,19 = 3 colours + tranparent > Sprite 2 and 3 Colour Reg 20,21,22,23 = 3 colours + tranparent > Sprite 4 and 5 Colour Reg 24,25,26,27 = 3 colours + tranparent > Sprite 6 and 7 Colour Reg 28,29,30,31 = 3 colours + tranparent > Total = 12 Colours + 4 transpaerents !! > True so far, but sprite pairs can be "attached". In an attached pair, you have a total of four bitplanes (two from each sprite) which correspond to color (American spelling :) registers 16 - 31. Note that there is only four acceptable sprite pairs: 0-1, 2-3, 4-5, 6-7. This way you can have 4 sprites with 15 colors for a total width of 4*16 = 64 pixels. >Cheers > >SJR > I had to figure out how to attach sprites for a game that I am writing. So, in response to a different thread, YES! real games use hardware sprites! (At least I hope that mine becomes "real" :) Have fun, Joe Peck peck@ral.rpi.edu
uzun@pnet01.cts.com (Roger Uzun) (09/14/90)
Amiga sprites can be attached together, 0 and 1, 2 and 3, 4 and 5, 6 and 7,
all pair with each other and the pair ALWAYS uses registers 16-31.
So you get 64 pixel width/scanline of 15 color (+transparent) object.
It takes a BIG load off the blitter/cpu combo.
-Roger
UUCP: {hplabs!hp-sdd ucsd nosc}!crash!pnet01!uzun
ARPA: crash!pnet01!uzun@nosc.mil
INET: uzun@pnet01.cts.combarnettj@pookie.crd.ge.com (Janet A Barnett) (09/20/90)
I'll add my extra bit of misinformation here: You can only get 15 colors with attached sprites if the sprites in a particular pair lie on top of each other. Therefore, with 4 pairs of sprites, the maximum 15 color sprite can be only 64 pixels wide. Of course, a sprite pair does not have to completely overlap, but only the overlapping portions will be in 15 color mode; the unoverlapped (sp?) portions will display the 3 colors that the pair usually display. Now, here's the interesting part. If you read the Hardware manual closely, you will see that the sprite data registers can be reloaded by the COPPER or the CPU at any time. This can allow you to have sprites of almost arbitrary width, at the cost of reloading the sprite registers manually during the course of the screen display. The only limitation is that there have to be sufficient CPU cycles available during display time to load the sprite data registers. For instance, it won't work on a 16 color HIRES screen. This is an interesting hack to try with user copperlists, and the relatively unused COPPER SKIP instruction.