Well, I was going to try and record at least 5 minutes of what I had gotten done today, but my cough is getting worse. I don’t think you wanna hear a stuffed up, coughing Roth talking at all! I was going to upload a video of Clik from the 3-in-1 2p Pak, as I got it finished today. Unfortunately, there is no one awake right now to show how the 2-player game looks. I will get a video up tomorrow, and hopefully I am well enough to do the DogCast.
Sorry freaks, but I gotta get some rest!
Ever had a hankerin’ to allow a player to have the ability to input controller codes in the NES games you make at some point? Well, it’s not all that difficult to implement, and as promised on The DogCast, here is what I came up with. Okay, so today isn’t Sunday. A day early doesn’t hurt, does it? Anywhat, firstly we have to set up the things we will need to get it to work; some constants, a couple of bytes of RAM, and a table. The syntax is useable in ca65.
The only constants needed for this bit of code are those of each individual button. This will help with clarity in the table we use later:
a_punch = $01
b_punch = $02
select_punch = $04
start_punch = $08
up_punch = $10
down_punch = $20
left_punch = $40
right_punch = $80
We need two bytes of RAM. I have assigned these to zero page. Both of them could be generic if need be. For example, you will probably have to use offsets quite a bit in your game, and could use something called ‘generic_offset’ or some such. Here are what I named them:
code_count: .res 1 ; Number of frames between each button press
code_offset: .res 1 ; Which byte to check in the code_check table
Before we get to the code itself, we need to set up our table. This is where you decide what the input code needs to be. For this example I have used the classic Konami code, and named the table code_check:
code_check:
.byte up_punch, up_punch, down_punch, down_punch
.byte left_punch, right_punch, left_punch, right_punch
.byte b_punch, a_punch
What that table is, essentially, is just a string of numbers like so: $10,$10,$20,$20,$40,$80 etc… But because we assigned those values as constants, we can more easily read our table and understand what it is saying. Also keep in mind that there are a total of 10 bytes in that table. We will need to know that for the code below.
And here it be! It’s commented, but I’ll explain a bit more afterwards:
test_code:
ldx code_offset ; Get the offset ready
lda control_pad ; Check buttons for only one
eor control_old ; button press at a time
and control_pad ;
and code_check, x ; Check the button press against
beq :+ ; the code_check table
lda #$10 ; When buttons match, reset the
sta code_count ; code count and increase the
lda code_offset ; offset by one.
clc ;
adc #$01 ;
sta code_offset ;
cmp #$0a ; Compare accumulator to max
bne :+ ; offset in code_check table
jsr PPU_off ; Do successful code input stuff
; here. Be sure to jump over
; everything else to the end
; of the routine or RTS if you
; actually implement this.
: lda code_count ; If code_count is NOT zero...
beq :+ ;
sec ; ... then subtract it by one
sbc #$01 ; and return.
sta code_count ;
rts ;
: lda #$00 ; If code_count was zero then
sta code_offset ; set code_offset back to zero,
rts ; which means the code input
; failed, and must start from
; the beginning.
After a button is pressed, we look at the code_check table using the offset. For instance, the offset starts at 0. When we press Up on the control pad, code_check will be looked at with 0 added to it, which matches the first byte in the table. When this is successful, code_offset has 1 added to it. Pressing Up again would have the program once again look at code_check, but since code_offset now has the value of 1 in it, then the code has code_check with 1 added to it, which means we look at the second byte, which is up_punch. We once again add 1 to code_offset, which would now have a value of 2. This goes on for the entirety of the code.
Now, we could leave it at that. Just have people pressing the correct button sequence. They could press Up, then go to the liquor store, grab some PBR, come back, and press the rest of the code and it would still work. What fun is that? Besides the PBR part, of course. No, we need to have some challenge to even a code like this.
We use the variable code_count to keep track of how much time has passed between each button press. After a correct match of user input and code_check, we initialize code_count to $10 (16 decimal). Every frame, this will count down by 1. If it reaches 0 before the next successful input, then code_offset is set back to 0, and the player must make another attempt at inputting the code. You can change that $0a value to whatever you need it to be. I find that this many frames seems to be just about right, but you can slow it down with higher numbers.
You might be wondering what that $0a is up there. That is to check and see if we have reached the end of the code or not. Remember, there are 10 bytes in the table ($0a hex). So once code_offset reaches 10, then the code has been input by the user successfully. The ‘jsr PPU_off‘ that I have in there can be ignored. That is just what I used to check and make sure the code worked. You will probably want to flip some sort of switch and then rts in place of it.
UPDATE: Just thought I’d point out that you would do a ‘jsr test_code‘ in your code to implement this. Most likely on a title screen loop, though it can be implemented just about anywhere, really.
Episode #: 002
Original Date: October 12, 2006
Running Time: 6:26
Ninja Gaiden is one of my favorite games of all time. Not only was the gameplay absolutely awesome, but the story was told in a most unique way in the days of the NES. Not many games have both a great story and fun to boot.
This was the first episode of NES Tips to feature the “extra tips” section towards the end. There really isn’t anything extra special about this particular video. Being only the second in the Tips series, my voice was still bland as all hell.
Talk about how absolutely normal and average the day is mentioned in a sentence or so. Lots of dev updates, including palette animations and sound for Clik on the 3-in-1 2p Pak. I talk about an article on Kotaku which is about a six-year-old kid with terminal cancer, and how the Everquest community rallied together to make something special for him.
Download or LISTEN to The DogCast!
Here is the link to the Kotaku article.
Here is a video showing a ton of people at the event.
Here is the channel of the boy, Ribbitribbitt.
Yes, a penis cloud was sighted, and I talk about how I was promptly informed about it. One of the drawbacks about being a janitor is discussed; seeing what was thrown away. NES development discusses how much I got done today, which was quite a bit, all within the game !Clik! From defining sprites to randomizing the virus locations. I take a trip down memory lane and talk about the local bowling alley, Lincoln Lanes.
Download or LISTEN to The DogCast!
Here is what Lincoln Lanes looks like from the outside.
Not waking up until the afternoon put a damper on things, but seeing the Snail Maze Game mentioned at NES World made the day. I talk about a game called Driar that I saw while over there, and talk more about how much dev got done here at Sly Dog Studios today. Finally, variants of games that collectors like to purchase is brought into question, as I don’t really understand it.
Download or LISTEN to The DogCast!
Here is where Snail Maze Game was mentioned on NES World.com.
Here is a link to learn more about Driar.
The show starts off with talk about how nice of a day it was, and also pissing on gnats (yup). Dev talk includes working on sprite definitions for the 3-in-1 2p Pak, some tiles getting drawn up, and a venture into getting secret controller codes to work properly. The end of the podcast talks about the disappointment of Chasing Ghosts, which may have been a let down because of the awesome that was Ecstasy of Order.
Download or LISTEN to The DogCast!
Here is a link to the official Ecstasy of Order website.