Jump to content
  • entries
    644
  • comments
    2,542
  • views
    863,576

step 9 - Game Variations

SpiceWare

1,589 views

It's common for Atari games to have a number of game variations. To simplify the logic, the variations are usually driven by individual bits and/or groups of bits within a single byte that holds the game variation. A good example of that would be Space Invaders - check out the game matrix from the manual:

blogentry-3056-0-28751000-1404959852_thumb.jpeg

 

A byte is comprised of 8 bits, usually numbered 0-7 where 7 is the leftmost bit as in 76543210.

 

For Space Invaders the bits in the game variation are used in this fashion:

  • 7 - not used
  • 654 - selects 1 of 7 player variations
  • 3 - Invisible Invaders
  • 2 - Fast Bombs
  • 1 - ZigZagging Bombs
  • 0 - Moving Shields

Humans start counting at 1, but computers start at 0, so if you select game variation 12, internally it's really 11. 11 in binary is %00001011, which means bits 0, 1 and 3 are all turned on so the game variation has Invisible Invaders, ZigZagging Bombs and Moving Shields. You can confirm that by looking at column 12 of the Game Matrix above.

 

With this update to Collect, we're using bits 1 and 0 to give us 4 game variations:

  • 765432 - not used
  • 1 - Arena 1 or 2
  • 0 - # of players

If we have space at the end of the project I plan to add some additional arenas. If we can add 2 more we'd just start using bit 2 and let the game Variation go from 1-8

  • 76543 - not used
  • 21 - Arena 1, 2, 3 or 4
  • 0 - # of players

If we can add 6 more we'd add bit 3 and let the game variation go from 1-16

  • 76543 - not used
  • 321 - Arena 1, 2, 3, 4, 5, 6, 7 or 8
  • 0 - # of players

The ProcessSwitches routine has been modified so that hitting Select will increment the new variable Variation. It will also limit Variation to only the values 0-3. After changing Variation, the left score will be set to show Variation+1 as Humans prefer to see 1-4 instead of 0-3. The Right Score will be used to show the # of players, either 1 or 2.

 

NotReset:        lsr             ; D1 is now in C        bcs NotSelect   ; if D1 was on, the SELECT switch was not held        lda #0        sta GameState   ; clear D7 to signify Game Over                ldx Variation   ; Get the Game Variation        inx             ; and increase it        txa             ; transfer it to A        and #%00000011  ; limit Variation to 0-3        sta Variation   ; save it        tax             ; transfer it to X        inx             ; and increase it by 1 for the human readable varation 1-4        stx Score       ; save in Score so it shows on left side        ldy #1          ; default to showing 1 player variation         lsr             ; D0 of Variation, # of players, now in Carry flag        bcc Not2        ; if Carry is clear, then show 1 player         iny             ; else set Y to 2 to show 2 playersNot2:        ror Players     ; put Carry into D7 for BIT testing of # of players        sty Score+1     ; show the human readable # of players on right sideNotSelect:        rts

 

The routine works, but when Select is pressed the game variation will rapidly change making it difficult to select a specific game variation. You can see that in this build:

collect_20140709_nodelay.bin

 

To fix that, we'll add a SelectDelay variable so that holding down SELECT will only result in Variation changing at the rate of once per second. However, if the user rapidly presses/releases SELECT then Variation will also rapidly change.

ProcessSwitches:        lda SWCHB       ; load in the state of the switches        lsr             ; D0 is now in C        bcs NotReset    ; if D0 was on, the RESET switch was not held        jsr InitPos     ; Prep for new game        lda #%10000000          sta GameState   ; set D7 on to signify Game Active          bne NotSelect   ; clear SelectDelay        NotReset:        lsr             ; D1 is now in C        bcs NotSelect   ; if D1 was on, the SELECT switch was not held        lda #0        sta GameState   ; clear D7 to signify Game Over                lda SelectDelay ; do we need to delay the Select switch?        beq SelectOK    ; if delay is 0 then no        dec SelectDelay ; else decrement the delay        rts             ; and exit the subroutine        SelectOK:        lda #60         ; Set the Select Delay to 1 second        sta SelectDelay ;        ldx Variation   ; Get the Game Variation        inx             ; and increase it        txa             ; transfer it to A        and #%00000011  ; limit Variation to 0-3        sta Variation   ; save it        tax             ; transfer it to X        inx             ; and increase it by 1 for the human readable varation 1-4        stx Score       ; save in Score so it shows on left side        ldy #1          ; default to showing 1 player variation         lsr             ; D0 of Variation, # of players, now in Carry flag        bcc Not2        ; if Carry is clear, then show 1 player         iny             ; else set Y to 2 to show 2 playersNot2:        ror Players     ; put Carry into D7 for BIT testing of # of players        sty Score+1     ; show the human readable # of players on right side        rts        NotSelect:        lda #0          ; clears SelectDelay if SELECT not held        sta SelectDelay        rts

 

The routine PositionObjects has been modified to use a Box Graphic for player1 if a 1 player game has been selected:

PositionObjects:...        lda Variation       ; get the game variation        and #1              ; and find out if we're 1 or 2 player        tax    ; Player1Ptr = BoxGfx + HUMAN_HEIGHT - 1 - Y position        lda ShapePtrLow,x        sec        sbc Temp        sta Player1Ptr        lda ShapePtrHi,x        sbc #0        sta Player1Ptr+1                rts        ShapePtrLow:        .byte <(BoxGfx + HUMAN_HEIGHT - 1)        .byte <(HumanGfx + HUMAN_HEIGHT - 1)        ShapePtrHi:        .byte >(BoxGfx + HUMAN_HEIGHT - 1)        .byte >(HumanGfx + HUMAN_HEIGHT - 1)

 

The Kernel has also been modified so that the correct Arena will be drawn. A little bit after TimerBar: you'll find this:

TimerBar:...        lda Variation       ; 3 20        lsr                 ; 2 22 - which Arena to show        tay                 ; 2 24 - set for index        ldx ArenaOffset,y   ; 4 28 - set X for which arena to draw        lda ArenaPF0,x      ; 4 32 - reflect and priority for playfield        and #%00000111      ; 2 34 - get the lower 3 bits for CTRLPF        ora #%00110000      ; 2 36 - set ball to display as 8x pixel         sta CTRLPF          ; 3 39...ArenaOffset:        .byte 0         ; Arena 1        .byte 22        ; Arena 2

 

The lsr command shifts bit 1 down to bit 0 so that we end up with 0 or 1 for the Arena number. That's used to set X to either 0 or 22 via the command ldx ArenaOffset,y.

 

I also added code to update CTRLPF based on the first PF0 data byte for the selected Arena. CTRLPF uses its bits like this:

  • 76 - not used
  • 54 - set width of BALL object
  • 3 - not used
  • 2 - Playfield Priority
  • 1 - Score Mode
  • 0 - Reflected Playfield

Since PF0 only uses bits 7654, also known as the upper nybble of the byte, we can use the lower nybble to hold extra information to specify whether or not the selected Arena uses Playfield Priority (as opposed to Player Priority) or has a Reflected Playfield(as opposed to Repeated Playfield). We could even specify Score Mode which would just color the two sides of the playfield to match the colors of the players (like in the score display).

ArenaPF0:   ; PF0 is drawn in reverse order, and only the upper nybble        .byte %11110001 ; Arena 1   lower nybble controls playfield, set for REFLECT        .byte %00010000        .byte %00010000        .byte %00010000...                .byte %11110100 ; Arena 2 - lower nybble controls playfield, set for PLAYFIELD PRIORITY        .byte %00010000        .byte %00010000        .byte %00010000

 

Game Variation 2, Arena 1 with 2 players. Arena 1 features Reflected Playfield and Player Priority

blogentry-3056-0-27001700-1404959369_thumb.png

 

Game Variation 3, Arena 2 with 1 player. Arena 2 features Repeated Playfield and Playfield Priority

blogentry-3056-0-27903300-1404959374_thumb.png

 

Look at the left Humanoid's head in each screenshot to see the difference that setting Playfield Priority makes. You might remember this being used in some games like Combat where the planes go behind the clouds.

blogentry-3056-0-93790400-1404962729_thumb.png

 

Just for fun, here's Arena 2 with SCORE mode set (I've moved the players to the side of the screen they didn't start on):

blogentry-3056-0-26683400-1405018771_thumb.png

 

The code change for that is:

.byte %11110010 ; Arena 2 - lower nybble controls playfield, set for SCORE

 

ROM

collect_20140709.bin

 

Source

Collect_20140709.zip



5 Comments


Recommended Comments

In regards to this:

If we have space at the end of the project I plan to add some additional arenas.


Contributions will be more than welcome! Just edit the data at ArenaPF0, ArenaPF1 and ArenaPF2. Once the "collect the box" routines are in place, figure out which of your layouts work well and send them in.

Share this comment


Link to comment

Hi!

 

This section was pretty easy to follow, though I did have one minor question; Why is the first mask necessary? I would think the game variation would already be accurate and could just be stored in 'Variation'.

Share this comment


Link to comment

The and in this section of code?

        ldx Variation   ; Get the Game Variation
        inx             ; and increase it
        txa             ; transfer it to A
        and #%00000011  ; limit Variation to 0-3
        sta Variation   ; save it

 

Step thru the code (by hand or using Stella) when Variation starts out with the value of 3.

Share this comment


Link to comment

Yep - using a mask is an efficient way to limit these six ranges of 8-bit values:

  • %00000011 - limits to 0-3
  • %00000111 - limits to 0-7
  • %00001111 - limits to 0-15
  • %00011111 - limits to 0-31
  • %00111111 - limits to 0-63
  • %01111111 - limits to 0-127

Other ranges, such as 0-6, require the use of compare and branch commands.

Share this comment


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

Loading...
  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...