Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming > #6680

Re: Mystified by an Atari 2600 demo.

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>

Show all headers | View raw


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


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