Sequences

Today’s mission was to get Sequences up and running. A Sequence is a series of monster images at the top of the screen that indicates to the player what they should whack next. I want the Sequence engine done before I start work on monsters. It doesn’t make sense to do the monsters first. The Sequence engine is like the backbone of the game.

Here’s what I needed for Sequences:

• An init routine that selects a starting Sequence based on Level/Sublevel.
• A routine to draw a sequence to the screen
• A routine to close an individual Slot and advance the engine to the next monster in the Sequence. This includes some helper routines to update graphics.
• A routine to select a (random) new Sequence after all Slots in the current Sequence are closed.

Graphics

I decided to start by drawing a 16×16 metatile to represent a closed slot. I had time, so I took my time and ended up redrawing a lot of the dummy graphics for the Sequence Indicator:

new graphics for the Sequence Indicator.

I went for a metal look to start because it is the easiest for me to draw. For the final game I want to have several tilesets for different Level themes. I’ve always sucked at art, so I was quite surprised and happy that my tiles ended up looking so good (to my eyes anyway). I’m especially proud of my keyhole.

Loading Sequences

Loading a Sequence was pretty straight forward to code. I have a table of pointers to tables of pointers to tables of pointers: Levels->Sublevels->Sequences. Once I get down to the Sequences, I choose one randomly. My random number generator is extremely basic: I merely increment a variable once per frame. So far it does the job.

Each sequence is a series of bytes representing a monster ID. Since Sequences can be of variable size (4, 5 or 6 monsters), I have a terminator ($FF) to signal to the engine when the Sequence ends. Loading a sequence copies this series of bytes (including the terminator) to an array in RAM and sets an index variable to 0.

Drawing the sequence was pretty straight-forward too. I cleverly designed the game board so that each Slot location corresponds to a 16×16 square in the bottom-right quadrant of an attribute block. This means that the only thing that differs between the 6 Slots as far as drawing is concerned is the low byte of the target PPU address. Code is so much cleaner when everything lines up like this.

Closing Slots

Since there are no monsters yet, I have the game close a Slot every time a hole is whacked. On the game logic level, all I have to do is increment the sequence index variable and check for the terminator.

Graphically it is no more complicated than drawing a monster image into a Slot. At least it shouldn’t have been, but I got greedy and added a 3-frame animation. It took me all day to finish as I had never done background animation before today, but it was good to get my hands dirty and figure it out. I learned a lot. As a final touch, I added a door-slam sound effect at the end of the animation, which incidentally forced me to code pitch envelopes for the noise channel into my sound engine. Here’s the latest video:

Conclusion

There are still some things I want to add the the Sequence engine. I want to animate the Slots opening when a new Sequence is displayed. I also need to add in some mechanism to advance Levels/Sublevels after a specified number of Sequences are cleared. What I mean is if the player is on Level 1-1, and they knock off, say 8 Sequences, it sends them to level 1-2, which would have a different set of Sequences for the engine to choose from. These features can wait for another day though, as I’m all Nintendo’d out for today.

(BTW, Google is the ultimate word-usage authority: it’s “Nintendo’d out”, not “Nintendoed out”)

To me the most obvious way to do this is to look for combinations like up+A, down+A, left+A, right+A. Even if I reserve the Start button for pausing, that still leaves me with 12 combinations (4 each for A, B and Select). 12 holes is plenty for this kind of game, and actually due to screen space limitations I’ve decided to limit myself to 10 holes.

Detecting button combinations on the NES is a little bit tricky. I don’t want to allow the player to hold down B and spam the dpad to hit many holes very quickly. Also, if the player presses up+left at the same time while pressing B, I don’t want two holes to be hit simulataneously. On the other hand, it would be unreasonable to expect the player to hit two buttons at once in the exact same frame. Nobody is that fast. So I have to allow some leeway. With that in mind, here is how my Button Combo routine works.

Button Combo Routine

Output

My button combo routine takes what the user has pressed and outputs a value 0-12. The output possibilities are laid out like this:

• 0: no combination was pressed.
• 1-4: B+dpad was pressed (in order: up, down, left, right)
• 5-8: A+dpad
• 9-12: Select+dpad

Each of these values is mapped to a hole, and I use the outputted value to index into hole-related tables. For example, here is a table that I use to determine if a valid hole was whacked:

valid_holes:
    .byte 0             ;unused (no combo)
    .byte 1, 1, 1, 1    ;B (up, down, left, right order)
    .byte 1, 1, 1, 1    ;A
    .byte 1, 1, 0, 0    ;Select
    .byte 0, 0, 0       ;unused (select+left, select+right unused)

I have tables for attribute table PPU addresses and the like as well.

Input

When I read the controller every frame, I store two sets of data in RAM. One is the current button states (pressed or not pressed), which I store in a variable called joypad1. The other is off-to-on transitions, ie what was unpressed last frame but is pressed this frame. Off-to-on transitions are stored in a variable called joypad1_pressed.

Each variable is one byte, basically a bitflag with each bit corresponding to a button. My controller reading routine stores button information in this order:

joypad1 and joypad1_pressed bits:

76543210
||||||||
|||||||+- right
||||||+-- left
|||||+--- down
||||+---- up
|||+----- start
||+------ select
|+------- B
+-------- A

Logic

The first thing I do in my button combo routine is to check if A, B or select is pressed. If not, obviously we can’t have a combo, so skip to the end.

;---------------------------------------------------
; check for dpad+button combos
.proc check_combos
    lda joypad1
    and #%11100000      ;isolate A, B, select
    beq @somewhere_near_the_end
    ;....snip

If a button is pressed, I want to grab its combo value and store it in RAM:

.proc check_combos
    lda joypad1
    and #%11100000      ;isolate A, B, select
    beq @clear_btn_val  ;if not pressed, clear btn_val
    lda joypad1_pressed
    and #%11100000      ;if off_to_on, we need to set the flag, else skip to dpad check
    beq @check_dpad
@set_btn_val:
    asl                 ;shift the A button bit to the CF
    bcc @B
    lda #$05            ;if A bit is set, store 5 in btn_flag  (5, 6, 7, 8 = A combo)
    bne @store
@B:
    asl                 ;shift the B button bit to the CF
    bcc @Select
    lda #$01            ;else if B bit is set, store 1 in btn_flag (1, 2, 3, 4 = B combo)
    bne @store
@Select:
    lda #$09            ;else Select bit must be set, so store 9 in btn_flag (9, 10, 11, 12 = Select combo)
@store:
    sta btn_val         ;add dpad value to this to get index
@check_dpad:
    ;.....snip

@clear_btn_val:
    lda #$00
    sta btn_val
@end:
    rts
.endproc
    

Notice that I check if the button is newly pressed or if it was held from last frame. This check is for a special case. Say the user is holding A. Then say a monster they want to smack appears in the up+B hole. The player will press up+B, but there is a chance that there will be several frames of A+B as the player slides their thumb from A to B. I want to catch the newest button press (B), not the older one (A). So I check joypad1_pressed. If a button is newly pressed this frame, I set btn_val. If not, I skip straight to the dpad (btn_val having been set in a previous frame).

To say it another way, I only alter the value of btn_val in two cases: when a new button is pressed, or when no buttons are pressed. This is important for another case too, which I will get to in a moment.

Note that if on the off-chance that B, A or Select are newly pressed simultaneous in the same frame, A takes precedence over B, which takes precedence over Select. Not going to happen often, and when it does it’s not a big deal – the player will know they mashed both buttons.

Finally we check the dpad to complete the combo:

@check_dpad:
    lda btn_val
    beq @end            ;if A, B, Select not pressed, no combo
    lda joypad1
    and #%00001111      ;isolate dpad
    beq @end            ;if no arrows pressed, no combo
    tay
    lda dpad_add, y     ;else, grab arrow value from table (up = 0, down=1, left=2, right=3)
    clc
    adc btn_val         ;add arrow value to button value.  Results in a number 1-12
    sta joypad1_combo
    jsr do_button_combo
@clear_btn_val:
    lda #$00
    sta btn_val
@end:
    rts

First thing I check is if btn_val is 0. But if we made it this far, shouldn’t this be non-zero? The player is definitely holding down either A, B or Select afterall. Yes they are, but btn_val could still be zero. After a button combo is registered, I process the combo via do_button_combo and then I clear btn_val. This check for btn_val == 0 covers the case that a button combination was recently processed (say last frame), but the player hasn’t released the buttons yet. It took me some bug-hunting before I realized I needed this check. Button Combinations are tricky, aren’t they?

The rest is pretty straightforward. I check the dpad. If no arrow is pressed, there is no combo so I return. If an arrow is pressed, I grab its value from a table and add it to btn_val to get the final combo value. The reason for the dpad_add table is to protect against cases of multiple arrows being pressed at the same time. If up+left is pressed, for example, I resolve it to up. If left+right is pressed, I resolve it to left. If you’re curious, my table looks like this:

;this table maps each possible d-pad combination to a single d-pad direction
;   0 = up, 1 = down, 2  = left, 3 = right
dpad_add:
    .byte 0     ;unused (will never be read)
    .byte 3     ;r -> right
    .byte 2     ;l -> left
    .byte 2     ;r+l -> left
    .byte 1     ;d -> down
    .byte 1     ;d+r -> down
    .byte 1     ;d+l -> down
    .byte 1     ;d+r+l -> down
    .byte 0     ;u -> up
    .byte 0     ;u+r -> up
    .byte 0     ;u+l -> up
    .byte 0     ;u+r+l -> up
    .byte 0     ;u+d -> up
    .byte 0     ;u+d+r -> up
    .byte 0     ;u+d+l -> up
    .byte 0     ;u+d+r+l -> up

Having this in table form makes it easy to modify in the future if I need to tweak some of the values (poor right arrow gets overruled a lot, doesn’t he?). If you want to know more about this technique, I have written about protecting against odd dpad combinations using tables before.

That’s it. It’s a little complicated but it works. I haven’t optimized this routine, so it’s possible that I could improve it somehow. I’d rather move forward though, since this works fine the way it is.

Incidentally, the player is allowed to hold a dpad arrow and spam A/B/Select. Doing so is of such limited use that I don’t see it being abusive. If testing reveals otherwise though, I’ll rewrite the routine to protect against that.

Full Routine

Here’s the full routine in case anyone wants to copy/paste it into their game. If you do, I will feel really happy if you mention me in the credits somewhere. :)

;---------------------------------------------------
; check for dpad+button combos
.proc check_combos
    lda joypad1
    and #%11100000      ;isolate A, B, select
    beq @clear_btn_val  ;if not pressed, clear btn_val
    lda joypad1_pressed
    and #%11100000      ;if off_to_on, we need to set the flag, else skip to dpad check
    beq @check_dpad
@set_btn_val:
    asl                 ;shift the A button bit to the CF
    bcc @B
    lda #$05            ;if A bit is set, store 5 in btn_flag  (5, 6, 7, 8 = A combo)
    bne @store
@B:
    asl                 ;shift the B button bit to the CF
    bcc @Select
    lda #$01            ;else if B bit is set, store 1 in btn_flag (1, 2, 3, 4 = B combo)
    bne @store
@Select:
    lda #$09            ;else Select bit must be set, so store 9 in btn_flag (9, 10, 11, 12 = Select combo)
@store:
    sta btn_val         ;add dpad value to this to get index
@check_dpad:
    lda btn_val
    beq @end            ;if A, B, Select not pressed, no combo
    lda joypad1
    and #%00001111      ;isolate dpad
    beq @end            ;if no arrows pressed, no combo
    tay
    lda dpad_add, y     ;else, grab arrow value from table (up = 0, down=1, left=2, right=3)
    clc
    adc btn_val         ;add arrow value to button value.  Results in a number 1-12
    sta joypad1_combo
    jsr do_button_combo
@clear_btn_val:
    lda #$00
    sta btn_val
@end:
    rts
.endproc

;this table maps each possible d-pad combination to a single d-pad direction
;   0 = up, 1 = down, 2  = left, 3 = right
dpad_add:
    .byte 0     ;unused
    .byte 3     ;r -> right
    .byte 2     ;l -> left
    .byte 2     ;r+l ->left
    .byte 1     ;d -> down
    .byte 1     ;d+r -> down
    .byte 1     ;d+l -> down
    .byte 1     ;d+r+l -> down
    .byte 0     ;u -> up
    .byte 0     ;u+r -> up
    .byte 0     ;u+l -> up
    .byte 0     ;u+r+l -> up
    .byte 0     ;u+d -> up
    .byte 0     ;u+d+r -> up
    .byte 0     ;u+d+l -> up
    .byte 0     ;u+d+r+l -> up

Conclusion

So button combinations are done with, and if you watched the video embedded in the last post you will see that they work quite well! This game is really coming along.

Ramses Game

The new game is tentatively titled Ramses Game. It’s a single screen action/puzzle game with a cutscene-driven storyline. I’m using ca65 to assemble and the UNROM mapper.

Story

The story of the game goes like this:

Ramses (the hero) was kidnapped from his home by space pirates and sold at a slave auction in the Artajian system to a cruel master named Bonehammer. Now he finds himself on a monster-infested planet, trapped in a strange prison with a bomb strapped to his chest. He sees a hammer in the corner of the room. Curious, he picks up the hammer and the game for his life begins…

Gameplay

I got the idea to make Ramses Game while I was playing Dragon Quest V on the DS. There is a mini-game in DQV called Slime Smack, which is basically a touch-pen version of Whack-a-mole game with slimes:

Ramses Game has a very similar concept. The flow of gameplay looks like this:

There are a series of HOLES. CREATURES come out of the holes. You whack them in the SEQUENCE indicated before the TIMER runs out.

Successfully whacking all CREATURES in a SEQUENCE will add time to the TIMER and bring up a new SEQUENCE. Successfully completing a series of SEQUENCES (7-10?) will advance you to the next AREA.

If the TIMER ever reaches zero, you lose a LIFE. If you lose all your LIVES, game over.

Ramses Game will differ from Slime Smack some key areas though:

1. You use an NES controller instead of a touch-pen. This is why I was working on up+B, down+A button combinations.
2. A much larger variety of monsters with different abilities. I have a design document full of monster ideas that will make the game more fun and challenging.
3. Multiple area themes, with matching monsters.
4. Possibly bosses at the end of each area.
5. Difficulty curve: at the beginning of the game there are eight holes and sequences of four monsters. By the end there will be ten holes and sequences of six monsters.
6. Cutscene-driven storyline to give the game more depth and color.

Progress

I’ve made quite a bit of progress in the few days I’ve been working on it. I have a placeholder gameboard that displays. I have input-reading routines that successfully detect button combinations. When you whack a hole on the gameboard, you get a visual and audio cue. I made some dummy monster images that display up in the sequence indicator. Everything is coming along nicely. Here is a video of current gameplay:

I’ll post some code snippets next post.

After a long break I finally got back to some homebrew coding. I worked in 6502 for a few hours today. I didn’t work on Explorer, but rather a different game project that is less ambitious. I’ll introduce the game properly in a future post.

What I Did Today

Button Combos

One thing that I needed for the new game project was a way to detect button combinations like up+A or right+B – the kind that you use to select plays in TecmoBowl. It was a little tricky to pull off. For one thing, if the player presses something like up+left+A, I need to resolve that to either up+A or left+A. I need to work that out for all possible combinations of button presses. This includes taking care of cases where A+B are pressed at the same time.

Another issue is with holding buttons. If the player holds B down and makes circles around the dpad, I only want it to catch the first combination. To do two combos in a row, they should release the B button and press it again. But what if the player hits up+B, and then while still holding B they press A+left? Does the holding of B stop the 2nd combination from being picked up or not? There are a lot of possible cases since the controller reading routine is called 60 times per second. The player can’t control their input on a frame-by-frame scale. Sliding from B to A might very well contain several frames (fraction of a second) where both buttons are held down before the B button is released. Not impossible to solve, but it wasn’t as straightforward as I had expected.

Sound Engine

Another thing I did today was port my sound engine to ca65. I wrote my NES sound tutorials for the NESASM assembler. My tutorials are a continuation of another set of tutorials which use NESASM and I wanted to stay consistent. Plus most new nesdevers start with NESASM as it is very newbie-friendly.

My tutorial sound engine was an improvement over the one I had previously written in ca65, so I wanted to replace the old with the new. So I spent some time today porting my sound engine from NESASM to ca65. I was sure everything was going to break as soon as I got all the syntax converted. But it didn’t! Once I got it to assemble it worked perfectly on the first try! That was a relief.

Scopes

ca65 lets you define scopes. Scopes enable you to keep parts of your program hidden from the other parts of your program. It’s good to separate modules, especially in large programs, so that you don’t have variable conflicts and the like. These bugs are the hardest to trace in assembly language.

I didn’t use scopes before because I didn’t really know how. But I found a great thread on nesdev about ca65 scopes that told me how to do it, so I spent some time today separating my sound and controller reading modules from the main program. Everything feels much … cleaner now. Like washing your hands after working outside on a summer day. I can physically feel how much easier things are going to be in the future for me with scopes.

New NES

I bought an NES! Ordered it on Yahoo Auctions on Saturday and it arrived at my house on Sunday! All I need now is a PowerPak and I can start testing my programs on real hardware. I can’t wait!

I’m too lazy to upload pictures here, but you can see the ones I posted to twitter here:

My new NES 1
My new NES 2

I felt I should do some kind of update though, so here are the terrifying monsters I whipped up in GIMP. Turn on the lights before looking at them or you might die in your sleep:

1. Purple Tongue Head
   
   

   When you see it coming, the shit runs down your leg.

2. Eyeball
   
   

   It's looking for something to KILL!

3. Shuriken
   
   

   It's pointy.

]]> http://www.tummaigames.com/blog/2009/08/17/explorer-12-monster-art/feed/ 2 http://www.tummaigames.com/blog/2009/08/06/explorer-11-sobjects/ http://www.tummaigames.com/blog/2009/08/06/explorer-11-sobjects/#comments Thu, 06 Aug 2009 14:01:11 +0000 Thomas http://www.tummaigames.com/blog/?p=185 I haven’t posted in a few days and that’s because I’ve been spending my time doing research. I’ve been peeking at other games and seeing how they handle sprite objects. By sprite object, I mean entities in a game that are represented on screen with sprites: enemies, projectiles, powerups, etc. When I was trying to code bullets, I didn’t really know how to go about it. Should I keep them separate from other sobjects (sprite objects) or are there enough similarities to lump them together?

If you think about it, a bullet isn’t much different from an enemy. It has an x and a y. It has a speed and a movement pattern. It has a palette. It has a hit box. The main difference is what you check for collision against. Enemies collide with the hero. Hero bullets don’t. They collide with enemies instead.

So some logic is different, but the data (or rather type of data stored) is the same! As far as turning the sobject data into actual sprites, bullets can be treated just the same as enemies (the hero too). Why do I care? If I am able to lump them all together, I can make all the sprites in a single loop. Here’s an example of what I mean:

Sobjects to Sprites

Let’s say I have a hero. That’s one sobject. He can shoot bullets. Let’s say I want to allow 3 bullets maximum on the screen at a time. That’s three more potential sobjects. Then enemies. Just pulling a number out of the air, lets say I want there to be 10 enemies on the screen at a time maximum. That’s ten more potential sobjects.

1 hero + 3 bullets + 10 enemies = 14.

So I have 14 sobjects that could be represented on the screen at any one time. If I treat them all the same, I can hold all of the data in arrays, like this:

sobj_id: .res 14
sobj_hp: .res 14
sobj_x: .res 14
sobj_y: .res 14
sobj_hitbox_top: .res 14
sobj_hitbox_bottom: .res 14
...etc

Then whenever I need to turn them into sprites, I can just loop through them all using an index register:

sobjects_to_sprites:
    ldx #$00
@loop:
    lda sobj_id, x
    ;do stuff
    ;calculate y, CHR#, attrib and x
    ;for each sprite of the sprite object
    ;and store in DMA sprite RAM

    inx
    cpx #.sizeof(sobj_id) ;loop through all 14
    bne @loop
    rts

And that will cover all my sobjects as far as turning their data into sprites. I don’t need to write more than one routine!

To differentiate between sobject types (bullet vs. enemy vs. hero), I can just have their index range set. For example, hero is always index 0. Bullets are always 1-3. And enemies are always 4-13. This way I always know what to test for collisions against: enemies will always test against index 0 (hero) and deal damage on a collision. Enemies will also test against index 1-3 (bullets) and receive damage on a collision.

With defined index ranges, limit testing is easy too: If the player presses the fire button, check sobjects 1-3. If they are full already, don’t create a new bullet. If there is an open space there, create a new bullet.

Conclusion

I think I finally figured out how I’m going to arrange sprite objects. Today I rewired all of my previous hero-moving code to fit into this new data model and I think I have it working. Tomorrow I’m going to try to add bullets for real!

]]> http://www.tummaigames.com/blog/2009/08/06/explorer-11-sobjects/feed/ 1 http://www.tummaigames.com/blog/2009/08/01/explorer-10-refocus/ http://www.tummaigames.com/blog/2009/08/01/explorer-10-refocus/#comments Sat, 01 Aug 2009 06:30:47 +0000 Thomas http://www.tummaigames.com/blog/?p=183 I originally started working on this game as an entry for a coding competition. The genre was puzzle games and I thought a switch-throwing maze game would be fun to write. I missed the deadline for the contest long ago but I kept working on the game anyway. Now I’m thinking about taking the game in a new direction.

The decision to make a maze-only game was made because there was a deadline, and because the genre for the contest was “puzzle”. But now that I have as much time and freedom as I want, I think I’m going to expand the game beyond just finding your way through a maze. Specifically, here are some things I want to add that weren’t in the original plan:

1. Enemies and bosses
2. Weapons
3. A way to die (ie, health bar)
4. A way to improve (more weapons. powerups… level ups?)

In addition to these changes, I’m also going to change the setting and storyline completely. No more treasure hunting archaeologist. I haven’t worked out all the details but I think it’s going to be somewhat sci-fi, with the hero as a cyborg (ie, guns not swords). I think using the Guardian Legend girl as my test sprite has influenced me in some way. :).

Anyway, this comes at just the right time. I just got switches and doors working and the next thing I was going to write was a way to break the breakable blocks. In the original maze-game concept there was going to be an item (like a hammer) that the archaeologist hero would find to allow him to break blocks. Now I think it will be a powerup that makes your gun blast stronger.

Next objective: make the hero shoot a projectile when pressing A.

]]> http://www.tummaigames.com/blog/2009/08/01/explorer-10-refocus/feed/ 2 http://www.tummaigames.com/blog/2009/07/29/explorer-10-sprite-collision/ http://www.tummaigames.com/blog/2009/07/29/explorer-10-sprite-collision/#comments Wed, 29 Jul 2009 13:49:59 +0000 Thomas http://www.tummaigames.com/blog/?p=166 In the last post, I got the hero sprite moving. But there’s a problem: she can walk through walls. I need to add collision detection with background tiles. Collision detection with the background can be summed up like this:

if the player tries to move:
    check the space they want to move to
    if that space is solid/blocked:
        don't move
    else:
        move

The looks pretty easy, but it can actually be quite complicated. Here are some issues:

1. The hero sprite has x and y coordinates, which are on the pixel level. My room tile data is stored in ram on the metatile level. We need to make a conversion there.
2. There isn’t any one point on the hero that is a catch-all for movement checks. If the player tries to move left, we will want to check for a collision with the left side of the hero. If the player tries to move right, we want to check for a collision with the right side of the hero. So we will need to make a hit box.
3. Each side of the hit box will have a length > 1, so we may have to check for a collision with more than one background tile. For example, say the player wants to move right. We will check using the right side of the hit box. But it’s possible that the top half of the hit box will be adjacent to one tile, while the bottom half is adjacent to another.
   

   If we only checked the top-right corner of this hit box for collision, it would show the way as clear. But it really isn't, because the bottom half of the hit box collides with a solid tile.

Step 1

First thing I want to do is make a hit box. I’m going to put it around the hero sprite’s feet. I define where the edges are relative to the hero’s X/Y coords, then make a subroutine to calculate the box every frame:

;collision box for the hero sprite (box around the feet)
HERO_MOVEMENT_BOX_TOP = 26
HERO_MOVEMENT_BOX_BOTTOM = 31
HERO_MOVEMENT_BOX_LEFT = 5
HERO_MOVEMENT_BOX_RIGHT = 11

hero_box: .res 4 ;top bottom left right

set_hero_box:
    lda hero_x
    clc
    adc #HERO_MOVEMENT_BOX_LEFT
    sta hero_box+2
    lda hero_x
    clc
    adc #HERO_MOVEMENT_BOX_RIGHT
    sta hero_box+3
    lda hero_y
    clc
    adc #HERO_MOVEMENT_BOX_TOP
    sta hero_box
    lda hero_y
    clc
    adc #HERO_MOVEMENT_BOX_BOTTOM
    sta hero_box+1
    rts

Movement within a metatile

Since every metatile is 16 pixels wide and 16 pixels tall, I can take a shortcut if I determine that the player is not at the edge of a tile. Check out these two cases:



We don't need to check for a collision in the left case. The player is already on a walkable tile, and will remain on that tile if they move a pixel to the right.

Let’s assume the player is trying to move right. The player is on a walkable tile in both cases. In the first case, they are in the middle of the tile. In the second case they are at the edge. We only need to check for a collision in the second case. Checking the first case would be a waste of time, because we’d be checking the tile the player is already on for walkability, but we know it must be walkable since the player is already on it. So right away we can skip over a collision check if we determine the player to be in the middle of the tile (ie, not on the edge).

This is very easy to pull off with 16×16 metatiles. In all cases, the left edge of a metatile will have an x-coord of $x0, and the right edge will be $xF. The top edge of a metatile will have a y-coord of $x0 and the bottom will be $xF. So in our collision detection routines, we can do something like this:

can_move_right:
    ldx hero_box+3 ;right edge of movement box
    inx ;we want to peek at the next pixel over
    txa

    and #$0F ;isolate right nibble,
         ; tells us where we are WITHIN a tile

    bne @move_ok ;not on the edge.  movement within current
                 ;square OK (in other words, if the right
                 ;nibble is 0, we are on the left edge of the
                 ;NEXT tile, and therefore need to check
                 ;for collision)

    ;... check for collisions

@move_ok:
    sec  ;return a 1 if movement is OK
    rts

I use a similar check at the beginning of can_move_left, can_move_up and can_move_down.

How many checks?

Do I need to check one bg tile for collision or two? It depends on the hero sprite’s position. Imagine the player is moving right again. If the top and bottom edges of the hit box are both within the boundaries of a single tile, we only need to check one bg tile for collision. But check this picture (should look familiar):



moving right, the top and bottom edges of the hit box touch two different bg tiles. We need to make two checks.

In this case, the top and bottom edges of our hit box line up with two different bg tiles. So we need to check both. If either of them are unwalkable, we don’t allow movement.

So, two checks or one check? There are a couple of ways to determine if the top and bottom edges of our hit box touch different tiles. I do it this way:

    ;find how many tiles to check (1 or 2)
    lda hero_box ;top edge of movement hit box

    ora #$F0 ;we are going to add the box height,
             ;so set us up to check for a FF->00 transition

    adc #HERO_MOVEMENT_BOX_HEIGHT ;negative means our box is
                                  ;h-aligned with one tile.
                                  ;positive = 2 tiles
    bmi @not_two

    ;... check a tile

@not_two:
    ;... check a tile

I do similar tests for the other directions, but for can_move_up and can_move_down I will check the left and right edges instead of the top and bottom edges.

Hero pixel coords to a room coords

I need to turn the hero’s pixel coordinates into room coordinates so that I can find which bg tiles to check. Here’s my subroutine to do that:

;------------------------------
; set_hero_map_coords finds the x and y room coords for the 
; topleft pixel of the player's movement hit box
set_hero_map_coords:
    lda hero_box+2 ;left
    ldx #$00
    sec
:
    sbc #$10
    bcc :+
    inx
    jmp :-
:
    stx hero_map_x

    lda hero_box ;top
    ldx #$00
    sec
:
    sbc #$10
    bcc :+
    inx
    jmp :-
:
    dex
    dex ;correct y for the status bar
    stx hero_map_y
    rts

Once I have the hero’s room coordinates, I can add to or subtract from them to find the coordinates for the adjacent tiles I want to check for walkability.

Walkability

How do I check for walkability? With a lookup table:

;tile ids
.enum
    floor
    wall
    block
    water
    block_breakable
    stairs_up
    stairs_down
    pitfall
.endenum

.enum ;walkability
    unwalkable
    walkable
.endenum

tile_walkability:
    .byte walkable, unwalkable, unwalkable, unwalkable
    .byte unwalkable, walkable, walkable, walkable

I read a tile id from the room map in RAM and use it to index into the tile_walkability table.

Here’s a simplified can_move_right. (I took out checks for room boundaries to make it more readable):

can_move_right:
    ldx hero_box+3 ;right edge of movement box
    inx
    txa

    and #$0F ;isolate right nibble, where are we WITHIN a tile?

    bne @move_ok ;not on edge. move within current square OK

    ;how many tiles to check (1 or 2)
    lda hero_box ;top edge of movement box
    ora #$F0
    adc #HERO_MOVEMENT_BOX_HEIGHT
    bmi @not_two

    ldy hero_map_y
    iny
    ldx hero_map_x
    inx
    jsr get_room_offset ;takes x/y room coords and returns an
                        ;array index in y

    lda room, y
    tay
    lda tile_walkability, y
    beq @no_move

@not_two:
    ldy hero_map_y
    ldx hero_map_x
    inx
    jsr get_room_offset

    lda room, y
    tay
    lda tile_walkability, y
    beq @no_move
@move_ok:
    sec return 1 in the carry if we can move
    rts
@no_move:
    clc return 0 in the carry if we can't move
    rts

I have seperate routines for the other 3 directions. They are all very similar. The last step is to update my move_hero subroutine to call these collision detection routines before moving, and then skip movement on carry clear.

Conclusion

Now I have a sprite that changes direction, moves, animates and bumps into walls. Here’s the latest video demo:

]]> http://www.tummaigames.com/blog/2009/07/29/explorer-10-sprite-collision/feed/ 4 http://www.tummaigames.com/blog/2009/07/26/explorer-9-sprite-movement/ http://www.tummaigames.com/blog/2009/07/26/explorer-9-sprite-movement/#comments Sun, 26 Jul 2009 15:00:19 +0000 Thomas http://www.tummaigames.com/blog/?p=159 Ok, I got the hero to change directions based on user input. Now it’s time to move her. The first step for this is to have a hero_moving flag that the input handler will set if there is d-pad input:

hero_moving: .res 1

handle_joypad:
    lda joypad1
    and #$F0
    beq @end
    lsr
    lsr
    lsr
    lsr
    tay
    lda direction_change_table, y
    sta hero_direction
    lda #$01
    sta hero_moving
    rts
@end:
    lda #$00
    sta hero_moving
    rts

With this updated input handler, the hero_moving flag will be 1 when the d-pad is pressed, and 0 when it is not. And as before, our hero’s direction will be stored in hero_direction.

Next, I need to check the hero moving flag in my update_hero_sprite routine, which is called every frame:

update_hero_sprite:
    lda hero_moving
    beq @hero_moving_done

    jsr move_hero
@hero_moving_done:
    ;...
    ;write sprite data to RAM as before

Now that I have the foundation laid, I need to write the move_hero routine.

move_hero

There are 8 possible directions the hero could be facing. The current direction is stored in a variable called hero_direction. The possible values for this variable are 0-7, as assigned by these constants:

;direction indexes for tables
SPRITE_UP =         $00
SPRITE_DOWN =       $01
SPRITE_LEFT =       $02
SPRITE_RIGHT =      $03
SPRITE_UP_LEFT =    $04
SPRITE_UP_RIGHT =   $05
SPRITE_DOWN_LEFT =  $06
SPRITE_DOWN_RIGHT = $07

I need to alter the hero’s coordinates based on the direction the player is moving. If they are moving left, I need to subtract from hero_x. If they are moving right, I need to add to hero_x. If they are moving up, I need to subtract from hero_y. If they are moving down, I need to add to hero_y. If they are moving diagonally, I need to update both hero_x and hero_y. There are many possibilities, and rather than have a million branch instructions, I’ll use table lookups again. I will have one table for horizontal movement and one table for vertical movement. I will index into these tables using hero_direction. The tables look like this:

;up, down, left, right, up_left, up_right, down_left, down_rt
hero_movement_x:
    .byte $00, $00, $FF, $01, $FF, $01, $FF, $01

hero_movement_y:
    .byte $FF, $01, $00, $00, $FF, $FF, $01, $01

My move_hero routine will read from these tables and add to the hero coordinates. Note that adding $FF to a number (on an 8-bit system) is the same as subtracting 1, since it will wrap around from $FF to $00. Here is move_hero:

move_hero:
    ldy hero_direction
    lda hero_movement_x, y
    clc
    adc hero_x
    sta hero_x

    ldy hero_direction
    lda hero_movement_y, y
    clc
    adc hero_y
    sta hero_y

    rts

And now she’s moving.

miau pointed out in a comment that diagonal movement should really alter x and y by SQRT(2) rather than 1 (see Pythagorean Theorum). This is something I didn’t consider before, so my hero covers ground a little more quickly when moving diagonally. I’m not sure yet if this is undesirable behavior or not. If I keep it a simple maze-solving game, it probably won’t be an issue. If I get more ambitious and change it to a more action-oriented game with enemies (something I’ve been seriously thinking about), it may be an issue. We’ll see :).

Animation

I want to talk very briefly about animating the sprite. To do animation, I need a few things:

1. Graphics for the various frames of animation
2. A counter to tell me when to change animation frames
3. A variable telling me the current animation frame

I already have the graphics for my test sprite. The other two I need to make myself.

frame_counter: .res 1
hero_anim_frame: .res 1

The animation is a walking animation, so I don’t want the hero to animate unless she is moving. It makes sense then to do the animation frame-changing logic in the move_hero routine. The Guardian Legend hero sprite has a 4-frame walking animation, so here’s how I do it:

move_hero:
    ldy hero_direction
    lda hero_movement_x, y
    clc
    adc hero_x
    sta hero_x

    ldy hero_direction
    lda hero_movement_y, y
    clc
    adc hero_y
    sta hero_y

    inc frame_counter
    lda frame_counter
    cmp #$0B ;change anim frame every 11 "moving frames"
             ;found this number by trial and error
    bcc @end

    lda #$00
    sta frame_counter ;reset counter
    inc hero_anim_frame ;go to next anim frame
    lda hero_anim_frame ;make sure we stay between 0 and 3
    and #$03
    sta hero_anim_frame
@end:
    rts

Then I will modify my CHR tile lookup tables to handle graphics for all four frames of animation for all 8 directions. Then I will update my update_hero_sprite routine to read from these tables based on the values of hero_anim_frame and hero_direction. I’m not going to post the code, because it’s a little long and there are a lot of tables. If anybody wants me to elaborate more, let me know in the comments :)

BTW, before I forget! When adding new variables, it’s a good idea to initialize them. Here is my updated initialize_hero_sprite routine:

initialize_hero_sprite:
    lda #$50
    sta hero_x
    sta hero_y

    lda #$00
    sta hero_moving
    sta hero_anim_frame
    sta frame_counter

    lda #SPRITE_DOWN
    sta hero_direction

    jsr update_hero_sprite

    rts

Conclusion

Whew. I covered a lot of ground today. I probably should have made this two posts instead of one, but I want to hurry up and get to collision detection so I can put up the next demo video. :)

You may have noticed by now that I use hero_direction a lot to index into lookup tables. This is because everything changes based on the hero’s direction, and lookup tables are a great alternative to long sections of compare/branch code. Often when I find myself writing a lot of branching code I’ll see if I can come up with some scheme to turn the test value into a table index.

See you next time!

]]> http://www.tummaigames.com/blog/2009/07/26/explorer-9-sprite-movement/feed/ 4 http://www.tummaigames.com/blog/2009/07/24/explorer-8-sprite-direction/ http://www.tummaigames.com/blog/2009/07/24/explorer-8-sprite-direction/#comments Fri, 24 Jul 2009 15:51:43 +0000 Thomas http://www.tummaigames.com/blog/?p=140 Last time I wrote code to put a hero sprite onscreen. In my first (pre-sprite) video demo, I had room changes triggered directly by player input. Today I’m going to recode the input handler to alter the hero instead, specifically the hero’s direction.

Joypad revisited

I posted my joypad reading code in a previous post, but here it is again for easy reference:

update_joypad_data: ;props to blargg for A-only joypad read.
    lda joypad1
    sta joypad1_old
    lda #%01111111
    sta joypad1
    sta $4016
    asl a
    sta $4016
@loop:
    lda $4016
    and #$03  ;props to Disch for Famicom support
    cmp #$01
    ror joypad1 ;right, left, down, up, start, select, B, A
    bcs @loop

    lda joypad1_old
    eor #$FF
    and joypad1
    sta joypad1_pressed ;this tracks off-to-on transitions.

    lda joypad1
    eor #$FF
    and joypad1_old
    sta joypad1_released ;this tracks on-to-off transitions
    rts

Before, I was checking joypad_pressed to determine whether or not to change a room. This was so that if the player held down a button, it would only change rooms once (instead of once per frame held). But now that I’m going to be using input to control the sprite, it makes more sense to check joypad1 and use every frame’s input. If the player holds down the d-pad, the sprite should keep moving.

But I’m not quite ready to move yet!

Changing Direction

I want to rewrite my input handler so that it takes d-pad input and uses it to set the hero’s direction. This sounds pretty straightforward, but there are some special cases I need to be wary of: what happens if the player presses left+right? or up+down? This isn’t likely to happen on a real controller, but most people play Nintendo games on emulators these days. If you don’t protect against these strange key combinations, you open yourself up to some pretty bizarre glitches, like the Zelda 2 acceleration glitch (commentator talks about it around the 4:20 mark):

I’m going to work around this problem by assigning a single direction to these weird combinations. But first we need to look at our input. In my joypad reading routine above, I store the button states in a variable called joypad1. The left 4 bits of joypad1 will hold the d-pad states and the right 4 bits will hold the states of the other four buttons. First I want to isolate the d-pad bits:

    lda joypad1
    and #$F0
    beq @end
    lsr
    lsr
    lsr
    lsr
    ;now the d-pad button states are in the right nibble.
    ;do change direction stuff here.
@end:
    rts

The right nibble of the A register now holds the d-pad button states. Next I will build a look-up table, assigning a direction to each possible combination of d-pad presses. Let’s look at the combinations. There are sixteen possibilities in all:

0000xxxx
    ||||
    |||+--up
    ||+---down
    |+----left
    +-----right

0000 = no arrows pressed (will never happen)
0001 = up
0010 = down
0011 = up+down
0100 = left
0101 = left+up
0110 = left+down
0111 = left+up+down
1000 = right
1001 = right+up
1010 = right+down
1011 = right+up+down
1100 = right+left
1101 = right+left+up
1110 = right+left+down
1111 = right+left+down+up

The highlighted ones are the problem combinations. I will need to assign a single, specific direction to them. For example in the case of right+left, I will just choose one: left. Let’s turn this into a lookup table. Recall that I have a set of constants assigning a value to each direction (for indexing into CHR lookup tables among other things):

;direction indexes for tables
SPRITE_UP =         $00
SPRITE_DOWN =       $01
SPRITE_LEFT =       $02
SPRITE_RIGHT =      $03
SPRITE_UP_LEFT =    $04
SPRITE_UP_RIGHT =   $05
SPRITE_DOWN_LEFT =  $06
SPRITE_DOWN_RIGHT = $07

Now I will make a lookup table assigning these constant values to the various button combinations:

direction_change_table:
    .byte $FF               ;0000 dummy value
    .byte SPRITE_UP         ;0001, up
    .byte SPRITE_DOWN       ;0010, down
    .byte SPRITE_UP         ;0011, up+down
    .byte SPRITE_LEFT       ;0100, left
    .byte SPRITE_UP_LEFT    ;0101, left+up
    .byte SPRITE_DOWN_LEFT  ;0110, left+down
    .byte SPRITE_UP_LEFT    ;0111, left+up+down
    .byte SPRITE_RIGHT      ;1000, right
    .byte SPRITE_UP_RIGHT   ;1001, right+up
    .byte SPRITE_DOWN_RIGHT ;1010, right+down
    .byte SPRITE_DOWN_RIGHT ;1011, right+up+down
    .byte SPRITE_LEFT       ;1100, left+right
    .byte SPRITE_UP_RIGHT   ;1101, left+right+up
    .byte SPRITE_DOWN_RIGHT ;1110, left+right+down
    .byte SPRITE_DOWN_LEFT  ;1111, left+right+up+down

Now all button combinations have a single direction associated with each of them. All that I have left to do is read from this table and set the hero’s direction, like so:

handle_joypad:
    lda joypad1
    and #$F0
    beq @end
    lsr
    lsr
    lsr
    lsr
    tay ;right nibble has the d-pad button states. use as index
    lda direction_change_table, y
    sta hero_direction
@end:
    rts

Changing the sprite

The rest of the work is already done for me. I already have a routine update_hero_sprite (see last post) that takes hero_direction and uses it to index into some CHR lookup tables. I don’t have to change anything to get the new sprites to display. It works! (you can see the input in the bottom left of each picture):



If I press up, the sprite faces up.



Pressing down+right makes her face southeast



Left+Right gets mapped to left.



up+down+left+right

Conclusion

My hero sprite is now capable of looking in 8 directions. I use a lookup table to assign a specific direction to each possible d-pad button combination. The next step is to actually move her in the direction she is facing. And when she is moving, I will want to animate her. Stay tuned!

]]> http://www.tummaigames.com/blog/2009/07/24/explorer-8-sprite-direction/feed/ 6