>No kidding. I thought the sprites were only 8 pixels
>wide. Where can I find info on the 6 digit score
>routine so I can see how it's done? Is it posted on
>The Dig? (Haven't looked there in a few months I'm
>afraid.)
Look in Okie Dokie's source, it's in there. I also posted something to
the effect of "6-digit score routine explained" sometime around April '97,
look that up in the archives if you want. The 6 digit score is three
clones of each of the two players, rewriting their graphics register
between each copy of each player. It does it with no cycles to spare.
>> Missile Command's missiles are one of the players,
>> cloned if necessary. Two sets of missiles are drawn
>> by flickering them on alternate frames.
>
>Do you mean the missiles you launch to intercept, or
>the ones descending towards the cities, or both?
Those are the incoming missiles. The missiles you launch and their
explosions are all drawn by the other player, flickering horribly - it
alternates between _three_ different sprites with one hardware object.
The cursor is the ball.
>I admit when I'm wrong, and you are absolutely
>correct. I just plugged Asteroids in and checked and,
>yes, indeed, it is just like you explained. I don't
>know why I didn't remember the flicker.
>
>So, if I can run with this ball, to draw the other
>asteroids in progressively smaller sizes, because it
>can clone the images but not change sizes, it draws
>the different sized asteroids on seperate frames,
>right?
Actually, I looked again...
>I think the asteroids only fly in two different speeds, and then there is
>an option for how diagonal the small ones fly. It's a pretty complicated
>kernel, I'm sure, because of how the sprites have to break off and fly
>around, which complicates things, which is why Asteroids is one of if not
>the first 8K game. I'm sure the flickering could have been minimized by
a
>more intelligent kernel, but it's still a good one as it is.
The Asteroids kernel is actually pretty straightforward but very clever.
Look at, say, only the downwards-moving asteroids. As the asteroids fly
around, notice that they all stay perfectly in their vertical sequences.
Sometimes they fly off diagonally, but notice that they always maintain
the same vertical speed. It's lots of reuse of one sprite, exactly the
way River Raid and Air-Sea Battle draw the sequence of objects.
Now, there's two sequences of asteroids like that, one moving upwards and
one moving downwards, which very convincingly creates the illusion of much
more freedom of movement.
All the asteroids - both sequences - are drawn on the same frame. Then on
the next frame, the player, his bullets, and the enemy saucer and bullets
are drawn. Load up PC Atari and slow it down to 4 frames per second and
you can see this clearly. (I think I'll give Millipede that treatment
later - I've definitely always wondered how that game drew more stuff than
an NES...)
Asteroids was of course the first 8k bankswitched game. Since it actually
has two display kernels - the asteroids and the player/bullets - it'd make
quite a bit of sense for each kernel to be in one of the banks. Anyone
disassembled it to look?
>sprites or flickered. You just couldn't move an individual sprite
>horizontally, they'd have to move as a group. If you wanted the illusion
>of the sprite moving into the other "lane" you'd have to shift the data
>over where part is written to sprite one and part to sprite one copy two,
>and so on.
>
>Most games run sprites along horizontal rails so that they can get two
>groups of sprites, 1, two, or 3 copies a piece, and slide them back and
>forth. Megamania and Oystron are good examples of that. Other games
>Journey Escape do regular sprite clones and then scroll those down. But
>rewriting the sprite shapes, you could then not only control the vertical
>position of the sprite, but all of its clones by simply deciding where
>when to write the other shapes into the other copies.
Soo... you get Journey Escape except the enemies don't have to line up
horizontally.
>Do any games use this sort of kernel??
The problem is the amount of manipulation you have to do to get all that
sprite data and write it into the right place. It'd take a ton of
indexing and lookups to get the right data at the right times for all the
sprites - probably too much if you're already rewriting that many graphics
per scanline (Remember the 6 digit score routine does it with 0 spare
cycles), and really makes it impossible to do any missiles or playfield.
On the Supercharger, one could write all the sprite data to RAM beforehand
and have the kernel just display it, but as you pointed out, you're just
into Suicide Mission by that point.
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
