VCS: Space Rocks

[igorstellar]

Space Rocks Label Contest

GRANDE MAC!!!
fanne una che poi vince !!!

[SpiceWare]

_the first is the slower, if compared to the original Asteroids, game speed, again

Yeah, I went thru many revisions on speed after watching others get very frustrated with faster game speeds. Does starting with Level = HARD help? Does the game speed up enough to be challenging? I normally get to around 50K, though got up to 70K once.

If you want a bigger challenge there's an easter egg that will start every wave with 12 large asteroids

_the second is that greater asteroids vector shaped (simulated vector mode = on) still turn into solid shape when hit for the very first time

Are you playing via a Harmony cartridge or Stella? If Stella then I suspect you're using an older build of Stella as this sounds like an issue that was fixed in version 3.7.1.

I also see that in the PAL version the B/W mode selection is no longer available (hehe, I already said I'm a fan of the original B/W vector tube display... ).

Hmm, I just tested my PAL build and can select B/W mode.... Ah, I think I know what's wrong - if you're using Stella and didn't tell it the game is PAL60 it will autodetect as NTSC. The menu should be colored like this:
spacerocks20121004_PAL.bin.jpg

If it looks like this then Stella is in NTSC mode and you won't be able to select B/W.
spacerocks20121004_PAL.bin_1.jpg

What's going on is there's 4 instances of B/W in TIA's PAL palette. For NTSC the color selection range is 0-15, for PAL I limited it to 1-13 so there wouldn't be any confusion because of grey showing up 4 times. If you're using the PAL ROM, but Stella's in NTSC mode, then you'll get shades of yellow instead of B/W.

http://www.qotile.net/minidig/docs/tia_color.html

I did up a page at my site, Atari NTSC s PAL vs SECAM, that you might find enlightening.

http://spiceware.org/atari_ntsc_pal_secam.html

OH ! I'd be glad to draw some (good ?) layouts for the cartridge and the box, too, maybe with my "white label series" livery, as I did for the "Arcade series" VCS carts !

Great! looking forward to seeing your contest entries

[MacDLSA]

Darrell, you're "terribly" right !

_First of all, I played in "easy" difficulty level, so I see that in the other harder levels asteroids have more speed (HARD= !). There's no speed-rising while playing on the same game, while this thing happens on the "old" VCS' Asteroids, but I think it's ok because in this way Space Rocks is closer to the original arcade game, cause it also does not have speed-rising !

_Yeah, I'm using Stella (I still do not own an Harmony...), and due to that just mentioned fact "I'm off since..." I did not "update" it.
Now the latest 3.7.2 fixes the "vector-to-solid" issue !

_Way before updating Stella to the latest release before this newest one (I had the 3.4... ) I forgot to change default video settings, so I had phosphor mode = off and TV system = auto-detect... Ok, now it's allright !

[it could be nice to have an add-on hardware for the VCS which could "mix-up" the typical VCS' 2-frame-drawings, as the Stella's phosphor mode does ! I remember I talked with Stephena about a (posssible) Stella's 3-frame-drawing "mixer" for all those games, like Ms.Pac-Man, in whose every image is drawn by THREE single frame instead of the "typical" two .]

_Yeah, I know the differences between PAL and NTSC VCS' TIA processors... Years ago I wrote a little article here on RH just for talkin'bout PAL and NTSC differences, and of course it's all referred to our beloved VCS .

http://www.retrogaminghistory.com/consol-iamoci-vf7/visualizzazione-televisiva-nozioni-di-base-pal-vs-ntsc-vt844.html#post6377

_I got some spare time right now, so I'm goin' to draw "something"... maybe before the end of the week I could send it for the contest !

[SpiceWare]

Hmm, speeds should increase over the course of the game. In looking at the code though it's probably increasing at too slow of a rate to be noticeable:

void PrepSpeedRange(int level)
{
    int i;
    int base_adjust;
    
    base_adjust = MM_LEVEL;
    if (base_adjust)
        base_adjust--;
    
    base_adjust *= 2;
    
//    SPEED_RANGE[0] = (level >> 2) + 4;
//    SPEED_RANGE[1] = (level >> 1) + 4;
//    SPEED_RANGE[2] = level + 4;
//    
//    // defines slowest speed of asteroids
//    SPEED_BASE[0] = (level >> 6) + base_adjust;
//    SPEED_BASE[1] = (level >> 5) + base_adjust;
//    SPEED_BASE[2] = (level >> 4) + base_adjust;
    
    for(i=0;i<3;i++)
    {
        SPEED_RANGE[i] = (level >> (2-i)) + 4;
        SPEED_BASE[i] = (level >> (6-i)) + base_adjust;
        if (SPEED_BASE[i] > 15)
            SPEED_BASE[i] = 15;
        if (SPEED_BASE[i] + SPEED_RANGE[i] > 15)
            SPEED_RANGE[i] = 15 - SPEED_BASE[i];
    }
}

It sets up the range & base (lowest) speed for each of the 3 asteroid sizes based on MM_LEVEL (kids = 0, easy = 1, normal = 2, hard = 3) and level (the "wave" number).

Range is how many speeds it can select from. On the first wave, level = 0, so the range is 4 speeds for each asteroid size. On the second wave level = 1 so the smallest asteroids have 5 speeds to select from, but the other sizes still have 4. On the third wave level = 2 so the smallest asteroids have 6 speeds, medium asteroids have 5, largest have 4. And so on.

Maybe I should adjust the SPEED_BASE calculations so the slowest speeds are dropped off sooner. (level >> 4) is the same as level / 16, so the slowest speed of the smallest asteroids doesn't increase until round 16.... Likewise (level >> 5) is level / 32 and (level >> 6) is level / 64, so the medium base doesn't increase until round 32 and the large asteroids until round 64. Changing it this might be better:

//    // defines slowest speed of asteroids
//    SPEED_BASE[0] = (level >> 4) + base_adjust;
//    SPEED_BASE[1] = (level >> 3) + base_adjust;
//    SPEED_BASE[2] = (level >> 2) + base_adjust;

The smallest asteroids would increase their base every 4th wave, the medium every 8th and the large every 16th.

When asteroids are created, it uses this function to select a random speed and direction:

unsigned char RandomAsteroidMotion(int size)
{
    // returns a random speed & direction based on size of asteroid
    char speed;
    char direction;
    int index;
                
    if (size == LARGE_ASTEROID_SEQ_ID)
        index = 0;
    else if (size == MEDIUM_ASTEROID_SEQ_ID)
        index = 1;
    else
        index = 2;
    
    speed = (SPEED_RANGE[index] * (Random32() & 0xff)) >> 8;
    speed += SPEED_BASE[index];
    speed <<= 4;

    direction = ((Random32() >> 10) & 0x0f);

    return speed | direction;
}

[igorstellar]

mmm
now we go on matters hard for me .....

[Dr_Who]

Darrell , which compiler you use ? I thought you worked in asm

[SpiceWare]

All the game logic is written in C as it runs on the ARM chip in the Harmony/Melody cartridge. The compiler, ARM EABI version, is available here:

http://www.mentor.com/embedded-software/sourcery-tools/sourcery-codebench/editions/lite-edition/

There's still 6507 assembly in there as the ARM chip can't talk to the chips in the 2600, so the 6507 has to run the Kernel (the routines that generate the game display) as well as pass data (joystick readings, sound effects, etc) back and forth with the ARM.

If you care to, you can download the source code for Space Rocks from my blog to see how the 6507 assembly and ARM C code interact:

http://www.atariage.com/forums/blog/148-spicewares-blog/

[Dr_Who]

Stupid that I am Everything is clear, I did not remember that there is the ARM mcu...

[SpiceWare]

Just posted release candidate 4, it has a number of gameplay tweaks such as quickly the asteroid speed ramps up.

http://www.atariage.com/forums/topic/197315-space-rocks-2600/page__st__225#entry2624576

[MacDLSA]

Yeah, Darrell... if I had played it for more than 5 minutes I would have understood that speed increases...
So, I decided (tomorrow morning, for about 1 hour... ) to "throw myself inside" !

Ok, I watched your algorithm of speed changing, and I kinda' compared it with the arcade game (also with the "Deluxe version" which I know much more...) and the origlinal VCS' Asteroids.

So, playin' on the arcade I see, AT LEAST, that it has a very little speed increasing... dunno how it becomes if player go on through the game (I'm not so smart...) but I could assume that Space Rocks match this feature !
Deluxe version's asteroids,magnas and ufos are much more quick (also if the game is dipswitched in easiest difficulty) since the beginning of the game, and my feeling is that speed increasing is less noticeable.

VCS' Asteroids (that uses 8k... I remember an old thread in AtAg in which someone said it was the first "bankswitched" cart) has a MUCH MORE simpler speed-increasing program: it's "time-based" and it means that the more you play the fast are the asteroids... the (bad?) thing is that speed reach its maximum value in the very first one or two "rounds" (or asteroid waves), keeping it for all the game !
Of course, speed is usually "accompanied" by the typical "booz-buzz-booz-buzz" sound that becomes faster as much as the speed increases (and, as I already said before, PAL Asteroids game's buzz sounds much faster than NTSC !)
I use(d) to play it in its 12th variant which offers an "intermediate" challenge (not so easy and not so hard) with the shield instead of the (hated!!!) hyperspace ! [ EVEN difficulty levels stands for "quick" asteroids: when you hit a Large one then the 2 Medium are faster than the respective two when selected ODD levels, and the Small asteroids become much mure faster and with dangerous diagonal directions... ]

Playin' (serious... not as I did before... ) on Space Rocks I immediately think that we're lucky we can have "heavy" bankswitching (32 or more kbytes) modes, nowadays !
The game menu is really great: players could "mix" the features of Asteroids with the others of Asteroids Deluxe...
As I said, it's the arcade-closer version of Asteroids ever seen, and if I had been forced to reduce the program becuse it exceeded the limit (?) of 32k i really don't know where I could put my hands... Maybe on the speedup algorithm... or, if needed, I sure have been "reduced" the main menu with a simple selection between "Space Rocks-variant A" (Asteroids-based, with hyperspace only) and "Deluxe-variant B" (Deluxe-based, with shield and magnas).

Only a consideration, Darrell:
I already said it, but have you considered (if it could stay inside the 32k) the "BOUNCING" ship when shield is turned on and hit by enemies ?

[SpiceWare]

Thanks!

I would have loved to put in shield bouncing, but there's no room for it. Currently I have 32 bytes free, and they're scattered as follows:

14 - bank 0-4 (ARM)
1, 1, 0, 10 - bank 5 (6507 code space, broken up due to code alignment requirements to prevent page breaks that add extra processing time in the kernel).
3 - display data
3 - frequency data

[MacDLSA]

Are 32kbytes enough to print "Game Over" at the end of the game and/or set a kind of "last score / best score" screen (the playfield with score counters and without moving sprites) and alternate it with the main menu ?

[SpiceWare]

32 kbytes yes, 32 bytes no

Last score is shown though, the game does a demo mode that shows them.

[MacDLSA]

32 kbytes yes, 32 bytes no

AARRGGHH !!!
... I am REALLY too old !!!
I wrote "k"...

... mistake... sorry

Last score is shown though, the game does a demo mode that shows them.

I feel myself a little bit fool, recently... yeah, I see the demo and it's great.
Nothing left to say, Darrell... the game is perfect !

Give me some more time and I'll send to you and/or to AtariAge my artwork for the box and labels.

[SpiceWare]

Thanks! Looking forward to your artwork.

Thomas Jentzsch has been working on freeing up space for one last revision, he suggested making the frequency of the shield sound effect correspond to how much shield time remains. That would give you a audio feedback so you could gauge how much shields remain before your ship explodes. We're at 67 bytes so far. It's not enough for the change though, plus it needs to be consolidated into the ARM space.

30 - banks 0-4
1, 1, 19, 10 - bank 5
3 - Display Data
3 - Frequency Data