Path: utzoo!utgpu!watmath!iuvax!mailrus!accuvax.nwu.edu!dehn!rico From: rico@dehn. (Rico Tudor) Newsgroups: comp.sys.amiga Subject: Re: 3000 wishes Message-ID: <1221@accuvax.nwu.edu> Date: 7 Oct 89 09:21:22 GMT References: <4875@cps3xx.UUCP> <125964@sun.Eng.Sun.COM> Reply-To: rico@cbmvax.commodore.com (Rico Tudor) Lines: 105 In article <125964@sun.Eng.Sun.COM> cmcmanis@sun.UUCP (Chuck McManis) writes: >In article <4875@cps3xx.UUCP> porkka@frith.UUCP (Joe Porkka) writes: >> Make sprites work in hires, and allow them to be as wide as a playfield; >> make them as deep (bitplane wise) too... make it so that you can have 32 >> indipendent sprites per scan line. > >I designed one hardware graphics systems, and helped with another that >was part of a multiperson group that was working on the Intel 82786. >Both had something similar to this, and both attacked the problem in >different ways. The difficulties that come up are similar though. > >Sprites and windows can be thought of as a memory management problem. One I commend Chuck McManis for his detailed and insightful article. Sprites, as provided by the Amiga, are inexpensive and useful, but have rigid limitations. TI's graphics processor implements sprites by providing two dedicated bitplanes. However, the most general design would eliminate the difference between sprites, windows and playfields, using all bitplanes as "data". This design is described below, and requires hardware for multiple bitplanes, a colormap, vertical and horizontal scrolling. Experts will notice that Ami already has most of these features. Step 1: Overlapping Objects --------------------------- Imagine there's two windows (it isn't hard to do): a little one in front of a big one on the screen. It might look like this: b b l l L b b L l L B B b b b Assume each window is one bit deep. Then the big window is colored 'B' and 'b'. The little window is colored 'L' and 'l'. Residing in VRAM are the complete images of each window, in separate bitplanes: b b b b b - - l l L b b B b b - - L l L '-' means don't care B B b b b - - - - - Another bitplane, the "mask plane" looks like this: 0 0 1 1 1 0 0 1 1 1 0 0 0 0 0 The idea is to load the colormap so that the pixel will be L/l where the mask is '1', and B/b otherwise. This boolean function is called "cookie-cutter" in some circles: colormap entry (base 2) pixel value to screen ----------------------- --------------------- 0lb b 0lB B 0Lb b 0LB B 1lb l 1lB l 1Lb L 1LB L This example used rectangular objects, but they can be oval, or any set of pixels, even disconnected. By adding bitplanes, any number of objects can be displayed: maskplanes = roundup( logbase2( objects)); totalplanes = maskplanes + objects*depth; Actually, objects need not have the same depth. Step 2: Moving an Object ------------------------ Applications in the previous example can draw into an object by changing bits in the VRAM image, without concern for other objects that might be obscuring the view: a luxurious programmer environment. This luxury is maintained when the object is moved by employing the scrolling hardware. Each bitplane has independent address pointers (BPLxPT), which step through ascending 16-bit words of VRAM. During vertical blanking, an object's address pointer can be set lower or higher in VRAM, shifting the object's position on the screen. The maskplane address pointer is also adjusted. This can deal with vertical scrolls of one scanline, but jumps horizontally in increments of 16 pixels (not acceptable for replacing sprites). Since the object's bitmaps are not copied in VRAM to effect the move, the user sees smooth motion for an object of any "size". Step 3: Scrolling an Object --------------------------- As all CLI users are aware, scrolling a large window is slow. This is because AmigaDOS is copying all the bits in the window. The action is even worst when small windows sit on top: the scrolling becomes jagged and irregular. Solution: don't copy the bits. How? Very much like Step 2, except easier. The object's bitplane address pointer is changed, but not the maskplane address pointer. I have glossed over a small matter involving maskplane updates when three or more objects exist. I have also not discussed the glaring problem of memory size and bandwidth implied by this design; I am confident that Chuck will not leave this as it stands. The problem with full-width sprites, desired by the original poster, lies in the demand for memory bandwidth, a resource in short supply on the Amiga. Such a sprite, if full-height, would use as many cycles as two low-res bitplanes. With four hi-res bitplanes enabled, there is sufficient bandwidth in each horizontal scantime for just one such sprite. My implementation of the Amix windowing system was so tight on memory cycles to chip ram, I was unable to use the video hardware as a cookie-cutter. Instead, the function was performed using a 3-source blitter op. I desire the following improvements in Amiga graphics. Firstly, bit alignment for video data fetch per address pointer (playfield scroll is insufficient). Secondly, more DMA bandwidth: a factor of ten would be okay. Thirdly, more bitplanes and larger colormap. And dump sprites.