Useful
Inventions
Favorite
Quotes
Game
Design
Atari
Memories
Personal
Pages

Let’s Make a Game!

Step 14: Add Animation

By Darrell Spice, Jr. (adapted by Duane Alan Hahn)

Original Blog Entry

Static images that just slide around the screen work OK, but we can do betterso for this update we'll add a couple new images so we can animate the players as they run around the arena.

Animation Images

While you can have as many frames of animation as you'd like, the code is most efficient if the number of frames is a power of 2 (2, 4, 8, 16, etc). The code that cycles through 4 frames is this:

Example:
        inc frame
        lda frame
        and #3       ; limits values from 0-3, if A was 4 it becomes 0 after the and
        sta frame

Just change the #3 to #7 (8 frames), #15 (16 frames) and so on. If you wanted to cycle through a non-power of 2 count, say for example 5 frames, the code would look like this:

Example:
        ldx frame
        inx
        cpy #5
        bne save
        ldx #0
save:   stx frame

For Collect we're going to use 4 frames. You might be wondering why there's only 3 humanoid imagesit's because we're going to use 1 of the images twice:

 

To animate the players, we'll need to keep track of which frame they're showing, so let's add 2 new RAM variables:

; indexes for player animation sequences
Animation0:     ds 1    ; stored in $B3
Animation1:     ds 1    ; stored in $B4

Then modify PositionObjects so it will animate the images when it preps the variables for the 2LK, but only when the player is in motion:

PositionObjects:
...
    ; select image to show for Player0
        lda ObjectX         ; get current X location for player 0
        cmp SavedX          ;   compare with prior X location
        bne Animate0        ;   if different, animate player 0
        lda ObjectY         ; otherwise check current Y location
        cmp SavedY          ;   against prior Y location
        bne Animate0        ;   and animate player 0 if they're different
        lda #0              ; if X and Y didn't change then select 0, the
        beq SaveFrame0      ;   stationary image, and save it
Animate0:
        inc Animation0      ; increment to select the next frame
        lda Animation0      ; load it
        and #3              ; limit to 0-3 (if it was 4, it's now 0)
SaveFrame0:
        sta Animation0      ; save it
        tax                 ; Transfer A to X
    ; Player0Ptr = HumanGfx + HUMAN_HEIGHT - 1 - Y position
        lda ShapePtrLow,x   ; select image as specified in X
        sec
        sbc Temp
        sta Player0Ptr
        lda ShapePtrHi,x    ; select image as specified in X
        sbc #0
        sta Player0Ptr+1
...
ShapePtrLow:
        .byte <(HumanGfx + HUMAN_HEIGHT - 1)
        .byte <(HumanRunning0 + HUMAN_HEIGHT - 1)
        .byte <(HumanRunning1 + HUMAN_HEIGHT - 1)
        .byte <(HumanRunning0 + HUMAN_HEIGHT - 1)
        .byte <(BoxGfx + HUMAN_HEIGHT - 1)
        
ShapePtrHi:
        .byte >(HumanGfx + HUMAN_HEIGHT - 1)
        .byte >(HumanRunning0 + HUMAN_HEIGHT - 1)
        .byte >(HumanRunning1 + HUMAN_HEIGHT - 1)
        .byte >(HumanRunning0 + HUMAN_HEIGHT - 1)
        .byte >(BoxGfx + HUMAN_HEIGHT - 1)

The code for player 1 is almost the same, though it adds a test so the box image will be displayed for one player game variations:

; select image to show for Player1        
        bit Players         
        bpl UseBoxImage     ; if 1 player game then draw the box
        lda ObjectX+1       ; get current X location for player 1
        cmp SavedX+1        ;   compare with prior X location
        bne Animate1        ;   if different, animate player 1
        lda ObjectY+1       ; otherwise check current Y location
        cmp SavedY+1        ;   against prior Y location
        bne Animate1        ;   and animate player 1 if they're different
        lda #0              ; if X and Y didn't change then select 0, the
        beq SaveFrame1      ;   stationary image, and save it
Animate1:
        inc Animation1      ; increment to select the next frame
        lda Animation1      ; load it
        and #3              ; limit to 0-3 (if it was 4, it's now 0)
SaveFrame1:
        sta Animation1      ; save it
        tax                 ; Transfer A to X
        .byte $2C           ; $2C = BIT with absolute addressing, trick that
                            ; causes the ldx #4 to be skipped over
UseBoxImage:
        ldx #4              ; select the Box Image
    ; Player1Ptr = BoxGfx + HUMAN_HEIGHT - 1 - Y position
        lda ShapePtrLow,x   ; select image as specified in X
        sec
        sbc Temp
        sta Player1Ptr
        lda ShapePtrHi,x    ; select image as specified in X
        sbc #0
        sta Player1Ptr+1
Arena

It works, but the players move so fast they look Superman running on a greased treadmill. See collect_20140714_toofast.bin in my blog entry. To fix that, we'll revise it to use an image over multiple frames. For testing, we'll make the left player use each image for 2 frames while the right uses each image for 4:

Animate0:
        inc Animation0      ; increment to select the next frame
        lda Animation0      ; load it
        and #7              ; limit to 0-7 (if it was 8, it's now 0)
SaveFrame0:
        sta Animation0      ; save it
        lsr                 ; divide by 2 for 0-3 - this means we show the same
                            ; image twice in succession
        tax                 ; Transfer A to X
...
Animate1:
        inc Animation1      ; increment to select the next frame
        lda Animation1      ; load it
        and #15             ; limit to 0-15 (if it was 16, it's now 0)
SaveFrame1:
        sta Animation1      ; save it
        lsr                 ; divide by 4 for 0-3 - this means we show the same
        lsr                 ; image four times in succession
        tax                 ; Transfer A to X

See collect_20140714_speedtest.bin in my blog entry.

 

Both look OK, though I think the left player looks a little better, so the final version will use each image twice. One minor thing happens when the game is overif the players were in motion, the animation keeps on going even though the players are no longer in motion.

Arena

To fix that, we'll add a Game Over check (same logic was added for Player1) that will select the stationary image:

; select image to show for Player0
        bit GameState
        bpl StopAnimation0  ; if game is inactive, stop animation
        lda ObjectX         ; get current X location for player 0
        cmp SavedX          ;   compare with prior X location
        bne Animate0        ;   if different, animate player 0
        lda ObjectY         ; otherwise check current Y location
        cmp SavedY          ;   against prior Y location
        bne Animate0        ;   and animate player 0 if they're different
StopAnimation0:        
        lda #0              ; if X and Y didn't change then select 0, the
        beq SaveFrame0      ;   stationary image, and save it
Arena

The ROM and the source are at the bottom of my blog entry.

 

 

 

 

Be sure to check out the other assembly laguage tutorials on this web site.

 

 

 

 

 

< Previous Step

 

 

Back to the Beginning >

 

 

 

 

 

Table of Contents for Let’s Make a Game!

Introduction

Goals for this tutorial.

Step 1: Generate a Stable Display

On other systems, the video chip generates the display; on the 2600, your program generates the display.

Step 2: Timers

Improve the display generation by using the built-in timer.

Step 3: Score and Timer Display

Using the playfield to display information.

Step 4: 2 Line Kernel

Draw the player objects (sprites) on screen (X & Y location).

Step 5: Automate Vertical Delay

Finish the Y positioning of the player objects (sprites).

Step 6: Spec Change

Revise our goals.

Step 7: Draw the Playfield

Display an arena (like the mazes in Combat).

Step 8: Select and Reset Support

Using the Game Select and Game Reset console switches.

Step 9: Game Variations

How to implement game variations (number of players, different mazes).

Step 10: “Random Numbers”

How to randomize your game.

Step 11: Add the Ball Object

Draw the ball on screen (X & Y location).

Step 12: Add the Missile Objects

Draw the missiles on screen (X & Y location)

Step 13: Add Sound Effects

Let’s make some noise!

Step 14: Add Animation

Make the humans run instead of glide.

 

 

 

 

Useful Links

Easy 6502 by Nick Morgan

How to get started writing 6502 assembly language. Includes a JavaScript 6502 assembler and simulator.

 

 

Atari Roots by Mark Andrews (Online Book)

This book was written in English, not computerese. It's written for Atari users, not for professional programmers (though they might find it useful).

 

 

Machine Language For Beginners by Richard Mansfield (Online Book)

This book only assumes a working knowledge of BASIC. It was designed to speak directly to the amateur programmer, the part-time computerist. It should help you make the transition from BASIC to machine language with relative ease.

 

 

The Second Book Of Machine Language by Richard Mansfield (Online Book)

This book shows how to put together a large machine language program. All of the fundamentals were covered in Machine Language for Beginners. What remains is to put the rules to use by constructing a working program, to take the theory into the field and show how machine language is done.

 

 

6502 Instruction Set with Examples

A useful page from Assembly Language Programming for the Atari Computers.

 

 

6502.org

Continually strives to remain the largest and most complete source for 6502-related information in the world.

 

 

Guide to 6502 Assembly Language Programming by Andrew Jacobs

Below are direct links to the most important pages.

 

 

Stella Programmer's Guide

HTMLified version.

 

 

Nick Bensema's Guide to Cycle Counting on the Atari 2600

Cycle counting is an important aspect of Atari 2600 programming. It makes possible the positioning of sprites, the drawing of six-digit scores, non-mirrored playfield graphics and many other cool TIA tricks that keep every game from looking like Combat.

 

 

How to Draw A Playfield by Nick Bensema

Atari 2600 programming is different from any other kind of programming in many ways. Just one of these ways is the flow of the program.

 

 

Cart Sizes and Bankswitching Methods by Kevin Horton

The "bankswitching bible." Also check out the Atari 2600 Fun Facts and Information Guide and this post about bankswitching by SeaGtGruff at AtariAge.

 

 

Atari 2600 Specifications

Atari 2600 programming specs (HTML version).

 

 

Atari 2600 Programming Page (AtariAge)

Links to useful information, tools, source code, and documentation.

 

 

MiniDig

Atari 2600 programming site based on Garon's "The Dig," which is now dead.

 

 

TIA Color Charts and Tools

Includes interactive color charts, an NTSC/PAL color conversion tool, and Atari 2600 color compatibility tools that can help you quickly find colors that go great together.

 

 

The Atari 2600 Music and Sound Page

Adapted information and charts related to Atari 2600 music and sound.

 

 

Game Standards and Procedures

A guide and a check list for finished carts.

 

 

Stella

A multi-platform Atari 2600 VCS emulator. It has a built-in debugger to help you with your works in progress or you can use it to study classic games.

 

 

JAVATARI

A very good emulator that can also be embedded on your own web site so people can play the games you make online. It's much better than JStella.

 

 

batari Basic Commands

If assembly language seems a little too hard, don't worry. You can always try to make Atari 2600 games the faster, easier way with batari Basic.

 

 

Back to Top

 

Disclaimer

View this page and any external web sites at your own risk. I am not responsible for any possible spiritual, emotional, physical, financial or any other damage to you, your friends, family, ancestors, or descendants in the past, present, or future, living or dead, in this dimension or any other.

 

Home Inventions Quotations Game Design Atari Memories Personal Pages About Site Map Contact Privacy Policy Tip Jar