4 direction animation?

[+Gemintronic]

Resorting to asm in a BASIC compiler should have extreme benefits. Something like compressing frames of animation by only needing the changes between animation frames.

 

Team Sprybug, SpiceWare, bogax and SeaGtGruff: ASSEMBLE!!!!

[Cybearg]

What do you mean, "compressing animation frames"? You could use an Assembly-based data array to set sprite pointers for all sprites/frames in a single loop. That's what I usually do.

[+Gemintronic]

I'm derailing this topic. I'll try to rein myself in here!

 

Basically, for my current game, I set aside a variable called direction and some constants called _left _right _up and _down. When the player tried to move in a particular direction I set the value of direction like such:

 

const _none = 0
const _left = 1
const _right = 2
const _up = 3
const _down = 4

- sometime later -

if joy0left && player0x > 0 then player0x = player0x - 1 : direction = _left
if joy0right && player0x < 153 then player0x = player0x + 1 : direction = _right
if joy0up && player0y > 17 then player0y = player0y - 1 : direction = _up :  if counter{4} then REFP0 = 8
if joy0down && player0y < 88 then player0y = player0y + 1 : direction = _down :  if counter{4} then REFP0 = 8

 

When it comes time to display the character in the wanted direction I use an on goto statement using the direction variable

 

animate
on direction goto draw_begin load_knightleft load_knightright load_knightup load_knightdown

 

The actual animation code is much as you'd expect. The up and down animations can be taken care of by simply reflecting a single sprite. Moving the Knight left and right, however, requires two different sprites. I use the forth bit in a counter variable to determine the correct animation speed for horizontal movement. In a display of bad coding practices I also slip in the attack routine. A better programmer would have kept joystick input in one section of code.

 

load_knightup

player0:
%11100000
%11100000
%01100111
%01100110
%00110110
%00111100
%00011000
%10111100
%11111100
%11111111
%01111110
%11011011
%00111100
%00111100
%00111100
%00011000
end
goto draw_begin


load_knightdown

player0:
%00000111
%11100111
%01100110
%01100110
%01101110
%00111100
%00011000
%11011100
%11011101
%10111101
%01100110
%11011011
%00111100
%00100100
%00111100
%00011000
end
goto draw_begin

load_knightleft

REFP0 = 8

load_knightright

if joy0fire && player0x = xprevious then goto attack

if player0x = xprevious then goto knight_hframe1
if counter{4} then goto knight_hframe1 else goto knight_hframe2

knight_hframe1

player0:
%11100000
%11001110
%01101100
%01101100
%01100100
%00011000
%00100100
%00011100
%00100100
%00100110
%00101110
%01100110
%00011100
%00111110
%00111000
%00011100
end
goto draw_begin

knight_hframe2

player0:
%00000111
%11100110
%11100110
%11000110
%01001100
%01111000
%00100100
%00111100
%01001101
%01001101
%01011100
%11011110
%00111000
%01111100
%01100100
%00111000
end
goto draw_begin

[Cybearg]

I like how you specify the direction. Using the 1, 2, 3, 4 numbers instead of a bit per direction saves you a bit and is easy to index.

 

Why must left and right be different?

[+Gemintronic]

Some more notes about the above code (editing a post destroys the formatting of code sections)

 

Note that the only code in the load_knightleft section is REFP0 = 8. This is because the left and right Knight sprites are the same: only the sprite is mirrored to walk left!

 

Notice also I stuck the animation routine for up and down movement into the end of my joystick input code:

 if joy0up && player0y > 17 then player0y = player0y - 1 : direction = _up :  if counter{4} then REFP0 = 8
if joy0down && player0y < 88 then player0y = player0y + 1 : direction = _down :  if counter{4} then REFP0 = 8

The "if counter{4} then REFP0 = 8" at the end changes the mirroring to make the up and down sprite look like a second frame of animation. I should have put this in the respective load_knighup and load_knighdown sections.

[bogax]

Resorting to asm in a BASIC compiler should have extreme benefits. Something like compressing frames of animation by only needing the changes between animation frames.

 

Team Sprybug, SpiceWare, bogax and SeaGtGruff: ASSEMBLE!!!!

 

you'd have to decompress to ram.

 

you probably wouldn't want to give

up that many variables.

 

if it was something really really simple

it might be possible to do it in the kernel

but I wouldn't bet on it.

[+Gemintronic]

you'd have to decompress to ram.

 

you probably wouldn't want to give

up that many variables.

 

if it was something really really simple

it might be possible to do it in the kernel

but I wouldn't bet on it.

 

Damn. I was hoping storing just the pixel changes per frame would be possible. I forgot the 2600 is drawing directly from ROM. It can't jump to the pixel coordinates of the changed animation frame because it doesn't have time. Not sure if I made sense there.