At 08:16 PM 9/6/2003, you wrote:
is funny, because while a supercharger multiload might give you effectively
more RAM and more ROM, I don't think anything ever gives you more time
for your kernal.)
The Supercharger can give you more time in your kernel by virtue of being
able to use strips of RAM to determine dynamically on a frame by frame
basis what to display. You just blit to these RAM locations inbetween
frames to move sprites vertically.
This mimics in a rudimentary way how the Atari 8-bit sprites are
represented as a strip of memory.
The whole skipdraw routine is only necessary because the sprite is
represented as a pointer to a ROM location and you need to determine on a
line by line basis when to start and stop drawing the sprite and which
frame of animation to display. All that takes a lot of CPU time. Even
when you have enough CPU time for this, you have to worry about when you do
your writes to the GRPx registers because it can limit where you can
position your players without running into tearing problems. The current
Death Derby kernel that Thomas cooked up has a lot of variable ways it
traces through itself depending on the game state in order to allow
glitch-free graphics across the full width of the screen.
With a strip of RAM all you are responsible for doing is indexing through
it. Sure, it wastes RAM on lines the sprites don't appear in, but it's
worth it.
You could use other strips of RAM to store other attributes of the sprite
as well, like a color strip or an HMMx strip or a width strip.
It should therefore be possible to write a game that fully maxes out what
you can do with the sprites on every line.
I really haven't studied any SC source code at all but I'd be surprised if
SC kernels weren't a lot simpler and easier to read than most other heavily
tricked-out ROM-only kernels.
Of course, all those RAM strips do add up and some SC games might want to
use that RAM for other purposes (since the RAM also stores the program and
the graphics) so maybe they aren't all using that technique...
One thing that's surprising me is that so far the best ball
movment algorithm has been the simple diaganols I have now...
one danger with that and this game is that it might be that
the ball tends to always go to the same rows...
I know Warlords gets kudos from most, but what I don't like about it is the
lack of possible angles. The total possible trajectories are too
limited. The arcade version expressed the ball as a rotating fireball,
which is why there is an arc to some of the trajectories. In Warlords this
is expressed in that weird polygonal trajectory when you let go of a ball
you've been holding onto. I never understood what that was supposed to be
until I first played Warlords in MAME... The predictability of the ball
patterns is what spoils Warlords for me. Only when all 4 human players are
going at once does the random factor kick up enough to save the game, but
for a 2-player outing it's too easy to anticipate where the ball is going
to go.
So the moral of that story would be, spend some time trying to make the
ball trajectories more varied. You do have to cheat a little because I've
also seen some pong games that allow the ball to get grazed by the paddle
in a way that it starts moving in a mostly vertical trajectory, almost 90'
with almost no horizontal speed. When this happens it takes FOREVER for
the ball to slowly zigzag its way across the screen. Since the paddle
can't push forward, it's really hard if not impossible to get that
horizontal momentum back. So you can't really have completely realistic
physics. If you were playing a game of real air-hockey you'd be able to
reach forward and hit the ball in a case like this, but because the paddles
are railed in Pong the game itself has to make sure the ball doesn't get
stuck in the middle of the screen. Actually, one way to compromise would
be to allow for realistic physics but have the game run a timer and if it
detects that the ball is in the unhittable middle zone for too long, bring
out the Pterry to knock it around.
Hrm. I'm not sure if I like that or not. I almost think
that rainbows are a bit of a cliche in atari programming
'cause they're so easy...
You have to play to the 2600's strengths. Plus, it does provide separation
between the bricks without having to have a blank line.
In Death Derby it could have been a garish rainbow background but I want to
keep the game more austere in honor of its black and white roots so it's
merely a white to black gradient on the tombstones and safe-zone borders.
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
