>> 1. Q*bert (red)
>> 2. Q*bert's enemy (purple or green, flickering if there are multiple
>> ones on one level)
>> 3. Cube body color
>> 4. Flying discs (white)
>> 5. Background (black)
>
>Q*bert and the enemy are obviously the two players. Cube body is
>playfield. The flying discs are the unknowns. If I remember correctly,
>they flicker (only one disc on each row is displayed per frame), so I
>guess we'd have to assume the discs are either missile or ball, and the
>color is changed immediately before or after display. (Notice the discs
>don't move vertically - they disappear and Q*Bert just floats up to the
>top by himself.)
No, the discs don't flicker, but change color - but that's not very
important.
>> On scanlines with the cubetops:
>>
>> 1. Legs of Q*bert (red)
>> 2.-4. the three possible colors for the cubetops
>> 5. Background (black)
>>
>> All this without flicker!
>>
>> I don't know if this is comparable with your efforts, but it's surely
>> remarkable. Wonder how they did that...?
>
>Elementary, my dear Watson. By rewriting COLUPF between cubetops. There
>is no other precisely timed effect on the scanline. All the kernel does
>is rewrite the player's graphics for Q*Bert's legs, then rewrites COLUPF
>every cube.
That's not quite true. On scanlines with one, three or five cubes, the
playfield isn't symmetric, so there have to be some playfield writes in
there, too. I suppose they use different kernal parts for each cube
level, that's twelve kernals in all, since the ones for cubetops and
cube bodies are also different. Anyone confirm?
>> And, in fact, Amidar uses three-color playfield, but it alternates
>> colors by scanline, not by frame.
>
>Well, if you're gonna think *that* way, then there's games like Chopper
>Command that have a thirty-colored playfield in the mountains :)
OK, so this doesn't seem to be an apprioriate example.
With love,
Kurt Woloch
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/stella.html
