New game revamp/release - Stellar Shuttle 480i

[Rybags]

Well, I was hoping to have this out in time for the 40th Anniversary (Moon Landing), but other stuff interfered and a few bugs crept in.

 

Ssh480i.zip

 

STELLAR SHUTTLE 480i

 

As a further demonstration of the newly found Interlace ability of the Atari, presenting a revamp of the classic "Stellar Shuttle".

 

Features:

 

• Instead of just 4 non-rotating rock types, now we have 16 distinct rotating rocks, with 16 animation steps each.
  
• Asteroids defined as 8x16 (small), 16x32 (large) pixels
  

 

YouTube video (doesn't have sound):

 

To do list:

 

. fix main DLI... occasional glitches appear in first scanline of asteroid rows... can cause collision with player.

. tweak the game's delay constants (for door opening, closing, rescued guys jumping, running). The Interlace and animation take up some extra CPU cycles which at the moment makes some things run slower.

. fix Display List corruption of title screen when game over.

. generate new animation speeds for rocks on level up (currently only generated once)

. further colour tweaks to freshen the look, make monster same colour on title and game screen.

. make a nice 8x16 font to replace the system font.

. replicate main font into extra asteroid fonts, currently messages like BONUS aren't displayed properly.

. possible addition of Trainer and/or selectable number of ships.

. look into fixing a bug that exists in the origninal - when a saucer appears it's XPos is momentarily the same as when it was last shot... can sometimes kill the player.

Edited July 24, 2009 by Rybags

[José Pereira]

Can you post a picture.

I'm in a public place, using someone else computer.

 

Thanks.

José Pereira.

[Rybags]

Added a YouTube video to the first post.

[SeaGtGruff]

Added a YouTube video to the first post.

Pretty feakin' cool! Thanks for posting this!

 

Michael

[Tezz]

Excellent Gary Great work.

[tjb]

Awesome! I would think the image data necessary for the rotating rocks would take up quite a bit of memory (assuming pre-shifted images). Is this true or did you come up with a slick way to compress them?

 

tjb

[Heaven/TQA]

kicks ass, Rybags! cool...

 

now Miker needs to make a nice soundtrack and someone a nice g2f title screen... or you prefer a 480i highres vector like title...

[NRV]

Nice work!

 

I didn't knew the game by the way..

 

NRV

[Rybags]

As it turns out... I was going to do 4 x 16 individual animations, but the game's rocks are just 2 big/2 small with the second of each just turned 90 degrees.

 

So, I thought, since most of the time, each rock will be at some different angle, I just did 16 animations of each big/small.

 

Used Photoshop to turn each rock by 22.5 degree steps, which is a bit of a pain because it forces anti-aliasing and it doesn't allow rotate function in 1-bit bitmap mode (GIMP does though).

 

Then edited the full sets in MS Paint. Tried to ensure 2 pixel thickness in H/V directions so we don't get artifacts or interlace flashing due to single pixel thickness.

 

Quick & dirty BASIC program converts the bitmaps into the data files imported into the mod... even scanline data and odd scanline data.

 

256 bytes used for the small rocks, 1K is used for the big rocks.

 

A single move routine handles the small rocks. 4 move routines handle the big ones (since 1K = 4 pages). A bit of code + some tables self-modifies 2 JSR instructions to call the move routines for each rock.

 

Animation speed is 7 bits, upper bit controls direction... simple addition to accumulator variable for each rock, a change in Frame value sets up an animation call.

 

Due to CPU constraints, only 4 rocks are done per frame, but animating a rock at full speed means it turns more than 3 times/second, so it doesn't matter about that.

 

Move routines take about 800 bytes of space.

 

VBlank sequence had to be all moved about. I scrapped the OS VBlank completely because the Interlace is time-critical. The major reason is that if the DLIST address is moved from the shadow at the wrong time, it can cause the display to jump.

 

So, in VBlank, we have: calculate frame numbers for 4 rocks, then perform interlace. Call game's Immediate VBlank, then game's Deferred VBlank, then perform actual movement of rock data.

 

4 character sets are used (actually 8 since we need to double-up in Interlace). Since there are 7 rows of asteroids, we have a bit of repetition... not so noticable since everything is moving in opposite directions.

 

The game itself seems rediculously simple so far as it's movement mechanics. Same direction rows always move the same speed, and use the same HScrol value. First row of rocks always moves right -> left, etc.

 

One of the things still bothering me - the time you store to HScrol is critical. Along with changing CHBAS, it seems I'm getting corruption... I've optimised the DLIs twice already, looks like I might need to alter them again to use self-modifying code to get that extra bit of speed at the start.

 

The game itself does most of the mechanics of the ship, docking etc in the main loop. There are delay constants as follows (operands in LDA # instructions).

24f8 - base left/right movement delay 2533 - doors open delay 28e5 - astronaut delay 1 2921 astronaut jump delay 29d2 astronaut walk 2 delay 2a68 door close delay.

[Heaven/TQA]

thx Rybags.

 

 

Btw. re the photoshop antialising... we had this yesterday in our art department. we published and prepared for some of our NDS game screenshots and cutted assets out of screens and I was telling all the time to our gfx wizard (she is too young, she grew up with anitalising) she should switching off antialising when cutting 32x32 pieces out of the screenies and placing them together. We managed to get the antialising off when zooming but not when putting the pieces back in the screenshot. Really not impossible to switch that off?

[Rybags]

I don't think you can turn it off... it's annoying.

 

Photoshop is great for faking stuff, but kinda weak for creating game assets for our old computers... I tend to have MS Paint open and copy/paste between the two.

Even stuff like pixel editing is easier in Paint.

 

What we need is a painter where like you said, you can turn off filtering, anti-aliasing etc. PhotoShop is also weak in the lower palette modes, it disables most of the transform stuff when you change a pic to 1-bit colour mode.

 

There's The Gimp, but it's annoying insofar that it keeps picture, tools etc. all in seperate windows. I get annoyed at apps that insist on multiple windows, much prefer a tab-type layout.

Edited July 25, 2009 by Rybags

[Heaven/TQA]

that's why I am using Corel's PaintShop Pro X and XI on Windows. Mac, do not know. Gimp is strane with all the flowting bars...

[SeaGtGruff]

Photoshop is great for faking stuff, but kinda weak for creating game assets for our old computers... I tend to have MS Paint open and copy/paste between the two.

Even stuff like pixel editing is easier in Paint.

That's what I do, too-- copy and paste back and forth between Corel Paint Shop Pro and MS Paint, because Paint is so much easier to use for certain basic things, even though Paint Shop Pro is undeniably more powerful than Paint.

 

Michael

[Rybags]

I was actually tempted to redo the asteroids in Mode 4, shaded solid rocks that rotate in all 3 axes... problems being, it would probably use a ton of RAM, and I don't really have any software to do that kind of rendering.

 

Also, it would have changed the game too much, I wanted to keep things within the original spirit of the game.

[spookt]

I use Gimp on OSX a lot when editing graphics for webpages. It really is a great tool considering its free. It took me a while to get used to the multi windows and I found them frustrating at first, but now I don't even think about them.

[Rybags]

ssp12.zip

 

New build... included an 8x16 font I built for the text. Kinda broke a couple of things such as the title screen, fix it later. Also tweaked a couple of the delay constants so it runs a bit better.

 

I've really had the feeling I should have done 32 rock angle animations instead of just 16... would have cost an entire 1800 bytes or so extra and maybe 20 minutes more work... well, probably a bit late now, want to not have to spend too much more time on this thing.

 

[devwebcl]

Nice work Rybags, I hope you can finish it the way you say, not only because you're bored with this project because it's a good contribution.

Besides this game was one of the few I had to my old 400... I remember the first time that the monster ate my astronaut.

[Rybags]

Latest, and almost final build.

 

ssp15b.zip

 

 

 

Additions:

 

- Title screen fixed and modified, interlace now working everywhere.

- 8x16 font added universally.

- Animations now stop when scrolling does (when "Bonus 1000" displayed end of round)

- New animation rates generated each time the rocks are renewed.

- New look ship.

 

I don't think I'll do a trainer/lives selector... it kinda spoils the spirit of the game. It's easy to get to 20,000 without losing lives and then the real challenge begins. I've got about 27,000 best score.

 

To do:

That's pretty close to finished. Want to find that nasty bug from the original that's still here, doesn't clear the UFO XPos when you shoot it and it can sometimes momentarily appear the next time around in the middle of screen and kill the player.

I was going to do some new sound FXs, but just too much work and I only really wanted to change the UFO sound, so might leave that alone.

[Rybags]

Stelr480i.zip

 

Final release (hopefully).

 

- Annoying bug in original game where UFO sometimes flashed onscreen and killed player fixed.

- Altered loading sequence so the game should now work with any DOS.

 

To reiterate - game looks/works much better on real hardware... or try the Atari++ release that supports interlace.

Edited August 5, 2009 by Rybags

[Rybags]

I should also mention... this game would probably convert fairly easily to the 5200 if anyone was interested.

 

Probably looking at a 16K cart job... just leave the main code down ~ $2000 - $3FFF, practically all of the extra stuff I've done could sit in the ROM area.

[_Fandal_]

Stelr480i.zip

 

Final release (hopefully).

 

- Annoying bug in original game where UFO sometimes flashed onscreen and killed player fixed.

- Altered loading sequence so the game should now work with any DOS.

 

To reiterate - game looks/works much better on real hardware... or try the Atari++ release that supports interlace.

 

Nice conversion!!

 

But I noticed there is some garbage on the screen for one or two frames when you return to the ship. Check the screenshot. This short screen blinking is in original version as well. I just wonder if it can be fixed...

 

F.

[Rybags]

Yes, noticed on both original and mine. Happens when you start game, transition after game over, level ups etc.

 

The game seems to momentarily disable NMIs for short times, even after initialising. I did a build with it taken out, for some reason it caused all sorts of corruption... probably half-baked vector, who knows.

 

Decided to just leave as it is... a bit annoying but doesn't affect gameplay.

 

I also notice some graphical glitches near the rocks at times... can't seem to ever get the ship to collide with them, so I'll write that one off as another annoyance that doesn't seem to affect it.

 

The game also has dodgy collison detection for the shots. Occasional hits stop the bullet but don't kill the rock. Occasionally you can shoot your mother ship, and it will pick off a random rock or even the UFO.

Edited August 6, 2009 by Rybags

[luka]

just pure atari, prima

[tjb]

As it turns out... I was going to do 4 x 16 individual animations, but the game's rocks are just 2 big/2 small with the second of each just turned 90 degrees.

 

So, I thought, since most of the time, each rock will be at some different angle, I just did 16 animations of each big/small.

 

So for each frame you have 8 individual images right (pre-shifted)? Just out of curiousity how much space does the image data take up? I'm curious because a large chunk of space it taken up for image data in my Rasteroids game.

 

tjb

[Rybags]

Hi tjb... I was wondering about that game when I was doing this. I remember trying to convince you that rotating rocks would look great, and I think this confirms it.

 

Just compare arcade Asteroids vs Deluxe in MAME.

 

My mod isn't quite so sophisticated as you might think. The game by default doesn't really render any softsprites, it's all just a few custom characters and HScrol settings for the 7x2 rows for the asteroid field.

 

The game uses 2 characters for 2 different small rocks, 8 characters for 2 different big rocks.

 

All I have done is use 4 character sets, which gives the possibility to have 16 different shapes onscreen at once. Actually, it's 8 character sets since we're doubling up to provide the extra data for interlace.

 

Each VBlank, I do the animation for 4 rocks in a rotating sequence. That load-balances the CPU somewhat. Problem with this game is that it does all the ship-related stuff in the main loop, with delay loops instead of relying on VBlank timing, so doing lots of stuff just upset that too much.

 

So, by doing it the way I am, at most you need 4 animation changes in a frame which equates to moving 160 bytes around.

 

We have 7 rows of rocks... I've just repeated the use of character sets... if you look real carefully you can pick out which 3 are used twice.

 

Total RAM use for the big rocks is 1K - 4 characters x 8 bytes x 2 chsets (for interlace) x 16 rotation phases.

That data is then copied when needed into the 4x2 character sets (8K).

 

Little rocks use 256 bytes for the animation data.

 

For added speed, I use 5 subroutines. 4 to cover the pages the big rock data lives on, 1 covers all the small rock possibilities. All that is table-driven and there's 2 self-modified JSRs to call them.