SpiceWare's Blog

I don't want to poop on your head and make you take your ball and go home, but I thought I would be honest and say that the asteroids look more like chewed up bubble gum to me than asteroids:

 

http://www.randomterrain.com/games/asteroids/index.html#top

 

I probably couldn't do any better. All I know is that the shapes need more work.

I don't want to poop on your head and make you take your ball and go home, but I thought I would be honest and say that the asteroids look more like chewed up bubble gum to me than asteroids:

 

I probably couldn't do any better. All I know is that the shapes need more work.

 

• Nathan's sent in a test

Those do look nice, but you are comparing asteroids that are 68 pixels across with ones that are 8 pixels across.

Very well done for a test I'd say.

 

I'm not sure if Random's comment is refering to both shifted and non-shifted rocks but I do see a vast improvement between the two on many of the still frames (I'd post some example snap shots - but there seems to be no way to post them here ). Although the shifted rocks have 24 positions compared to 32 for the non, there's barely any noticable difference in the number of positions while both rocks are rotating at the same frame rate as I see it.

 

I would suggest that the rotation frame rate for some of the rocks be speeded up because it does help eliminate any noticable difference in the number of positions, and those rocks will look and animate so much smoother too.

Those do look nice, but you are comparing asteroids that are 68 pixels across with ones that are 8 pixels across.

 

I wasn't comparing directly, just trying to figure out how your asteroids could look more like asteroids and less like chewed bubble gum. After looking at it one more time, I think it's because they're not keeping enough of their shape as they spin. The shapes change too much, so it doesn't have a pleasing feeling to the eye.

We had to drop the frame count due to space issues. At 32 frames it would take 6K for both large asteroids. At 24 frames it takes 4.5K. The 32 non-shifting asteroids all shared the exact same 32 byte shift table.

 

I'm holding off on adjusting the rotation speeds until all the asteroids are done as the frame counts are not finalized.

After looking at it one more time, I think it's because they're not keeping enough of their shape as they spin. The shapes change too much, so it doesn't have a pleasing feeling to the eye.

Missed this before, must have shown up while I was commenting about the 32 vs 24 frames.

 

I had a similar realization about "inconsistency" with the 2x sized sprite. Namely I realized that the thickness of a specific point on the edge of the asteroid changes as it rotates. When the point is on the left/right edge it's 2x in size, but when it's on the top/bottom edge it's just 1x in size.

 

I revised the vector converter so that the top/bottom edge is now 2x and sent Nathan a new build. I've attached that test build to the blog entry so we can see if it addresses what you're seeing.

Played the updated build. The new 2x large rocks look better now.

 

I see you implemented the temporary immunity from the 7800 version along with the competitive mode. Good idea! That would help during competitive mode so players won't get snuffed out immediately when their next ship comes into play.

That it does. There's still some distortion during rotation, but that's to be expected when the horizontal resolution is 1/4 that of the vertical resolution (8x32 images are used for the large asteroids). Same thing happens with the smaller asteroids as well, but it's only 1/2 the resolution, so it's not as bad (8x16 for the medium and 4x8 for the small).

 

Does it? I've only read the manual for the 7800 version, hadn't played it in competitive mode. From the manual I got the Both players are supplied with ships as long as either player has ships in reserve(this is in place, but not in the posted builds) as well as the scoring of 500 points. I added the temporary immunity because sometimes I'd respawn in front of a fast moving asteroid and not have enough time to react. I don't like games with cheap deaths like that.

Observation: In B&W, shields pulse color.

Discussion: Purist says, " It should all be grayscale." Gamer says, "It's a feature! If you don't like it, turn down the color on your TV!" Purist says, "I'm playing it in emulation, there is no color adjustment."

... Play it on real hardware...

... Okay, tried that, my DLP projector won't take out all the color...

...

Thanks, hadn't tried shields since adding the color option.

I spent a couple of days trying to make an asteroid that looks less like chewed up bubble gum, but this is the best I could do:

 

 

It's just too hard to do in the limited space.

Hmm... I wonder what it would look like if you draw the original vector asteroids on an 8x32 grid at the 24 rotations. The point is to not try to rotate a 8x32 base image but to effectively downsample a higher resolution image.

 

From a space perspective are you storing all rotations or only the first quarter turn and then using reflections?

I'm pretty sure that's what Nathan is doing, though there is some extra work involved with the line-by-line shifting to make it look smoother.

 

Perhaps Nathan will expound upon his technique in a future blog update

Hmm... I wonder what it would look like if you draw the original vector asteroids on an 8x32 grid at the 24 rotations. The point is to not try to rotate a 8x32 base image but to effectively downsample a higher resolution image.

 

I'm tracing the original arcade game vectors at 16x32, rotating it 15° for each frame. Then going through line-by-line and hand tweaking them so they're an even number of pixels, so they can then be converted to 8x32 with rows shifted. It's a pretty very laborious process.

 

There are two rocks we're using - the one I've been working on using row-shifting is one of the three rocks from Asteroids:

 

 

The end result (as of this morning):

 

 

The other is the one which they re-used in Asteroids Deluxe (which hasn't been updated with row shifting yet):

 

 

 

So I'll work on revising that one next. That will be the harder of the two, since it's so lumpy. But I think it's too iconic not to use.

 

I suppose I could put together a blog entry on it. Haven't done one on game graphics in quite some time.

From a space perspective are you storing all rotations or only the first quarter turn and then using reflections?

 

Wouldn't work - the rocks are asymmetrical. But when I'm creating the sprites I'm only making the first 12 frames, then duplicating and rotating them 180° for the rest. I don't think that saves Darrell any space though.

 

That's looking less like chewed up bubble gum and is keeping most of its shape as it spins.

From a space perspective are you storing all rotations or only the first quarter turn and then using reflections?

 

All rotations are stored. Collision detection in done via software and having all the images readily accessible made that much less complicated.

 

Each image is stored twice, once as the solid asteroid, and again as the vector asteroid. The solid one is used for collision detection.

 

The large asteroids also have a line-by-line HMOVE shift table for each image. The 2 styles with 24 frames takes a little under 4.5K to store because I leave out leading and trailing rows if they're blank. Some overlap of image data can also be done, but I'm not going to worry about that until the final images are in place.

That's looking less like chewed up bubble gum and is keeping most of its shape as it spins.

 

If you squint hard enough, it looks better. Rotating graphics on the 2600 is always challenging because of the low resolution and non-square pixels. Ultimately, it's always going to look 2600-ish, and vector graphics are going to suffer the most. After posting the previous one, Darrell found one of the rows was still wrong (had an odd number of pixels), so I had to revise it again... twice:

 

 

All things considered, I'm pretty pleased with that. There are more tweaks I'd like to make to it that I can't, because they require single-pixel resolution changes - and this is a double-wide sprite.

 

I'm not even worrying about how it turns out as a vector version, since I know that's going to suffer by comparison. So I'm focusing on making the solid version look as good as it can, and then if something horrible shows up in the vector version, I'll look into tweaking it later.

 

The key is - how does it look in-game? When you're playing, you're not staring at the rocks and analyzing how lumpy they are (well... I do, but that's beside the point). As long as they aren't distracting, then I think the animation is successful.

All things considered, I'm pretty pleased with that.

 

Looks much better than what has been in the game so far. The most important thing is for it to keep its basic shape as it spins (like this new one is doing). The older asteroids in the game seem to change drastically as they spin, so they aren't pleasing to the eye. If your newer asteroids will keep their basic shape like this new one, the game will be more fun to play because of the pleasing eye candy.

It'll probably be a while, due to a diversion, before my next Space Rocks blog entry - so I added a build with the latest 2x asteroid so you can see it in action.