Star Raiders Source Code to be released?

[phaeron]

There is just enough space reserved on page 0 for two of the tables such as XPOSH, XPOSL, or XSIGN.

XPOSH and XSIGN are accessed the most so that has the potential to offer the largest speedup for the least work.

 

Keep in mind that while zero page indexed addressing is shorter, it is no faster than absolute indexed for load or read/modify instructions that don't cross a page. They're both 4 cycles.

 

Profile of cruising in space attached. The profiler is showing a huge amount of time being spent in a division routine, about half of the CPU. ~10% is spent waiting for vsync.

[JamesD]

Yup, you are right. Same number of clock cycles. I thought it was 1 less.

All it can do is save space to fit more code on an 8K cart.
I could still move a few things to page zero but it's not that much savings.

The only time the code isn't fast enough visually is explosions and I was hoping to cut enough clock cycles to eliminate that issue without cutting the explosion, which may not even be possible without a major rewrite. Cutting a few regular stars and part of the explosion could be enough. That's defined somewhere in the line 450 range with STRNUM and EXPNUM.
The stars are too close anyway so cutting a few of those shouldn't be a big deal, but the real issue is once there is an explosion which adds 32 stars.
While rather spectacular that's a lot of calculations. Reducing those numbers was actually the first thing I tried and cutting both by 1/3 seems to help a lot during the explosions. I attached that version below.

 

 

The divide is large compared to what you'll find on the internet at a glance, but the first section is setup for looking forward or looking back.

Then it has to check if the divisor is larger than the dividend (overflow) and multiply by 80 at the end which is a table lookup.
There may be some clock cycles to be saved, for example overflow could be detected right away (if the divisor is larger it's overflow) but I'd need to look at the impact of that change.

At the very least, the loop could be unrolled with a 16K cart.
Some sort of table lookup is the only way that would be significantly faster all the time and that's probably a rewrite of a lot of code.

The main reason I was looking at the code was to see how tough it would be to port.

StarRaiders.bin

Edited October 20, 2015 by JamesD

[Rybags]

I reckon more stars = better. More explosion particles = better.

Fairly sure there's already a hack out there that reduces particle count to make explostions less lag inducing.

 

I also reckon forget 8K Rom, 8K Ram. 16K Rom straight up means nice big lookup tables if needed, a couple of custom fonts, ability to add graphical detail e.g. internal details of our spacecraft.

 

Porting - I've also had that thought. It would likely be very appreciated on the likes of C64 & Plus4 though it does sort of become a bit sacrilegious.

[playermissile]

The divide is large compared to what you'll find on the internet at a glance, but the first section is setup for looking forward or looking back.

Then it has to check if the divisor is larger than the dividend (overflow) and multiply by 80 at the end which is a table lookup.

There may be some clock cycles to be saved, for example overflow could be detected right away (if the divisor is larger it's overflow) but I'd need to look at the impact of that change.

At the very least, the loop could be unrolled with a 16K cart.

Some sort of table lookup is the only way that would be significantly faster all the time and that's probably a rewrite of a lot of code.

 

Here's my work on speeding up the explosions. This was written before the source was available, so I haven't revisited it although I intend to:

 

http://playermissile.com/tech/starraiders/index.html

 

Upping the RAM usage to 48k, the best way to speed up the division is to have logarithm/exponentiation tables. I haven't had time to implement anything, but the source code availability has gotten me interested again.

 

Rob

[playermissile]

Thanks to JamesD's work, I've updated my github to use his CA65 cleanup of the source code instead of the reverse engineered disassembly. There's a makefile that generates an XEX file rather than a cart image with the idea that I'll be expanding the source to include the log/exp tables and don't need to stick with 8k.

 

https://github.com/robmcmullen/Atari8bit_StarRaiders

[JamesD]

I reckon more stars = better. More explosion particles = better.

Fairly sure there's already a hack out there that reduces particle count to make explostions less lag inducing.

 

I also reckon forget 8K Rom, 8K Ram. 16K Rom straight up means nice big lookup tables if needed, a couple of custom fonts, ability to add graphical detail e.g. internal details of our spacecraft.

 

Porting - I've also had that thought. It would likely be very appreciated on the likes of C64 & Plus4 though it does sort of become a bit sacrilegious.

Well, I think it's going to be a matter of how many stars/particles work with the tables.

I knew there was a hack but just added that for a test.

At 8 stars instead of 12 and 21 explosion particles instead of 32 it's right near the limit with the current code.

There's a slight lag but not as much as before and the explosion still looks pretty good.

With the table lookup I think the original numbers should work or close to it.

There's definitely no point in sticking to the RAM or ROM limit.

 

[JamesD]

I played the version with reduced stars/particles again and the lag is still a bit much with particles down to 17.

[fujidude]

I reckon more stars = better. More explosion particles = better.

Fairly sure there's already a hack out there that reduces particle count to make explostions less lag inducing.

 

I also reckon forget 8K Rom, 8K Ram. 16K Rom straight up means nice big lookup tables if needed, a couple of custom fonts, ability to add graphical detail e.g. internal details of our spacecraft.

 

Porting - I've also had that thought. It would likely be very appreciated on the likes of C64 & Plus4 though it does sort of become a bit sacrilegious.

 

Agreed. There's no imperative today to stay within the confines of 8K.

[Rybags]

It might be worth assembling a 16K Ram based version that loads @ $2000 just for the sake of saying it can be done.

[JamesD]

It might be worth assembling a 16K Ram based version that loads @ $2000 just for the sake of saying it can be done.

It could certainly run from a small RAM configuration.

Code to generate the tables isn't that large depending on what precision you want.

If I could get two of the tables I was working on moved to page 0 this might still fit in an 8K cart.

If you want the tables on the cart it has to be 16K.

[SoundGammon]

How about an extra level? Level 5.

 

In this level, the Zylons have a hidden starbase that they are using to make more Zylon ships.

You can't win just by trying to destroy them, you eventually will be overrun!

 

To find the hidden base, you must do a Long Range Scan everytime you enter a sector and then bring up the Galactic Chart to see if it has been found.

The scan will only reveal the sectors around it.

 

When found, you must go into that sector and destroy the base, similar to docking at your own Starbase.

 

Then you must go and destroy the rest of the Zylon fleet to win!

 

Could be a fun challenge!

[Keatah]

Or how about having the enemy ships behave a little differently when they are closer, no more than a few sectors away, from the hidden base.

 

Sort of like how traffic behaves when a cop is running radar nearby. Drivers far back take note of everyone braking and fall in line. Except the ships would play more aggressively perhaps? Or tend to fly in a certain pattern or favor one side of the screen more - thus pointing to the direction of the hidden base?

 

A boss sector! A Zylon superbase that you have to fly around and hit certain parts of it first, knock out the shields, then navigation, then the main reactor. It could be the size of the base in VCS' Phoenix or VCS' Cosmic Ark.

[JamesD]

If you approach the base have Zylons start warping in from around the map to defend it.

*edit*

The base produces a new Zylon fighter every specific time period.
If you end up in the Zylon base sector it calls for help.
Fighters warp in at regular intervals based on distance they were away.
If you didn't clear enough fighters before entering that sector you will probably be overwhelmed with fighters.

Edited October 22, 2015 by JamesD

[Rybags]

Change the dynamics too much, may as well just start an entire new game.

 

What might be nice is more levels and/or a bigger overall galactic map, given that more storage could be used.

e.g. have up to double the number of Zylon squadrons, more starbases to defend in a larger overall area.

 

The concept of Zylon bases or mothership sounds good but then it becomes more like SR2/Last Starfighter.

Though it would be nice to have a boss that you have to overcome.

Maybe just have 4 enemy bases that you have to destroy - they can be simply starbases that don't fight back or have local defenders, but when you destroy each one it unleashes multiple squadrons of fighters that appear in random sectors in the vicinity of the base.

Game strategy employed would have to be such that you don't destroy all the bases in quick order as they'd unleash sufficient enemies that would overrun your own bases.

[SoundGammon]

Change the dynamics too much, may as well just start an entire new game.

 

What might be nice is more levels and/or a bigger overall galactic map, given that more storage could be used.

e.g. have up to double the number of Zylon squadrons, more starbases to defend in a larger overall area.

 

The concept of Zylon bases or mothership sounds good but then it becomes more like SR2/Last Starfighter.

Though it would be nice to have a boss that you have to overcome.

Maybe just have 4 enemy bases that you have to destroy - they can be simply starbases that don't fight back or have local defenders, but when you destroy each one it unleashes multiple squadrons of fighters that appear in random sectors in the vicinity of the base.

Game strategy employed would have to be such that you don't destroy all the bases in quick order as they'd unleash sufficient enemies that would overrun your own bases.

The Zylon bases in SR2/Last Starfighter were already exposed, just zip back and forth until they were destroyed.

No hunt involed. No challenge. No enjoyment when you discover it and change your strategy to take it out.

 

Khan, from Star Trek 2: "There she is!"

[Heaven/TQA]

cool. as I am still in Voxel land right now... does the converted SR-source assemble with MADS?

[JamesD]

cool. as I am still in Voxel land right now... does the converted SR-source assemble with MADS?

 

There are a few syntax differences in assembler directives such as .ds instead of .res but I didn't do anything fancy that would make it difficult to port to another assembler just by using search and replace.

 

[Rybags]

Defeating the planets in SR2 is actually a pretty big challenge.

 

In Last Starfighter it's easy as you can just move about the planet freely and wipe the cities out in a couple of minutes.

In SR2 they forced you into a proper sort of "orbit" where you always have forward motion and can only go left/right or faster/slower which makes it a whole lot harder to defeat each planet.

 

There's only so far you can go with a game like Star Raiders - change it too much and it just becomes another game entirely.

[Keatah]

I'd like to see a high res version with everything else untouched. No mods, no new sprites, no color changes, no nothing. Just upping the resolution.

[JamesD]

Defeating the planets in SR2 is actually a pretty big challenge.

 

In Last Starfighter it's easy as you can just move about the planet freely and wipe the cities out in a couple of minutes.

In SR2 they forced you into a proper sort of "orbit" where you always have forward motion and can only go left/right or faster/slower which makes it a whole lot harder to defeat each planet.

 

There's only so far you can go with a game like Star Raiders - change it too much and it just becomes another game entirely.

Well, I think ultimately you would launch the program with a menu that lets you make some choices as to which scenario you want to launch.

Part of the reason I chose that assembler was so a menu could be added in C to choose different variations, show instructions, etc...

 

I would think the first menu item would be '1. Classic Star Raiders', but it would make sense to offer other missions which use the same engine but have different goals.

 

[JamesD]

Thanks to JamesD's work, I've updated my github to use his CA65 cleanup of the source code instead of the reverse engineered disassembly. There's a makefile that generates an XEX file rather than a cart image with the idea that I'll be expanding the source to include the log/exp tables and don't need to stick with 8k.

 

https://github.com/robmcmullen/Atari8bit_StarRaiders

Did you test that or just see if it assembles?

[Rybags]

There is a Star Raiders HD around - clausb made the modification some years ago.

 

He PM'd it to me and I'm fairly sure it's been published here with his permission before.

 

SRE.zip

 

I've also had another idea for a simple higher res modification to the base game but won't say any more until I've had chance to try it out.

 

Also, re any modifications people contemplate, please consider a couple of vital inclusions:

1. most important. The Red Alert on PAL is totally wrong, giving the pinkish purple colour instead of red. This is an easy fix.

2. as mentioned by many people. The green screen with shields active is annoying.

My suggestion re shields would be to get rid of the colour change or restrict it to border area. Possibly accompany it with a graphical representation of the player ship with different graphics for shields on/off.

[JamesD]

There is a Star Raiders HD around - clausb made the modification some years ago.

 

He PM'd it to me and I'm fairly sure it's been published here with his permission before.

 

SRE.zip

 

I've also had another idea for a simple higher res modification to the base game but won't say any more until I've had chance to try it out.

 

Also, re any modifications people contemplate, please consider a couple of vital inclusions:

1. most important. The Red Alert on PAL is totally wrong, giving the pinkish purple colour instead of red. This is an easy fix.

2. as mentioned by many people. The green screen with shields active is annoying.

My suggestion re shields would be to get rid of the colour change or restrict it to border area. Possibly accompany it with a graphical representation of the player ship with different graphics for shields on/off.

Colors are defined at the top. All you need is is the proper value and we can change that in a few seconds.

The shield color could be more subtle easily enough but switching it to just the border would be more difficult.

[+MrFish]

2. as mentioned by many people. The green screen with shields active is annoying.

My suggestion re shields would be to get rid of the colour change or restrict it to border area. Possibly accompany it with a graphical representation of the player ship with different graphics for shields on/off.

 

The color is $A0. This is only green on PAL systems. It's a very dark aquamarine on NTSC.

 

I think the shield color looks fine on NTSC, I can see why it's not too welcome on PAL systems. Suffice it that there needs to be a PAL color table, but I'd leave the shield color in.

[Rybags]

I'd like to see the game have a more realistic "in-ship" view - not as outlandish as the ST version or as complex as the likes of RoF or Koronis Rift.

In conjunction with that could be an active shield/systems display instead of colour change.

 

The game seems to use 212 active scanlines of which 20 are already devoted to what would become part of the cockpit console, so leaves plenty of scope for additional detail.