Star Raiders port to Amiga?

[lmimmfn]

Any chance of some pix with the updates? , would be nice to track even if it simple at the start.

[VladR]

I guess I could do that, if you think it's a good idea. For now, it looks exactly same as the two screenshots on page 3 of this thread...

[VladR]

I just had a very interesting unexpected discovery while implementing dynamic shading of stars based on distance coupled with reappearing at the furthest distance (upon crossing behind the player).

When I rotated the view downwards and at about 45' angle, the starfield created a strong vertigo effect in my stomach - very similar to Descent when you suddenly approached a vertical shaft (downwards).
First few seconds it felt like I was falling ! I know there are some people more sensitive to this (some even to just walking around in FPS games) - would be great to test it on them

This could be used as a new effect (perhaps even a feature) for the Hyperspace jump.

Now, it obviously helps a lot that I'm testing this with 384 stars, so the field of view is quite densely populated (we certainly won't have that many stars for OCS build).


I'm just genuinely surprised I haven't experienced this ever, on any platform, having played hundred+ space games. A truly WTF moment !

[TroyWilkins]

Originally Posted by VladR

I just had a very interesting unexpected discovery while implementing dynamic shading of stars based on distance coupled with reappearing at the furthest distance (upon crossing behind the player).

When I rotated the view downwards and at about 45' angle, the starfield created a strong vertigo effect in my stomach - very similar to Descent when you suddenly approached a vertical shaft (downwards).
First few seconds it felt like I was falling ! I know there are some people more sensitive to this (some even to just walking around in FPS games) - would be great to test it on them

This could be used as a new effect (perhaps even a feature) for the Hyperspace jump.

Now, it obviously helps a lot that I'm testing this with 384 stars, so the field of view is quite densely populated (we certainly won't have that many stars for OCS build).


I'm just genuinely surprised I haven't experienced this ever, on any platform, having played hundred+ space games. A truly WTF moment !

Oh wow, would it be possible to capture that on video? I've never experienced that sort of experience, and that, to me at least, indicates that we don't need graphics that look like they belong on a PS5 for it to be a good experience.

[VladR]

Originally Posted by TroyWilkins

Oh wow, would it be possible to capture that on video? I've never experienced that sort of experience, and that, to me at least, indicates that we don't need graphics that look like they belong on a PS5 for it to be a good experience.

Let me do some scripting first - I will chain up several rotations together, hopefully with some non-linear acceleration to slightly enhance the effect.

SRI did only a simple acceleration when jumping to hyperspace.

But we don't have Atari dictating "thou shalt not consume more than 8 KB", so I don't mind spending a KB or two (out of 512) on some transition effect.

Worst case scenario is we learn it won't work but that's progress anyway.

And none of this work is entirely lost, as it'll be directly useable on V4. I've already moved few routines from this to my main V4 project...

[VladR]

Originally Posted by TroyWilkins

we don't need graphics that look like they belong on a PS5 for it to be a good experience.

Looks like even during Amiga times the tech has moved way too quickly beyond Star Raiders technology.

Closest space shooter game I can find is Wing Commander, which occupies 75% of screen with HUD (absolutely ridiculous). Those pre-rendered sprites from 3 and half angles did not age well at all.

SRI, however, aged perfectly well. PointCloud and Flatshading always ages well.

[VladR]

I did some scripting for the transition to Hyperspace. A simple linear angle increase looked too boring, so I tried gradual acceleration.

First, I used simple integer math - each frame the angle would get incremented by 1 (then 2,3 and so on).
However, even though there's 360 degrees, it's kinda twitchy when the angle increment jumps from 1 to 2 (or 2 to 3).

So, I implemented a fractional change - in increments of 0.25 (0.25, 0.5, 0.75, 1.0) - via bitshift.

While the transition from one to another is much less visible (than the integer delta), it is still, however, noticeable.

I guess I'm going to have to reimplement it with fixed-point math, which will allow for constant smooth acceleration (at the precision of used bitshift)...

[VladR]

Attached is a short (10s) .MP4 vid of the potential Hyperspace transition effect.

It's in xVid codec (2Mbit). Works in Windows Media Player, hopefully with all standard codecs...

Stars are not randomized yet, but in a regular grid for now.

These are the scripted stages (most of them overlap):
1. Perspective Stretch into the distance
2. Roll around View axis
3. Gradual Speed increase
4. View Angle Down
5. RedShift of colors
6. Hyperspace speed increase
7. View Angle back to center - this will be the interactive part (joystick)
8. Colors back to normal
9. Perspective reverted back to normal

I did some quick test with a short motion blur at the start/end of the effect, but it doesn't look as good in such low res, as I hoped it would.

I reckon V4 will make it work in 640x400, though - especially when I run the 2x2/3x4/cross kernel blur over each star.

[TroyWilkins]

That looks really cool in my humble opinion. Great work!

[TroyWilkins]

Originally Posted by VladR

Looks like even during Amiga times the tech has moved way too quickly beyond Star Raiders technology.

Closest space shooter game I can find is Wing Commander, which occupies 75% of screen with HUD (absolutely ridiculous). Those pre-rendered sprites from 3 and half angles did not age well at all.

SRI, however, aged perfectly well. PointCloud and Flatshading always ages well.

I just fired up the original Star Raiders on an emulated Atari 400 to take some video captures and to remind myself of how it looks, and I noticed something that made me think of what I've quoted above.

Right at the very start, when you're choosing your difficulty level, before you hit the start button to begin a game, the starfeld display is literally fullscreen, with the only exception being the text up towards the top of the screen.

When you start the game, you lose a little of that starfield view to the 2 'text' status lines, but the vast majority of the screen is still the starfield. Pretty impressive stuff I think for a 6502B running at 1.77MHz (PAL) or 1.79MHz (NTSC), given how smooth it all looks when in motion. And even when playing, that's a bigger viewport than Wing Commander or Elite, and about the same as Frontier: Elite II from 1993.

Sure, Frontier: Elite II is more colourful and complex, but it's also not a great experience on a basic A500, where this could very well be I think.

[coder76]

There is also a good starraiders clone (Sentinel) for C64, released in 1984 by Synapse software. I believe they developed for Atari first, before they moved to C64. It has all the features of Starraiders I believe (and more), though I never played Starraiders.

The game can end in several ways: run out of shields, energy, lose all friendly baseships (no repairs and energy replacements can be done), or the planet in the middle of the starmap gets overrun by enemy ships. Ship systems get damaged with more damage to ship and can be repaired on friendly baseships. You can lose your cannons as well, but the ship can also fire protons, which will destroy everything on the screen at once. These are also needed to destroy enemy baseships, and you get one additional proton when docking with friendly baseships for repairs.

Easier levels are too easy, but there are 5 difficulty levels, and in the difficult levels, there are really a lot of enemy ships around, which will start attacking the planet and your baseships right away. The game is won by destroying all enemies, not just all the enemy baseships.

Here is a video of the game:
[ Show youtube player ]

[TroyWilkins]

Originally Posted by coder76

There is also a good starraiders clone (Sentinel) for C64, released in 1984 by Synapse software. I believe they developed for Atari first, before they moved to C64. It has all the features of Starraiders I believe (and more), though I never played Starraiders.

The game can end in several ways: run out of shields, energy, lose all friendly baseships (no repairs and energy replacements can be done), or the planet in the middle of the starmap gets overrun by enemy ships. Ship systems get damaged with more damage to ship and can be repaired on friendly baseships. You can lose your cannons as well, but the ship can also fire protons, which will destroy everything on the screen at once. These are also needed to destroy enemy baseships, and you get one additional proton when docking with friendly baseships for repairs.

Easier levels are too easy, but there are 5 difficulty levels, and in the difficult levels, there are really a lot of enemy ships around, which will start attacking the planet and your baseships right away. The game is won by destroying all enemies, not just all the enemy baseships.

Here is a video of the game:
[ Show youtube player ]

Oh wow, I did not know about this game, thank you for posting this, very interesting. I'll have to give that one a try, it looks and sounds quite interesting and yes, does appear to have been fairly heavily influenced by Star Raiders.

Some very nice transition effects used in this that could be used in our port/clone/version if so desired, such as the transition to showing the galactic map.

[VladR]

Originally Posted by TroyWilkins

That looks really cool in my humble opinion. Great work!

Glad you liked it, just remember - star count will be butchered for A500, but before I do any benchmarks on A500, we won't know for sure (though it surely won't be anywhere near 384 stars like I have now). I guess I could spend an hour, counting cycles of the main loop - to get some rough estimate of the cost of one star.

Originally Posted by TroyWilkins

I just fired up the original Star Raiders on an emulated Atari 400 to take some video captures and to remind myself of how it looks, and I noticed something that made me think of what I've quoted above.

Right at the very start, when you're choosing your difficulty level, before you hit the start button to begin a game, the starfeld display is literally fullscreen, with the only exception being the text up towards the top of the screen.

When you start the game, you lose a little of that starfield view to the 2 'text' status lines, but the vast majority of the screen is still the starfield. Pretty impressive stuff I think for a 6502B running at 1.77MHz (PAL) or 1.79MHz (NTSC), given how smooth it all looks when in motion.

Yeah, the immersion really works nice there. I mean, especially in 1979, that must have been brutal next-gen, seeing a full-screen 3D starfield like that.

We have 512 KB of RAM, so I don't object to having a cockpit, but it will be a secondary consideration.

If anything, right now I'm thinking of having at least these 2 HUD options (key-press to switch between them any time):
1. None at all : just starfield, full-screen
2. Atari-style HUD

Originally Posted by TroyWilkins

And even when playing, that's a bigger viewport than Wing Commander or Elite, and about the same as Frontier: Elite II from 1993.

Sure, Frontier: Elite II is more colourful and complex, but it's also not a great experience on a basic A500, where this could very well be I think.

It's been some time since I watched Frontier, so I will take a look at it now, perhaps there are some features we can get inspired by and would make sense to incorporate here? From the top of my head, it's quite a different genre (other than also happening in space), though.

[VladR]

Originally Posted by coder76

There is also a good starraiders clone (Sentinel) for C64, released in 1984 by Synapse software. I believe they developed for Atari first, before they moved to C64. It has all the features of Starraiders I believe (and more), though I never played Starraiders.

The game can end in several ways: run out of shields, energy, lose all friendly baseships (no repairs and energy replacements can be done), or the planet in the middle of the starmap gets overrun by enemy ships. Ship systems get damaged with more damage to ship and can be repaired on friendly baseships. You can lose your cannons as well, but the ship can also fire protons, which will destroy everything on the screen at once. These are also needed to destroy enemy baseships, and you get one additional proton when docking with friendly baseships for repairs.

Easier levels are too easy, but there are 5 difficulty levels, and in the difficult levels, there are really a lot of enemy ships around, which will start attacking the planet and your baseships right away. The game is won by destroying all enemies, not just all the enemy baseships.

Here is a video of the game:
[ Show youtube player ]

Damn, what a great find ! Thank you And to think this runs in 64 KB at 0.985 Mhz!

Just watched the whole vid. It appears more accessible (chatty, explaining stuff via messages) than SRI and slightly more arcadey. Definitely very colorful.

I'm not sure we want the Disneyland-On-Drugs color theme, though...



Very clever technique of drawing lines during transition ! Uses just few pre-defined angles, and updates only endpoints (thus reducing line computation cost by more than an order of magnitude).

I initially completely discarded the idea of those hyperspace lines (knowing darn well how expensive generic line algo in 3D is), but this trick would obviously work on A500 too.
We sure have a lot more RAM for unrolled code for that effect than puny C64.

[VladR]

Originally Posted by TroyWilkins

Some very nice transition effects used in this that could be used in our port/clone/version if so desired, such as the transition to showing the galactic map.

Yeah, but it takes whole six seconds from the moment you press the key till you get control within the map.

That's quite atrocious, no ? Especially for something you use often.

Hyperspace transition - that's fine - you don't do that that often. But map should be available very quickly.


There is scenario, where you might want to take your time - let's say it would take A500 3 full seconds to draw the map (like, showing 3D orbits of planets - lots of expensive divisions in that process) - then yeah - we would need some kind of transition to mask the rendering in the background (kinda like a fake loading screen).

Hopefully we can find some compromise between cool-looking Galaxy map and the time it takes to render it (ideally under a second).

Hell, if scripted properly, the actual drawing of the map could be the transition effect in itself without any faking (kinda like in C64's Sentinel)

[TroyWilkins]

Originally Posted by VladR

Yeah, but it takes whole six seconds from the moment you press the key till you get control within the map.

That's quite atrocious, no ? Especially for something you use often.

Hyperspace transition - that's fine - you don't do that that often. But map should be available very quickly.


There is scenario, where you might want to take your time - let's say it would take A500 3 full seconds to draw the map (like, showing 3D orbits of planets - lots of expensive divisions in that process) - then yeah - we would need some kind of transition to mask the rendering in the background (kinda like a fake loading screen).

Hopefully we can find some compromise between cool-looking Galaxy map and the time it takes to render it (ideally under a second).

Hell, if scripted properly, the actual drawing of the map could be the transition effect in itself without any faking (kinda like in C64's Sentinel)

Ahh yes, good point, we don't want to disrupt the "flow" of the game unless necessary, particularly as the game runs in real-time.

[VladR]

Originally Posted by TroyWilkins

Ahh yes, good point, we don't want to disrupt the "flow" of the game unless necessary, particularly as the game runs in real-time.

If you mean the cumulative time loss (say, 3 seconds per invoking a map) across whole game (e.g. you press map key 100 times, thus 100x3 = 300 seconds lost), then that's not an issue, as we can simply disable the AI update during the map transition (via simple on/off variable in the code).

It's just annoying watching the same transition 100x per game session.

I've been doing some initial research into this and since on OCS we don't have a lot of RAM to store the map (both Galaxy and Star) screen, we will have to render it, real-time, upon key-press.
I've discarded few approaches that would look nice but take more than half second to render.

Half second on 7 MHz 68000 is not exactly miracle, unfortunately - it's still only around ~250,000 instructions (rough ballpark estimate), which if we want a galaxy background with real 3D stars (forming nice shaded elliptical rings, below the 2D grid), adds up very fast...


Doing this real-time will however allow us to do actual planet orbits (when you enter map of the current star system) - meaning each planet (even if it's just a 2D sprite) will have a specific orbital period, so every time you hit the map key, the planet will be slightly further along its orbit.

[VladR]

I've been experimenting with various starfield approaches during last 2 weeks.

SRI doesn't really move the stars, it's a mere hack (zpos increment by a speed) that works because they rotate them in world-space, so regardless of where they are, they don't need to do anything else.

This approach has few issues that I want to avoid in Vampire version, especially the cumulative error that becomes quite ugly in higher resolutions. You don't see it on Atari very much, because stars appear right in front of the camera and disappear quickly. But if you rotate at lower speeds few times, it can be seen even on Atari.

There's few reasons why it makes sense to have a slightly more complex star system - by having a unique direction vector per star, we can:
- create more complex transition effects
- have various star groups on screen, each with different speeds/directions
- create starfield FX similar to one in Orville show, where nearest stars in a tube around the ship move 10x faster than the further ones
- have an actual different camera angle viewing the stars (impossible in SRI) without the cost of view-matrix transformation (one-off CPU cost upon changing camera angle)


Now, for this to work on 7 MHz 68000, the max CPU work we should do per each star is just an addition (e.g. Star.Position + Star.Direction).

This is the moment where pure integer approach reached its limits, so I had to implement fixed-point math. The fastest fixed-point approach appears to be 16.16, since we can simply discard lower 16 bits and no bitshift is needed (which is expensive on 68000 - 2 cycles per each shift).

Thus, the only time when direction vector needs to be computed is when star leaves screen.

Unfortunately, each of the four approaches has different visual characteristics / behavior, each with separate set of advantages/disadvantages. It does look slightly weird when certain stars cross the center of the screen (the direction vector is completely generic, so each star can move freely in any direction and any speed).

I think I can fix that cross-over while retaining global position+direction per each star and keeping the minimum possible performance cost (I have one approach that does that already, but it's too expensive for 7 MHz due to amount of math involved). Hopefully, it won't introduce any unwanted star behavior.
The most recent approach places stars in a sphere (or cylinder if desired) which opens up few new possibilities.

Because the ships will be internally 3D, we could create a transition FX (hyperspace or other) that will populate the Starfield data with the vertices of the ship and assign a different speed to each of them - making it effectively disappear over the course of few seconds (when coupled with shading them appropriatelly).
If you've seen Chronicles of Riddick, when his ship was leaving the atmosphere, it left a trail of 3D vertices slowly dissolving away over 3 seconds. It would probably take a week or two to script something like this, but this approach could technically do this.

And, of course, ship explosion could really benefit from this approach.

I'm sure there's few other applications I haven't thought of yet. Any in-engine cut-scene doesn't need 30 fps, but can easily get away with 10 fps, as we have full control over movement speed, so we can make even complex effects appear smooth (by reducing movement speed to match the framerate).

[saimon69]

Not a coder but wonder if a 'star tube' linked to the spaceship where points disappear behind you and appear in front of you is feasible for low speeds?

[VladR]

Originally Posted by saimon69

Not a coder but wonder if a 'star tube' linked to the spaceship where points disappear behind you and appear in front of you is feasible for low speeds?

You mean a tube shape consisting of stars placed in a regular grid along the tube sides?
Like an additional (second) starfield "layer" on top of regular starfield layer (further away from ship)?

The first thing that comes to mind is the tube FX in Orville - you could see it outside the window even from within the Orville's interior (mostly from within Mess Hall). You mean something like that ?

I'm sure it won't have a measurable impact on Vampire, but on 7 MHz...

Let's not forget that on Atari, most ops were 2/3/4 cycles, especially when working with zero page addressing.

The single greatest advantage of 68000 for this particular game is that we can directly do 32-bit signed math and have 16 registers. So, mostly coder's comfort, really. Signed 16-bit math on 6502 is quite a b*tch to debug...
But from performance standpoint, I don't really think the performance throughput differential is 7 MHz / 1.79 MHz...

Storing byte on 6502 (to zero page) is 3 cycles. On 68000, storing byte from register is 16 cycles (and with the DMA slot contention as a bonus). Slower than on 6502...
Array access via (an)+ should be just 8 cycles, so that's something...

I sure hope we can at least double the star count from 12 to 24. I doubt we can triple it, though...

And, the bitplane-switch latency is still an unknown quantity to me. If that in itself is significant, then we will have to dynamically [per frame] sort (or traverse full array 4 times - whichever approach will be faster) stars by their current bitplane index - a process that didn't have to happen on 6502...