At 02:13 PM 4/20/00 +0200, you wrote:
think the C-64's able to put out better graphics than the Atari 8-bit's.
The background on the C=64 could output 16 colors at 320x200 whereas the
only 320x200 color mode on the 8-bits was only two shades of one hue per
scanline, called "1.5 colors".
I think the sprites on the C=64 were also at 320 pixel resolution, vs. the
160 resolution on the Atari.
But the color really bugs me. Only 16 shades on the C= tend towards games
that are really posterized and unbalanced, aesthetically, whereas you can
be more creative and artistic in picking colors on the Atari.
Which is also caused by the different sprite architecture. From what I know,
the Atari 8-bit's still have 8-pixel-wide "players" like the 2600. They have
double the amount of them, but that's it, they still need to be re-written
They don't need to be rewritten in software every scanline. ANTIC/GTIA
takes care of that. The 8-bit stores enough memory for an entire vertical
strip for each sprite, and an entire screen (or more) of framebuffer. It
also supports hardware scrolling of the background. Not sure about the
C=64. The C=64's graphics memory map was kinda weird. The Atari stores
graphics memory in a more conventional chunky pixel format. The options in
drawing to the screen with the Atari were numerous because of all of the
available graphics/text modes. The C=64 didn't have that kind of
variety. You could have part of the screen be text (for scores) and part
be a GTIA 16-shade mode, and part a 160x200/4 color mode, and so on. There
are all sorts of interesting effects that can be achieved through display
lists.
Look at the Atari 8-bits as a 2600 with more sprites, better resolution,
some better color (GTIA mode, 16 shades) and a chip that handles the kernel
with its display list rather than a software kernel.
The Atari clock is 1/2 NTSC colorburst instead of 1/3rd, so it's still
closely tied to TV timings, unlike the C=. So it's still possible to do
2600-like effects and get through to the hardware while the screen is being
drawn.
I haven't played them on the C=64, but games like Archon which rely on
having 8 shades of gray it can cycle through must look pretty lame on the C=64.
do that job for you, but if you want to move an object up and down, you
still have to re-write all of its data. But I'm not sure about this. Does
To move a sprite up and down you have to move the memory. It would have
been nice if there had been hardware support for this, but this can be done
very simply to all sprites without any slowdown. Even in Basic there are
ML subroutines that can do this.
Remember that there is a strip of memory representing the sprite. I think
the C=64 sprites have a physical length to them much smaller than the
entire screen. So you can paint more of the screen vertically with Atari
sprites. You can also reposition a sprite in mid screen similar to the
Atari 2600 to create vertically separated "pseudosprites". Not sure if you
can strobe out sprite clones. I don't think you can. Unlike the 2600,
horizontal sprite position is decimal-based, not polynomial based, and
requires no subroutine to calculate fine/coarse positions.
There's also a custom chip which reads in the registers for the sprites
itself, but it can also be done by the CPU (which, I think, no-one did on
the Amiga). Anyway, what's not possible there, unlike on the C-64, is to
share sprite data in memory among multiple objects, because the header of
the data also contains the positions the sprites should be displayed at. So
if you animate a sprite, on the Amiga you have to re-write it, and also if
you have multiple instances of the same object, they still need seperate
data chunks in memory with the respective locations inserted. This isn't
needed on the C-64, because there you can write the pattern and position
registers independently. But I'm slightly out of topic now...
The special hardware features of the Amiga are too numerous to list. Its
only real weakness over earlier systems was the lack of a high speed
hardware text mode. 16-color Ansi terminal software was dog slow on the
Amiga because it has to blit each character. Also, it was economical to
tie in the serial and parallel ports to the custom chips, but it also had
the net effect of slowing down serial port performance when the graphics
were really busy. Not something they were thinking about when high speed
modems were 2400 baud without compression.
Glenn Saunders - Producer - Cyberpunks Entertainment
Personal homepage: http://www.geocities.com/Hollywood/1698
Cyberpunks Entertainment: http://cyberpunks.uni.cc
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/