Re: [stella] Starmaster disassembled

Subject: Re: [stella] Starmaster disassembled
From: Manuel Polik <cybergoth@xxxxxxxx>
Date: Fri, 03 Aug 2001 01:22:12 +0200
Glenn Saunders schrieb:
> No, the original Star Raiders is for the 400/800 home computers.

Ah, ok. 
> You'd use the keypad.  There were plenty of unused buttons in 2600 Star
> Raiders.  You might not be able to have all 10 speeds ala the home computer
> version but you could have presets or an accelerate/decelerate button ala
> Wing Commander (+/-).

Hm... I'll have to try the trick within the MAME emulation again. I
think I played it all the the time without even changing the speed and
didn't really miss this feature. And I think droping the Joystick
mid-combat and heading for the right acceleration button might not
really add to the gameplay value :-)

I somehow seem to prefer old fashioned incoming waves...

More important for the real Star Fire feeling would be the Exidy
mothership I think and the target-lock-device (Which I fear will be hard
to realise - if possible at all)

> >Do you mean switching the view completely or doing a permant
> >rearview mirror?
> No rearview mirror, switching views back and forth so you'd need to maintain
> state to know which ships are where in the coordinate space and have a
> separate starfield kernel for converging stars (which I hear is trickier
> than the regular 3d star field).

Hm... I see... but this'd be a 'just candy' feature. The ability of
looking backward is of no real use, since an X-Wing can't fire backwards
But it's a cool idea really, I'll try to do that, if it's not too
resource consuming...
> >This I've planned definitely for Star Fire. I think a way better
> >scanner than the one of 'Defender' is doable.
> >I think the one from Battlezone was quite acceptable...
> The long range scanner in Star Raiders is a gyroscoping XYZ style display.

Oh... that I possibly won't do. I'll trick around that and will actually
have _no_ 3D calculations at all. What I'm planing to do is sort of
scrolling a 2-dimensional map around the ship, nevertheless giving you
the illusion of real depth via the starscrolling and zooming enemies...

> You should take a look at that game before you make any design decisions.

Definitely. I'm a real maniac coming to research. I played more than 40
game in western sceneries, from arcades to C64 games to NES games up to
Lucasarts Outlaws. Hehe, I even bought the 400 page 'Encyclopedia Of
Western Gunfighters' written by Bill O'Neal. (Did you know that Billy
The Kid has only 4 definitely confirmed kills (+another 5 *uncertain*)
and that he's ranking only #10 in the list of the most dangerous
Gunfighters? Jim Miller is ranking on top with 12 kills.)

And coming back to Starmaster, did you know that an 'Alan Miller' did a
C64 game called 'Law Of The West'? :-)

> Star Fire is a great action shooter, but SR defined strategic space
> simulation.

Yup. And that's why I think I'm not trying to top SR & Starmaster, but
Star Wars & Star Voyager instead :-)
> >Why - Oh Why - is flicker accepted everywhere in the classic
> >games, but not in mine...
> It depends on how busy the display is.  The 2600 has to fill a lot of the
> screen with a space game.  You've got the stars all over (which isn't easy
> given so few sprites on the system) and the enemies, enemy shots, and your
> shots, plus a crosshair.  It's hard to do that without flicker.  That's
> probably why Starmaster only has one enemy at a time and also why it uses
> lasers rather than photon torpedos.  I haven't looked at the sourcecode but
> I'm sure Starmaster uses the 1-bit objects
> as much as it possibly can.

IIRC it is like this: 

The ball makes the complete starfield with 8 stars.

The missiles do crosshair & laser. I'm not sure why the crosshair is
disappearing when the laser is fired, but I think the lasers actually
_are_ the crosshair, just shifted. I assume there's not enough time in
the kernel to enable/disable the missiles on two different locations.
(Or maybe this'd look even crappier than blanking the crosshair :-))

Both players make one enemy object, with doubled resolution. The Trick
that it can fire is simple: The shot is either completely above, below
or *over* the enemy ship, so there's never two objects colliding
(BTW: I think there's another example of a STA RESP0, STA RESP1 sequence
in the Staraster source, used to tie the two players together without
losing too much calculation time... (One player is shifted one pixel
again with hmove later))

I'll try to use a similar techinque for my Star Fire except that it'll
blow your brains out when you see the number of enemy shpis attacking
you _at once_! I won't tell you my idea for that right now, you'll have
to wait for my Tie-Fighters demo :-)

> >Hm... I must admit, that I've never thought about doing such a big
> >project before. In fact, I'm not too certain about what a bigger ROM size
> >would gain for the gameplay. Wouldn't for example the
> >'main action display' have to run completely in 4K anyways?
> I think it's possible to have a kernel that performs a bank switch in mid
> scanline, although that's probably not advisable.

Thanks to Chris who just revealed the secret of bank-switching to me in
the other mail, I see a bit clearer now.
> All the game state is stored in RAM.  You can output that game state in all
> sorts of ways through different banks.  You could have your fore and aft
> view kernels and the galactic map in all different banks if you wanted.

> RAM does become a limited factor, though, because we're talking about a lot
> of state information.  You have position and type information for the enemy
> ships and the starbases, your position, then all the local positioning
> information and your ship systems state.  I'm sure Phaser Patrol took full
> advantage of the Supercharger RAM for that.  It's too bad they couldn't
> figure out how to do a 3D starfield in that game...

Actually I'd now say, that the _real_ limit factor for the strategy is
nothing but cycles(!). You can possibly live with 128 bytes RAM. You can
make the game as big as you want in ROM - But(!) you only have this
little number of overscan and vblank cycles to do actually something
useful. According to the experiences of Bob Colbert one might triple or
even quadruple these cycles by clever differing overscan and vblank
routines, but in the end this is your limit factor I'd say. (I'm at the
moment not aware if any of the classic games uses this technique, the
only one I'm sure of at all is the yet to be finished multisprite game
from Bob...)


Archives (includes files) at
Unsub & more at

Current Thread