Space Rocks (2600)

[iesposta]

"Will this be the first full-fledged game release to harness the harmonious beyond?"

 

Cherity is a Melody-enhanced game and features the ability to save high scores to the cartridge.

Requires Melody.

I'd call that "beyond" although Space Rocks running game logic in the cartridge might be a first.

If you can put in in an unmodified Atari and play, it is within the capabilities of an Atari 2600.

Space Rocks... the ultimate pew, pew, pew, pew.

Edited October 24, 2012 by iesposta

[Cebus Capucinis]

I agree! Random Terrain has a great article about it, and I think he explains it best. Since companies were introducing chips that enhanced the 2600's capabilities back when the console was new, I think things like Space Rocks still fit in the realm of "capabilities" for the system. If you can plug the cart in the slot of a completely unmodified console and play, it's still "good ol' 2600" to me!

[Keatah]

Can you link me to the article?

[Keatah]

I see a whole new breed of remakes and updated ports coming. Especially if using an external processor set-up is less tedious to program.

[+SpiceWare]

Will this be the first full-fledged game release to harness the harmonious beyond?

 

Maybe, maybe not

[+SpiceWare]

Can you link me to the article?

 

RT posted a link to his article in this topic.

 

A reply in that topic by eshu sums up my view - "It's homebrew.....hardware....."

Edited October 24, 2012 by SpiceWare

[BigO]

Maybe, maybe not

Thanks, that helps heaps in an obfuscatorially nondisambiguative sorta way.

At least you narrowed it down to two simple indefinitive options.

Edited October 25, 2012 by BigO

[+SpiceWare]

New build available in my blog entry menu updates. Thomas Jentzsch and Nathan Strum have helped me to free up some ROM space, so I'm going to squeeze in a few more changes before posting the next Release Candidate.

[+SpiceWare]

Thomas Jentzsch and Nathan Strum helped me free up some ROM for one final round of new features to Space Rocks! Many thanks guys

• Menu revisions including revised font, easier to use CONTROL option and updated KIDS option
  
• revised vertical screen-wrap, and did a fix to the top-border collision-detection
  
• Changed LUMA range of multi-color asteroids so they're slightly brighter - should help out if you had trouble seeing dark grey asteroids
  
• respawned ship is always facing upward during 1 player at a time games, for concurrent games the ship will still appear with a random heading
  
• shorter shield duration
  
• longer end-of-game delay before returning to main menu
  

CONTROLLER option is tied to PLAYERS

 

Updated KIDS option. Besides unlimited shields, KIDS option now turns on Friction, sets Bonus Life to 5K and disables Magna-Mines.

 

Screen-wrap of large objects (smaller objects still go fully off screen before reappearing).

 

A lot of things where changed during the optimizations, so please let me know right away if something isn't working correctly. Thanks!

 

Release Candidate 5 ROMs - Harmony or Stella¹

spacerocks20121110_NTSC.bin

spacerocks20121110_PAL.bin

 

¹ Requires Stella ver 3.7.1 or later. See first post for instructions on how to reduce flicker.

Edited November 14, 2012 by SpiceWare

[+SpiceWare]

I've had a report of the saucer/ufo hiding out in the "vertical wrap zone" for about half the width of the screen. I've taken a look to see what can be done, but it's going to take more ROM space to change the saucer movement logic than I have left.

 

If anybody else encounters this, please let me know and I'll see what I can do to make room for the fix. If nobody else encounters it then I'll assume it's just a rare occurrence that I don't need to worry about.

[BigO]

I haven't played it a lot, but twice now, I've seen what looked like a collision detection quirk. When a small-ish asteroid is passing near the ship, at the nose of the ship, while rotating the ship, I've seen the foremost,say, 1/4 of the ship and the asteroid occupy the same space at the same time without the ship being destroyed. If I could be more specific, I would.

 

Having said that, it's a very minor thing. Overall, this game falls under the description that I've used for games like you and some others write: "Way better than the 2600 was meant to be".

Edited November 11, 2012 by BigO

[+SpiceWare]

I haven't played it a lot, but twice now, I've seen what looked like a collision detection quirk. When a small-ish asteroid is passing near the ship, at the nose of the ship, while rotating the ship, I've seen the foremost,say, 1/4 of the ship and the asteroid occupy the same space at the same time without the ship being destroyed. If I could be more specific, I would.

 

I've been trying to recreate this, but my ship gets destroyed without fail. Does it happen all thetime, or just occasionally? If occasionally are you able to trigger it at will? Seeing it happen may help, can you make a video recording of it?

[Thomas Jentzsch]

Two remarks for the menu:

I think the graphic for COLOR should be shifted one pixel right. Also the gap between the ship and the asteroid for STYLE could be decreased

 

Though both changes would require a few extra bytes...

[KevinMos3]

Would the option for a white or light-gray ship be out of the question?

[+SpiceWare]

Two remarks for the menu:

I think the graphic for COLOR should be shifted one pixel right. Also the gap between the ship and the asteroid for STYLE could be decreased

 

Though both changes would require a few extra bytes...

 

Yeah, the graphic for color should go to the right a pixel - or I could add another pixel or 2 to the right side of the image for the same effect. I don't think I'd need extra ROM for either.

 

Depending upon how far the ship is shifted, changing STYLE would need either 7 or 14 bytes. As such, I don't foresee changing STYLE as if I end up freeing up more space it'll be to fix the saucer issue that iesposta brought up. I haven't seen it myself yet, so I don't know if it's a common occurrence that needs to be fixed, or something that rarely happens.

 

 

Would the option for a white or light-gray ship be out of the question?

 

If you move RIGHT (or FIRE) once on the COLOR option you'll get the greyscale palette

 

 

NOTE: if you're using the PAL ROM you need to tell Stella to use the PAL60 palette. If you don't, you won't be able to select the greyscale palette. You can tell if that's the case because the menu will have the wrong colors as seen below. It should have blue option names as seen above.

[Thomas Jentzsch]

Depending upon how far the ship is shifted, changing STYLE would need either 7 or 14 bytes. As such, I don't foresee changing STYLE as if I end up freeing up more space it'll be to fix the saucer issue that iesposta brought up.

Agreed, those fixes should have priority.

 

BTW: I think you can overlap parts of the new graphics.

 

EDIT: Found some bytes:

- Option2players1stick = ControlF (7 bytes);

- ColorC and FrictionD can be partially overlapped (4 bytes)

 

More if you need them.

Edited November 12, 2012 by Thomas Jentzsch

[KevinMos3]

If you move RIGHT (or FIRE) once on the COLOR option you'll get the greyscale palette

 

Yeah, I've used the color options before (my personal preference is default with solid objects), but I was thinking of an option to change the color of the ship separately from the asteroids -- so it could look like the old 2600 game or even green like that one label design or whatever.

 

Or... just a single additional option added to the existing color options with white/light gray ship and colored asteroids. (pardon me... "space rocks")

 

I'm not suggesting I don't like the purple, just that it would be nice to play with the colors I'm more used to if the cost is not too high.

Edited November 13, 2012 by KevinMos3

[+SpiceWare]

Gotcha. Yeah, the cost is too high. I've been looking at what I can do to squeeze in a fix for the saucer issue. There's 10 bytes free in the ARM section, but I need 20. I've got about 15 bytes scattered around the 6507 code and Display Data, but its quite difficult to consolidate as they're all over the place due to data alignment requirements.

[+SpiceWare]

Agreed, those fixes should have priority.

Turned out I could just shift the ship image 3 pixels left then swap it and the space. It also ended up saving some ROM in the ARM code as I was still updating the space when showing the solid vector.

 

I was also able to overlap the menu graphics enough to shift things around and put the saucer fix in place. It'll get posted when I select the label and update the "label by" in the easter egg.

Edited November 13, 2012 by SpiceWare

[+SpiceWare]

Hmm - saw some sprites "jump around" near the top edge of the screen while testing the saucer fix. I haven't figured out what's causing it yet as I've only seen it three times. Hopefully it doesn't take long to track down this new bug.

Edited November 13, 2012 by SpiceWare

[BigO]

I've been trying to recreate this, but my ship gets destroyed without fail. Does it happen all thetime, or just occasionally? If occasionally are you able to trigger it at will? Seeing it happen may help, can you make a video recording of it?

I've tried to reproduce it. It doesn't happen all the time, so might be really difficult to track down.

I can say that I was rotating the ship at the time and I'm pretty sure the nose was rotating with the direction of travel of a smallish asteroid that (didn't) hit the ship. I'll try to see if I can get it to happen and pay more attention to the circumstances. I think there were a lot of asteroids on the screen at the time, but wouldn't swear to that now.

 

It was on real hardware/Harmony cart (in case there's any other option).

[Keatah]

I haven't played it a lot, but twice now, I've seen what looked like a collision detection quirk. When a small-ish asteroid is passing near the ship, at the nose of the ship, while rotating the ship, I've seen the foremost,say, 1/4 of the ship and the asteroid occupy the same space at the same time without the ship being destroyed. If I could be more specific, I would.

 

Would you say like gears meshing? Is the direction of rotation of the ship or rock or both important? Does the ship need to be in motion or stationary? Solid or wireframe? What level? Colors? Any of this important?

 

I'm trying to dupe this, but so far no luck.

[Keatah]

Alright. I did duplicate this. It happened 2x out of perhaps 40 expected collisions. I just played the stock default game, continually rotated right and waited. I didn't thrust or anything, sit'n'spin, you know. I don't think I fired anything. The saucer was not yet onscreen IIRC. First time it was a purple rock and it blew right through me like a ghost. It seemed perfectly lined up. By that I mean it passed through the center of me. I don't think the nose of the spacecraft was pointing toward it. In fact I don't recall the position at all. It was a fast-mover, but slow rotator I think. Same rotation direction as my ship. This one originated from the 5 o'clock position, blew through me and exploded just prior to going off-screen. Never seen that! And then another rock blew me up.

 

The other time, it was a white mid-size rock, off axis and not aimed toward the ship's centerpoint. medium speed, medium rotation. I don't recall the rock's rotation direction. This one didn't blow up.

[+Nathan Strum]

The rock blowing up just before going offscreen was likely a collision with a saucer coming in from the same location. I've seen that before where it will actually blow up before you see the saucer.

[Keatah]

You know what..? I bet there's nothing wrong with the collision detection. Isn't this a normal behavior? It takes the ship a few moments to finish rezzing-up or materializing after it gets all blowed up from a previous collision. And during that time it's an opportunity for U to get away from impending doom. It also flashes various brightness levels as it does this. Takes a few seconds to totally solidify. I bet that's what we're seeing.

 

I find it odd that a game would progress this far and still have a fundamental problem such as collision detection. But hey man. Let's get everybody on the case just to be absolutely sure.

 

I made these save states from Stella 3.7.4.. states(spacerocks20121110_NTSC.bin).zip

ST0 - the ship finishes rezzing up and materializes fully while a rock is over it, BOOM!

ST1 - the ship is *not* finished rezzing, and thus the rock goes right through you.

If you watch closely, you'll see the brightness of the ship flickering, indicating you have a few moments to "get away now".