Jump to content
  • entries
  • comments
  • views




  • Nathan's sent in a test of one of the large asteroids with line-by-line shifting. It's purdy!
  • Beginnings of a 2-player competitive mode. It's functional, but there's still more work to be done.
  • Revised init wave routines so asteroids shouldn't start on top of the player's ships
  • Revised respawn routine, there's now 5 different locations a player can respawn at - this was added because of the new 2 player mode.
  • New temporary immunity when ships respawn. The ships will cycle their luminance for the duration of immunity.
  • Fixed the collision detect bug.

Can you tell which asteroids are using the new image?


Note: For testing, set Left Difficulty to A to make the asteroids rotate in place. Note that "next wave" detection requires the asteroids to be moving, so switch it back to B if you've shot all the stationary asteroids.



New PLAYERS option



Fights start in opposing corners




To track down the collision detect bug, I modified the program so the 2nd joystick would move a missile and the score was used to show collision info.


Shot next to ship, no collision expected



Shot correctly colliding with ship



Shot next to ship, no collision expected



Shot not colliding with ship, it should be.



The problem turned out to be that the collision routines did not use the Y Adjustment values. Images like the ship are drawn using 16 rows, but not all 16 rows are actually used. Here are the facing up and facing down images:

	.byte zz___X____ ; 0
	.byte zz___X____ ; 1
	.byte zz___X____ ; 2
	.byte zz___X____ ; 3
	.byte zz__XXX___ ; 4
	.byte zz__XXX___ ; 5
	.byte zz__XXX___ ; 6
	.byte zz__XXX___ ; 7
	.byte zz__XXX___ ; 8
	.byte zz_XXXXX__ ; 9
	.byte zz_XXXXX__ ; 10
	.byte zz_XXXXX__ ; 11
;		.byte zz________ ; 12
;		.byte zz________ ; 13
;		.byte zz________ ; 14
;		.byte zz________ ; 15
Ship_NoFlame0Height = * - Ship_NoFlame0

;		.byte zz________ ; 0
;		.byte zz________ ; 1
;		.byte zz________ ; 2
;		.byte zz________ ; 3
	.byte zz_XXXXX__ ; 4
	.byte zz_XXXXX__ ; 5
	.byte zz_XXXXX__ ; 6
	.byte zz__XXX___ ; 7
	.byte zz__XXX___ ; 8
	.byte zz__XXX___ ; 9
	.byte zz__XXX___ ; 10
	.byte zz__XXX___ ; 11
	.byte zz___X____ ; 12
	.byte zz___X____ ; 13
	.byte zz___X____ ; 14
	.byte zz___X____ ; 15
Ship_NoFlame16Height = * - Ship_NoFlame16

In the facing up image, the last 4 rows are blank so they aren't stored in the ROM (semicolons ; tell the compiler that what follows is a comment, so even though we can see them, the compiler ignores them). In the facing down image the first 4 rows are blank, so likewise they aren't stored in the ROM. By leaving out the blank rows, the player (TIA sprite) is freed up for reuse 4 scanlines sooner on the upward ship and likewise the player can be used to draw something else during the first 4 scan lines of the downward ship. A Y adjustment table is used to control skipped rows at the start of the ship. (The image height is used to control skipped lines at the bottom). The Y adjustment table has this for this ship:

	.byte 0 ; Ship_NoFlame0
	.byte 0 ; Ship_NoFlame1
	.byte 0 ; Ship_NoFlame2
	.byte 1 ; Ship_NoFlame3
	.byte 2 ; Ship_NoFlame4
	.byte 3 ; Ship_NoFlame5
	.byte 5 ; Ship_NoFlame6
	.byte 4 ; Ship_NoFlame7
	.byte 3 ; Ship_NoFlame8
	.byte 3 ; Ship_NoFlame9
	.byte 2 ; Ship_NoFlame10
	.byte 2 ; Ship_NoFlame11
	.byte 2 ; Ship_NoFlame12
	.byte 3 ; Ship_NoFlame13
	.byte 3 ; Ship_NoFlame14
	.byte 3 ; Ship_NoFlame15
	.byte 4 ; Ship_NoFlame16
	.byte 3 ; Ship_NoFlame17
	.byte 3 ; Ship_NoFlame18
	.byte 3 ; Ship_NoFlame19
	.byte 2 ; Ship_NoFlame20
	.byte 2 ; Ship_NoFlame21
	.byte 2 ; Ship_NoFlame22
	.byte 3 ; Ship_NoFlame23
	.byte 3 ; Ship_NoFlame24
	.byte 4 ; Ship_NoFlame25
	.byte 5 ; Ship_NoFlame26
	.byte 3 ; Ship_NoFlame27
	.byte 2 ; Ship_NoFlame28
	.byte 1 ; Ship_NoFlame29
	.byte 0 ; Ship_NoFlame30
	.byte 0 ; Ship_NoFlame31


Because it wasn't using the Y adjust value, the collision detection routine was off by 4 rows for the downward facing ship.



ROMs for Harmony or Stella 3.7.1 or later




Edit: test of new 2x vector sprites. It also fixes the invisible ship bug that Omegamatrix found.



Edit: latest version of the first 2x asteroid.






Recommended Comments

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
Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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...


Link to comment

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.

Link to comment

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?

Link to comment

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 :ponder:

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment
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.

Link to comment
Add a comment...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    • No registered users viewing this page.
  • Create New...