Re: [stella] bipolar joustpong

Subject: Re: [stella] bipolar joustpong
From: Glenn Saunders <mos6507@xxxxxxxxxxx>
Date: Sun, 07 Sep 2003 03:32:38 -0700
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 Unsub & more at

Current Thread