🚀 go-pugleaf

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			   \|

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" |
+----------------------------------------------------------------------------+

>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!

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

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. |

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

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

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

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.          |
+---------------------------------------+-------------------------------------+

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.ed