TROGBlog

For SpaceWar 7800 I used 24 rotations, which seemed to work out fairly well.

I'll probably have to stick with 16. That's how many are used in asteroids, and most games for the Atari, and it works well. The limiting factor isn't the math, or even memory. Using trig tables, it's trivial to add more rotation positions. The limiting factor is the graphics. The spaceship has to fit in an 8 by 8 pixel display, and it's tough to rotate the image and still have something that looks like a spaceship (as opposed to, say, a squashed bug.) This problem is compounded by the fact that pixels in the 2600 are rectangular rather than square.

 

I'm really happy with the graphics for the current 8 positions of the ship in the game, and spent a good hour or so fine tuning them. But then I spent another hour trying to make the 22 degree diagonals, and they all look like crap. If anyone would like to submit their own rendition of a 22 degree diagonal ship that matches the style of the current ship, if I use it, you'll get honorable mention in the game manual.

Yeah, for SpaceWar! 7800 I used the 320x200 mode and 16x16 sprites.

 

What you might want to try to do is draw your sprites at a higher resolution using vector graphics (rather than rotating the low-res bitmaps), then scale them down & clean up.

The spaceship has to fit in an 8 by 8 pixel display, and it's tough to rotate the image and still have something that looks like a spaceship (as opposed to, say, a squashed bug.)

 

If anyone would like to submit their own rendition of a 22 degree diagonal ship that matches the style of the current ship, if I use it, you'll get honorable mention in the game manual. 

 

8x8 is a bit tough. Any chance of making it a few pixels taller?

 

Hey Nathan,

 

Thanks! That's a nice graphic. I'll try coding them up and see how they look.

 

I could go to 8 x 10, but I wouldn't want to go any larger. My original intent was to use 8 height, and only about 6 pixels width to keep the proportions consistent.

 

What tool do you use to make your gif animations?

Photoshop for creating the individual frames (it allows me to set a pixel aspect ratio that mimics the 2600), then I work in ImageReady to build and refine the animation. ImageReady doesn't support custom aspect ratios, so I have to temporarily double the image width (using Nearest Neighbor sampling) to check how things will look.

 

Here's an 8x10 version of the ship:

 

I think that works a little better.

 

And the frames for both versions, if you need 'em:

http://www.cheeptech.com/misc/ship_frames.zip

 

(I guess I didn't need to include all sixteen frames, since there are only 5 unique ones. The rest are mirrored and/or flipped.)

I seems that the center of the ship is moving. Shouldn't that be compensated?

It's not the center - the cockpit window is set towards the back part of the ship. It makes for a kind of an unfortunate optical illusion, but you wouldn't see the ship spinning constantly like that in the game anyway.

It's not the center - the cockpit window is set towards the back part of the ship. It makes for a kind of an unfortunate optical illusion, but you wouldn't see the ship spinning constantly like that in the game anyway.

 

Be that as it may, it may be advantageous to make the cockpit be the center of rotation (using a +/- 1 pixel nudge on the display XY positions).

Be that as it may, it may be advantageous to make the cockpit be the center of rotation (using a +/- 1 pixel nudge on the display XY positions).

 

I think I see what you mean... in the game the ship's position would change slightly depending on its rotation, right?

 

So the frames would look like this:

 

I think I see what you mean... in the game the ship's position would change slightly depending on its rotation, right?

 

So the frames would look like this:

 

 

Precisely. One important aspect of game design that's sometimes overlooked (e.g. in Lunar Lander) is picking a reasonable and consistent center of rotation. For that space ship, the cockpit is probably a good choice. Not only does making that be the center avoid any ugliness if the player spins the ship in place, but it's probably not too far from the axis about which the ship would spin if opposite-side engines applied reverse thrust. The principle is similar to that of aligning running-frame animations so that people actually run rather than shuffle-footing (btw, was Pitfall the first game to really do that, or did any game on any system do so?)

I think I see what you mean... in the game the ship's position would change slightly depending on its rotation, right?

 

So the frames would look like this:

 

Yup, that looks much better.

It's also a cool workaround of hardware limitations, with the animation then being 9 or 10 pixels wide instead of 8

Nice work there Nathan. Thanks for your help. I'll be busy the next couple days with non-Atari activities, but I'll get this coded up as soon as I can.

 

My pixel maps for this kernel are a pain. I have to split the graphic tables into odd and even rows. I'll probably write up a small perl program to do that for me. It's tedious work for 16 sprites, and I'll likely be doing a similar odd/even algorithm for Battle of Midway.

My pixel maps for this kernel are a pain.  I have to split the graphic tables into odd and even rows.  I'll probably write up a small perl program to do that for me.  It's tedious work for 16 sprites, and I'll likely be doing a similar odd/even algorithm for Battle of Midway.

 

Actually, there are only 5 unique sprites. The rest are flipped or mirrored or both.

 

 

Not sure if that will help or not, but maybe it can save you some work.

 

And here are all 16 frames, as .bmp files. (John said those are easier to convert into sprite data.)

http://www.cheeptech.com/misc/sf_ship_10_frames.zip

Actually, there are only 5 unique sprites. The rest are flipped or mirrored or both.

http://www.cheeptech.com/misc/sf_ship_10_frames.zip

 

The vertical one looks too narrow. Would it be too wide if you made it 7 pixels? The body of the near-vertical diagonal one is almost 7 pixels wide.

 

Also, do you know if there are any command-line utilities that will easily convert a graphics file with a small number of colors into a text file (one line/row) and/or a "raw" RGB file? Could be very handy as part of a toolchain.

Also, do you know if there are any command-line utilities that will easily convert a graphics file with a small number of colors into a text file (one line/row) and/or a "raw" RGB file?  Could be very handy as part of a toolchain.

 

Oh, I thought I already told you that, it can be found here

The vertical one looks too narrow.  Would it be too wide if you made it 7 pixels?  The body of the near-vertical diagonal one is almost 7 pixels wide.

 

Also, do you know if there are any command-line utilities that will easily convert a graphics file with a small number of colors into a text file (one line/row) and/or a "raw" RGB file?  Could be very handy as part of a toolchain.

 

My guess is it'd be too wide. But I can play around with it later and see. I think overall it works pretty well now.

 

John (Champeau) is working on a conversion tool for LadyBug to convert .bmps into sprite data. I don't know how it differs from the one Manuel uses, but hey - now there's two.

Oh, I thought I already told you that, it can be found here

 

I didn't mean convert to a data file. I was thinking of something that would produce a file something like

--1111--
-121121-
-111111-
-113311-
-111111-
-141141-
-114411-
--1111--

I like to use Qbasic or C programs to munge things into data tables for the 2600, but often do so in ways that render other tools not quite suitable. I can "sort of" read monochrome or 24-bit .bmp files okay, but sometimes monochrome bitmaps aren't really enough while 24-bit is overkill, and sometimes it's nice to be able to examine things as text. A command-line utility which could take care of the necessary preprocessing would be handy.

You could run a perl script over the output from PCX2GRP transmogrifying the color and shape data it produces into whatever form you prefer. Of course, the example you give won't work, as it uses more than one color per scanline.

 

Of course, you can also run a perl script over plain PCX or BMP data as well.

 

Third you can adopt Eckhards tool to any output you want it to, since he included the source

My pixel maps for this kernel are a pain.  I have to split the graphic tables into odd and even rows.  I'll probably write up a small perl program to do that for me.  It's tedious work for 16 sprites, and I'll likely be doing a similar odd/even algorithm for Battle of Midway.

 

Is that because you don't have a line-counter matching the resolution of the sprites? You may consider using FlipDraw then, as it doesn't require a line-counter