I wanted to say two things about the ongoing discussions:
1. Some years ago, I also tried to record VCS games on a VCR. It did work on
most of them, but all lost color on playback. However, I didn't manage to
record Pole Position, which didn't get me a stable signal (all PAL versions,
here).
I also use my Amiga 500 to do Karaoke videos. In the mode I use, it also
generates non-interlaced display (50 fps), but it's no problem to record
this video signal (showing the lyrics you should sing) to VHS tape. Anyway,
not all VCR-TV combinations manage to playback these tapes without problems.
On one of our TV's (though I'm using the same VCR), the picture "jumps" up
and down sometimes, and on my cousin's VCR/TV combination (Philips), the
picture's not stable, though the TV displays a similar signal generated by
an AIWA XP-80G portable CD+G player flawlessly. On playing the tape back in
a Karaoke club once (where they had a rather worn-out VCR), the video showed
up, but the HI-Fi audio broke (!). Anyway, on the combination I normally use
(JVC HR-D960EG VCR, Amiga 1081 monitor, all PAL) it works fine.
2. About the single line resolution discussion: you totally ignored the
color stripes. Many newer games color-stripe some, or all objects, or the
background. This also uses additional cycles to re-write the color registers
and should be considered when judging if a sort of a Kernel is doable or
not. For instance, most Atari games only do solid-color sprites, while color
stripes are more common in Activision games.
Theoretically, on each scanline, you could have 5 objects (missiles,
players, ball), the playfield, and the 5 color registers, but it's
impossible to write to all of those registers in every scanline, so
constraints have to be made.
For instance, there are only few games displaying both players color-striped
on the same scanlines. Keystone Kapers does this, but I think the playfield
writes are restricted here, and at least the background color doesn't change
while the players are displayed. Also, this game doesn't use missiles at
this point.
I stumbled across this in my "Ship" demo two years ago. What would be
required here was three writes to playfield registers, one background and
one foreground color for the playfield, also the shapes and colors of the
players (I wanted to have to men be able to jump down next to each other)
which would have been four more registers, not considering that they should
be turned on and off too.
What I also discovered is that it's important how many "strings" of display
you have. This may sound new, but I'd consider a color-striped player as one
"string", since you can use the same index register to fetch the player data
and the color. The same holds true for a playfield which has three bytes per
line and two color bytes, but still is one "string", since it's all synched
to each other.
In my game, according to the initial concept, I would have had to use four
"strings" of index registers:
1. The sinking ship
2. The sky gradient (which should NOT be sinking)
3. and 4. The two possible men jumping next to each other.
I think game designers tried to use as few of those strings as possible to
keep the kernal possible. Most games only use three of such strings maximum.
Those who use more have flickering objects (which means not using all of
these strings in one frame) or at least not color-striped ones, or even
double or multiple scanline ones.
Some examples for this:
Keystone Kapers: three strings maximum:
1. Player
2. Enemies
3. Background
River Raid: Actually... two or three strings only:
1. Background AND enemies (they don't ever move up or down on the
background)
2. Plane AND its missile (which never is on the same scanline as the player)
Here, by the way, you have color-striped enemies, but a solid-color plane,
and maybe one of the playfield-color registers changes too, to display the
bridge.
Enduro: three strings
1. Road (probably done with the motion registers, like in Pole Position)
2. Enemy cars (they are always going all the same speed, never are more than
one in a scanline, and never pass each other)
3. Own car
And this game also doesn't use color stripes at all (except for the enemies
having different colors)
Q*bert: actually, only TWO strings:
1. Playfield AND enemies (the enemies don't move around freely, but rather
jump from cube to cube, so they're always in sync with the playfield)
2. Q*bert (moves around freely)
Also, Oystron, though being a double-scanline-game, only has TWO strings:
1. Own player
2. Asteroids and other enemies, crystals and the players shots (all are on
one line and in sync with each other, only the player moves freely up and
down)
Finally, this helicopter shooting game which was never completed, also has
only two strings:
1. Enemies (the author said he used only one player for this, so if more
objects are used, they flicker badly and are thus on different frames)
2. Player's gun AND aim (the aim doesn't really move up and down)
Even Pitfall II, which is said to be a very advanced game, only uses two or
three strings alternatingly:
1. Background
2. Enemies (including the balloon when Pitfall Harry isn't flying with it)
3. Pitfall Harry (with the balloon when he's got it)
And the enemies are either solid-shaded (like the bats) or, when they
aren't, they don't move independent to the background (up and down)... don't
know if the balloons move up and down, but I don't think so...
What do you think about those statistics? I think in view of this, the game
I wanted to do is probably impossible to do...
With love (and many strings to count)
Kurt Woloch
--
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
