Star Raiders Source Code to be released?

[fujidude]

I like the way shields on/off is shown as is.

[JamesD]

Could someone point me to documentation for the XEX file format.
I tried the code playermissile uploaded and as far as I can tell he threw it together and did just enough to assemble an xex file using a makefile.
He didn't even comment out the cart data.
I'm trying to get it working so I can test replacement divide code.

[VladR]

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.

It wouldn't be a sacrilege, if we kept the core brand - Atari. Just port it to the last and fastest model - e.g. Jaguar.

 

Having spent awful amounts of time with Star Raider in past, I would also very much like to see this in higher resolution, with more colors and better particles.But still keep the core gameplay intact.

 

Best of all, now with the source code available, we wouldn't just have to guess the AI / behavior - we could check the actual source code, so it could indeed have both the feel of A800 and the next-gen (compared to A800) visuals the Jaguar could provide.

 

The Galaxy map could be easily enhanced to offer multiple layers (sort-of like in Mass Effect) - to provide more places to visit and fight.

The "jump" sequence could be some neat effect (again, as a quick hack - a lower-res version of the jump gate in Mass Effect should suffice here)

 

While I got my hands full on Jag, Star Raiders was one of things I always wanted to see updated for Jaguar, and now that I got the skills (and some experience with 3D on jag), I should give this a priority.

[VladR]

Of course, this thread would be incomplete without the link to an Interview with Doug Neubauer:

http://www.atarihq.com/othersec/library/neubauer.html

[playermissile]

Could someone point me to documentation for the XEX file format.

I tried the code playermissile uploaded and as far as I can tell he threw it together and did just enough to assemble an xex file using a makefile.

He didn't even comment out the cart data.

I'm trying to get it working so I can test replacement divide code.

 

Indeed, just a hack to get it working. Also, in reference to your earlier post, it does create a working .xex that I have run successfully under atari800. I haven't played it extensively, so YMMV.

 

Here's the reference for object files that I've used:

 

http://www.atarimax.com/jindroush.atari.org/afmtexe.html

 

Go for it! Looking forward to seeing how someone with more knowledge than me figures out CC65's opaque .lnk files.

Edited October 22, 2015 by playermissile

[kiwilove]

Anything could be done to Star Raiders to add new life into it? I like the idea of adding variability/random elements to the game, so that you can be surprised well into the game.

 

Like adding a new kind of attack pattern(s) into it, so that they do behave differently at times.

Maybe adding shy elusive enemies which take a lot harder to track down and eliminate.

 

Adding new objects into the game - like a minefield? - different kinds of asteroids - ones you can't destroy, others will split into a smaller one...

 

Adding a random wormhole - which will give you some short of crazy hyperwarp - which can be good or bad.

 

New weapons - or upgrades would be nice - which can be lost also.

 

Having the droid shoot back, if you shoot it - duelling droid?

Which could do different things - like try to ram you - turning from a good droid to a bad one?

 

And if you're truly adventurous - maybe try adding some Star Wars element(s) to it - that can be done successfully. Not the whole game but parts (even if little things) that can be done well. Same for Empire Strikes Back.

To be able to go to different systems and go down to various planets - if only skimming their surfaces.

 

To at least have some option as to how you want the viewscreen to look - I prefer black space for combat mode, and not the green screen.

 

Harvey

Edited October 22, 2015 by kiwilove

[Kyle22]

Hi-Res VBXE version?

[+MrFish]

Like adding a new kind of attack pattern(s) into it, so that they do behave differently at times.

Maybe adding shy elusive enemies which take a lot harder to track down and eliminate.

 

These already exist in the game. There are a number of different attack patterns used, and of course they are more difficult to deal with as you increase the difficulty level.

 

There are also times when the enemies with either flee you -- usually from a distance only -- or stay outside of arms reach, unless you increase your attack speed.

 

But these could altered and the variety could be increased.

[JamesD]

 

Indeed, just a hack to get it working. Also, in reference to your earlier post, it does create a working .xex that I have run successfully under atari800. I haven't played it extensively, so YMMV.

 

Here's the reference for object files that I've used:

 

http://www.atarimax.com/jindroush.atari.org/afmtexe.html

 

Go for it! Looking forward to seeing how someone with more knowledge than me figures out CC65's opaque .lnk files.

Since I've made other changes to the code, I was porting your changes back to my working copy.

I probably just missed something.

You should actually be able to skip the lnk file for something this simple since all the blocks are marked with a start address.

It's when you start having blocks that can be positioned anywhere in memory and you are joining multiple object files that it becomes important.

Then you can let the linker decide how the puzzle fits together rather than setting all the addresses yourself.

This just needs a header tacked on so it can be loaded by the emulator and another block header at the end of the code to auto execute it.

I've had to do the same thing for other emulators.

I still have to figure out the code but it shouldn't be difficult.

 

For a simple program you can still build this using a lnk file from a batch file like this, no need to mess with make for one file.

This way I don't have to mess with cygwin just to build one file.

Make files are mainly important when you start having multiple files with dependencies on other files.

@echo off
:top
ca65  StarRaiders.CA65 -l StarRaiders.lst -o StarRaiders.o
ld65 -o StarRaiders.xex -C StarRaiders.lnk -m StarRaiders.map StarRaiders.o
shift
if not %1.==. goto top
:end

BTW, Star Raiders starts direct page use at $62 but ZP in your lnk file uses a higher address. If we were letting the linker assign addresses a few things wouldn't fit.

In this case it doesn't matter due to the hard coded addresses.

 

[FifthPlayer]

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.

 

A menu to customize the game objectives is interesting, but "1. Classic Star Raiders" to me is unnecessary as I already have the classic game to play.

[FifthPlayer]

Re: ports off-platform:

 

It wouldn't be a sacrilege, if we kept the core brand - Atari. Just port it to the last and fastest model - e.g. Jaguar.

 

At a certain point, the game stops being a port and starts being a rewrite. If one is going to take the time to do a rewrite for the Jaguar, to me it would make more sense to simply target modern platforms, such as PC/Mac or iOS/Android. It would find a much wider audience that way.

 

My feeling is that SR is fundamentally an 8-bit game, and so ports of the 6502 assembly to other 8-bit systems could be pretty interesting. I'd love to see someone attempt an Apple II port, for instance - it's likely doable with 48/64K, esp. if the math is driven by lookup tables to allow more CPU time to be devoted to software sprites.

[Synthpopalooza]

I would be keen on seeing how a C=64 version would come off ... or even better, if someone made a vector version of this using Asteroids hardware (it also uses 6502).

[SoundGammon]

I'd love to see a 7800 port, using the keypad from the 2600 version should work!

 

Multi-colored enemy ships, intensify the photon particle, no slow down on the explosions!

[Rybags]

I also had the thought of a 7800 version.

 

4K Ram might be a problem though original uses 8K of which over half goes to screen and OS overhead anyway.

Dynamically building DLists might be an issue. Maybe use DLL with dummy entries that get filled with stars, ships, shots. Explosions might better be done with character entries that are enlarged when needed.

[JamesD]

I would be keen on seeing how a C=64 version would come off ... or even better, if someone made a vector version of this using Asteroids hardware (it also uses 6502).

Vectrex.

The code would need converted to 6809 though.

Vector hardware is nice because you don't have to erase old sprites.

[Heaven/TQA]

as I did not had a chance yet to look into the source code itself... but is it commented? or readable or is everything like with DIS6502... Lxxxx without any hint?

[VladR]

At a certain point, the game stops being a port and starts being a rewrite.

We're talking about a complete rewrite here (e.g. from scratch) anyway - the coding techniques of A800 are non-transferrable to Jaguar. The A800 code would only serve as a reference as to the implementation of game rules and AI - e.g. we would have a complete set of AI's state machine, so that we could match the behavior of enemies without guessing. The graphics would change completely anyway - though we would have to preserve the look&feel.

 

For example - Planet Rendering. On Jag, you could have an actual full-res planet texture (but to avoid the lowpoly look of meshes, we'd have to go for image-space texturing - to get a proper rounded look of a sphere) and render the planet under different angles and zoom factors. The textures would be created at run-time using procedural techniques (thus each planet would have its own distinct look) , but the core gameplay would be kept intact - otherwise it would not be Star Raiders anymore.

 

Re: ports off-platform:

 

 

At a certain point, the game stops being a port and starts being a rewrite. If one is going to take the time to do a rewrite for the Jaguar, to me it would make more sense to simply target modern platforms, such as PC/Mac or iOS/Android. It would find a much wider audience that way.

Disregarding the Star Raiders on Xbox that was super boring, I don't believe it makes any sense to create a 1000th space game for modern platforms. The genre is so over-crowded that even thinking about it is a waste of time, let alone marketing it (how exactly do you plan on making the game visible in such a noisy and crowded environment? That question is 3 orders of magnitude more important than any implementation). The Jaguar was the last Atari and there will never be a faster one.

 

That is why I believe it makes sense to produce one for Jag - to see how it could have looked best on Atari.

 

 

As for the audience - uhm - this is as niche as it gets already - what do you think the percentage of current gamers (across all mobile/desktop/console platforms) is that have actually played the original Star Raiders on Atari ?

 

 

 

EDIT: Well, crap. I just noticed. This code is for Star Raiders I. I was talking about Star Raiders II, this whole time. I never really used to say "two"(it's just implied, as it's Star Raiders), but they are two quite different games, Star Raiders II being much more visual than I.

 

Any chance for Star Raiders II code being released ?

Edited October 23, 2015 by VladR

[danwinslow]

From the interview :

 

 

DN: With more memory available, I could have added planet landings and a trench scene. However, at the time, all games had to fit in 8K of RAM memory, as well as in 8K of ROM. These restrictions limited a lot of options. I had also envisioned more charts, or subcharts you could call up. With a disk drive for storage, you have more flexibility.

 

and

 

 

 

DN: Everything could be improved. More and better graphics would be added, not just showing the front view. I would like to add a planet and a trench scene. It seems that it should be possible to add effects closer to those in the Star Wars movies. It would be interesting to try and get and planet landing sequence, where you start from space and approach the planet; as it gets bigger more detail appears, and finally, you're on the surface.

 

If we are going to mod it, it seems like modding it in the designers original direction would be most appropriate.

Edited October 23, 2015 by danwinslow

[Rybags]

For Jaguar a line by line conversion to 68K would probably work. Maybe the graphics could be remapped in similar fashion to how the ST conversions for it were done.

 

Wasteful with resources, sure. But for obtaining a quick/easy conversion doesn't really matter.

[JamesD]

FWIW I have a different divide in place.
It's not table driven so I doubt it's faster but the code is much easier to follow.

While it runs, it's not compatible with the original so the visuals are out of whack.

At first glance the divide looked like a 16 bit divide that only processed part of the most significant bits and then scaled the output with the table multiply.

But at the moment it's appears as if the code expects something different and I'm trying to track down what that is.
Once I track that down I can look at switching the code to tables.
The problem is duplicating the behavior.

This divide might be faster than the original once I get it working but I wouldn't expect a huge improvement.

I'm doing this more for figuring out the behavior to where log will work.

 

 

as I did not had a chance yet to look into the source code itself... but is it commented? or readable or is everything like with DIS6502... Lxxxx without any hint?

It's sparsely commented.
There are no real comments about theory of operation of the routines and there are sections that will have one line for over 20 lines of code.

OTOH, there are some sections with comments almost every line. It depends on how much the programmer thought he needed to remind himself of how something worked.

[JamesD]

 

A menu to customize the game objectives is interesting, but "1. Classic Star Raiders" to me is unnecessary as I already have the classic game to play.

With faster math?

[VladR]

For Jaguar a line by line conversion to 68K would probably work. Maybe the graphics could be remapped in similar fashion to how the ST conversions for it were done.

 

Wasteful with resources, sure. But for obtaining a quick/easy conversion doesn't really matter.

It's not just wasting resources. I just never understood the point in getting exact same audiovisuals on a console that is few generations newer. Might as well just play it on the original platform.

 

I am a strong advocate for keeping gameplay as close to the original as possible, just raise the resolution, do more effects, create more levels, so it looks like a new game, but feels and plays like the original. There is nothing wrong with gameplay of Star Raiders, but change it a bit, and you got a different game (e.g. more sim-like , as Wing Commander for example)...

 

It was mentioned before that the gameplay is "8-bit". Well, then the gameplay of Mass Effect is "8-bit" too, as it's also just visiting various planets in galaxy and shooting your way through.

[VladR]

 

From the interview :

 

DN: With more memory available, I could have added planet landings and a trench scene. However, at the time, all games had to fit in 8K of RAM memory, as well as in 8K of ROM. These restrictions limited a lot of options. I had also envisioned more charts, or subcharts you could call up. With a disk drive for storage, you have more flexibility.

 

 

and

 

DN: Everything could be improved. More and better graphics would be added, not just showing the front view. I would like to add a planet and a trench scene. It seems that it should be possible to add effects closer to those in the Star Wars movies. It would be interesting to try and get and planet landing sequence, where you start from space and approach the planet; as it gets bigger more detail appears, and finally, you're on the surface.

 

 

 

If we are going to mod it, it seems like modding it in the designers original direction would be most appropriate.

Totally agree. With only 8 KB of RAM spent, there is a lot of space for the Doug's wishlist features above.

 

However, it shouldn't result in Star Raiders II (we already have that).

 

I wonder what exactly he envisioned by the 'trench' scene. Perhaps a Star-Wars-style chase ? Or just run'n'gun ?

 

[JamesD]

I've been working backwards from a divide routine to duplicate the functionality of the Star Raiders "DIVIDE:" routine.
I just created a loop that keeps subtracting the divisor from the dividend and increments the result each time it's successful.

Once it fails the dividend becomes the remainder.
But the DIVIDE: routine has some odd behavior. It limits the number of loops, plus it shifts the dividend and result each loop.

A normal divide doesn't produce the desired results so it appears this cannot be duplicated by using log without additional changes to the code.

[+CyranoJ]

While I got my hands full on Jag, Star Raiders was one of things I always wanted to see updated for Jaguar, and now that I got the skills (and some experience with 3D on jag), I should give this a priority.

 

Here comes Centron 4D!!!