Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming > #6680
| From | Kaz Kylheku <545-066-4921@kylheku.com> |
|---|---|
| Newsgroups | comp.programming |
| Subject | Re: Mystified by an Atari 2600 demo. |
| Date | 2016-06-09 04:18 +0000 |
| Organization | Aioe.org NNTP Server |
| Message-ID | <20160608205214.290@kylheku.com> (permalink) |
| References | <23c1e131-543c-4654-85b0-f3876f484635@googlegroups.com> <20160608163636.316@kylheku.com> <91006f78-4144-44e6-bd24-196ac0a68750@googlegroups.com> |
On 2016-06-09, Chad <cdalten@gmail.com> wrote: > How can the hardware redraw the sprites if they aren't in video memory? Simply because the hardware can be designed to take inputs from sources other than the memory-mapped frame buffer (or character buffer) and combine them together to form the resulting image. Each pixel that you see is a function computed from some inputs. This function is calculated dynamically, in real time, as the pixel is clocked out to the video amplifier of the monitor. In parallel, the pieces of hardware can determine whether the pixel lies in the middle of one or more sprites, based on the pixel address and the configuration of the sprites (their position, their transparency mask and so on). If the pixel doesn't come from the sprites, then it can be pulled from video memory. That all happens in real time, as the video signal is generated. The sprite generation circuitry can evaluate the pixel coordinates against the sprite list in real time and report to the video signal generation circuitry that a sprite pixel should be generated instead of a pixel from video RAM. A more advanced sprite implementation could do some blending of partially transparent sprites: take the underlying pixel value from video memory as the background, and blend it with the pixel values of one or more overlaying transparent sprites to produce the final color value that goes out to the monitor. To get the gory details we would have to look at the exact schematics of a particular machine and its video implementation. We can move sprites around without copying any pixels. This is the basis for fast, cheap animation in sprite-based video games. Sprites can eliminate the need for double buffering, if the background is static. For instance, imagine Pac Man. There is a mostly static maze, except for some dots that get eaten. Pac Man and the ghosts can be sprites, which means we don't have to worry about the background at all when we move them around. At the vertical refresh cycle of each frame, we just adjust their coordinates, and they move to new locations as the next frame is drawn. We don't need any logic to restore the background that is revealed when a sprite is moved, or spend cycles on it. (Don't get me wrong; these old 8 bit micros had plenty of good, fast games that worked without sprites. Apple II boxes didn't have sprites; yet decent games. The games were quite complicated to develop without sprites though and a challenge to make performant. For instance, what about restoring the background when something moves? One trick is to take advantage of the fact that the piece only moves by a fixed number of pixels in each frame: say it never makes jump larger than four pixels. Then, whenever that shape is drawn, a four pixels of the background can be drawn around it. That takes care of restoring the background as the shape moves in a fixed way without any special erase logic. The moving magnifying glass in Bob Bishop's "Dung Beetles" is handled like this, I think, for example.) -- TXR Programming Lanuage: http://nongnu.org/txr Music DIY Mailing List: http://www.kylheku.com/diy ADA MP-1 Mailing List: http://www.kylheku.com/mp1
Back to comp.programming | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Mystified by an Atari 2600 demo. Chad <cdalten@gmail.com> - 2016-06-08 16:05 -0700
Re: Mystified by an Atari 2600 demo. Kaz Kylheku <545-066-4921@kylheku.com> - 2016-06-08 23:51 +0000
Re: Mystified by an Atari 2600 demo. Chad <cdalten@gmail.com> - 2016-06-08 19:10 -0700
Re: Mystified by an Atari 2600 demo. Kaz Kylheku <545-066-4921@kylheku.com> - 2016-06-09 04:18 +0000
Re: Mystified by an Atari 2600 demo. Kaz Kylheku <545-066-4921@kylheku.com> - 2016-06-09 00:01 +0000
Re: Mystified by an Atari 2600 demo. commodorejohn <commodorejohn@gmail.com> - 2016-06-09 09:47 -0700
Re: Mystified by an Atari 2600 demo. "J. Clarke" <j.clarke.873638@gmail.com> - 2016-06-10 20:41 -0400
Re: Mystified by an Atari 2600 demo. Daniel Pitts <usenet@coloraura.com> - 2016-06-11 12:47 -0700
Re: Mystified by an Atari 2600 demo. "J. Clarke" <j.clarke.873638@gmail.com> - 2016-06-12 00:00 -0400
Re: Mystified by an Atari 2600 demo. Daniel Pitts <usenet@coloraura.com> - 2016-06-12 21:08 -0700
Re: Mystified by an Atari 2600 demo. Randy Howard <rhoward.mx@EverybodyUsesIt.com> - 2016-06-13 04:12 -0500
csiph-web