After finishing a game, every now-and-then shortly thereafter, I like to hit Google and see if there are any new things that turn up about the game on the web. I was pretty much done doing that, as I didn’t expect to find anything else on what was going to be the last time I did such a search. I released it at the end of April, so it’s getting close to six-months out, and there won’t be much new to read about what people might have to say about it. So you can imagine my surprise (and excitement) when I actually found something new on a blog called Irish Nintendo Fan (love the name of the site!):

One of the featured homebrew reviews [in Retro Gamer Magazine issue #93] I like was NES Virus Cleaner. I tried it for myself and it’s quite addictive but tough, avoiding things like you would in say, Frogger and collecting all the bits to complete a level.

Ah, good ol’ Retro Gamer Magazine! My game prior to NES Virus Cleaner, that being Pegs, actually appeared in there as well. It had a fair review from a guy named Jason Kelk, and though I can’t tell for sure, I believe he did the write-up this time around, too (the initials J.K. appear at the beginning of the article).

Once again, it is a solid write-up, and I’m grateful to have appeared in a magazine! It’s a cool feeling for sure. I’m definitely going to look into getting my hands on this issue, as I failed to get the Pegs issue last time. Here is a pic of it that a friend of mine, and also one of the lead testers of NES Virus Cleaner, took for me. Click to read it:

The new phonebook is here!

I don’t know if you still lurk around here, but I’d like to once again thank you, Jason, for the opportunity to be in the magazine! Oh, and you can rest easy knowing that I don’t hit the coffee as hard as I used to ; )

But the way I have the scrolling now feels… I don’t know. Like I’m not doing something properly. I can’t seem to comprehend the relationship between $2000, $2005, and $2006 that I’m always hearing about. Anyway, here is the code that I came up with after all kinds of time spent, and some guidance in IRC:

intro_nmi:
	lda time_write_count			; Check if we should write words to background
	beq :+					;  if so, jump over a couple instructions
		dec time_write_count		;  if not, decrement time_write_count
		jmp @scroll			;  and continue to scroll the screen
:	ldx offset_x_reg			; Use RAM register for our X offset
	lda intro_ppu_addy_hi, x		;  and check if #$ff is loaded from the table
	cmp #$ff				;  if it isn't, jump over an instruction
	bne :+					;  if it is #$ff, jump to the end of NMI,
		jmp end_nmi			;  effectively freezing the program
:	ldy offset_y_reg			; Load the RAM register for Y offset
	lda intro_lo, y				;  and use it to setup the pointer. The pointer
	sta pointer1				;  points to words to be printed to the
	lda intro_hi, y				;  background
	sta pointer1+1				;
	lda intro_ppu_addy_hi, x		; Use X to select from a table of background
	sta $2006				;  addresses to which to write to. Hi and lo,
	lda intro_ppu_addy_lo, x		;  of course
	sta $2006				;
	ldy #$00				; Use Y _without_ the RAM register offset,
:	lda (pointer1), y			;  and use it to grab the letters of the words
	sta $2007				;  and write them to the background
	iny					;  increment Y
	cpy #$1a				;  and check it against #$1a (the number of
	bne :-					;  letters in each row). Branch back if needed
	inx					; Increment X and store it back in the RAM
	stx offset_x_reg			;  X offset
	inc offset_y_reg			;  Increment the Y RAM offset
	lda #$38				; Use #$38 as the amount of time that needs to
	sta time_write_count			;  countdown before writing to the background
	lda reg2006hi				; Select the base nametable. In this routine,
	sta $2006				;  reg2006hi will be either #$20 or #$28
	lda #$00				;
	sta $2006				;
@scroll:
	bit $2002
	lda scroll_x_hi				; scroll_x_hi will never be anything but zero
	sta $2005				;  in this routine
		lda scroll_y_lo			; We want to scroll slower than 1 pixel per
		clc				;  frame, so we have a hi and lo value for
		adc #<intro_scroll_speed	;  the Y scroll. intro_scroll_speed is set
		sta scroll_y_lo			;  at $0040 in the declarations
		lda scroll_y_hi			;
		adc #>intro_scroll_speed	;
		sta scroll_y_hi			;
		cmp #$ef			; Check if the scroll has reached #$ef
		bne @store_scroll		;  branch and store scroll_y_hi in 2005 if not
			lda reg2006hi		; If it did reach #$ef, check if reg2006hi is
			cmp #$20		;  #$20, and if it is...
			bne :+			;
				lda #$28	;  ... stick #$28 in there
				sta reg2006hi	;  to use as the base nametable next time
				jmp :++		;  then jump two instructions
:			lda #$20		; If reg2006hi was NOT #$20, then make it that
			sta reg2006hi		;  number
:			lda reg2000save		; Load the $2000 register we made in RAM, and
			eor #%00000010		;  flip the bit for which nametable to scroll
			sta reg2000save		;  on. Be sure to save it in both reg2000save
			sta $2000		;  and the $2000 register itself
			lda #$00		; Reset the scroll_y_hi to zero
			sta scroll_y_hi		;
@store_scroll:
		sta $2005			; The second and final write to the scroll
	jmp end_nmi

I know there is some clean-up that can be done, like the inx/stx thing, followed by an inc, but whatever. Anywheres, the main loop of the program does nothing but keep waiting for another NMI to fire.

But yeah, I’m feeling like it’s just not right. It works, but feels wrong. If anyone has a better approach for this, please let me know! If you just want to see the end result of this, here is a vid (ignore the font, it’s just a placeholder).

What I’m babbling about, is this. You know how you play some game that has a hi score feature in it, but if you press reset, the hi score is still there? Well, oddly enough I never put much thought into it. But tonight it popped into my head, and I figured out how to do it. I remember someone telling me that the way you can do it is by having a space in RAM set aside that you don’t erase at the reset routine, and fill it with specific bytes. When it gets reset after those bytes are fed into it, you test them against the same bytes in ROM, and if they match, you don’t zero out the hi score. I don’t know if that sounds confusing, but here’s the code I came up with:

; in the declarations, of course
ram_check		=	$700
hi_ten			=	$706
hi_hundreds		=	$707
hi_thousands		=	$708
hi_ten_thousands	=	$709
hi_hun_thousands	=	$70a

; this is in ROM
rom_check:					; The string that gets put in RAM for
	.byte "SLYDOG"				; the hi score check

; and the actual subroutine that happens at reset
slydog_ram_check:
	ldx #$00
@start_ram_check:
	lda ram_check, x			; compare the RAM starting at $700 to
	cmp rom_check, x			; the ROM at rom_check
	beq @fill_ram_check			; if one of the bytes don't match
		ldx #$00			; throw zero back in the X register
@write_rom_ram:
		lda rom_check, x		; load a byte from rom_check
		sta ram_check, x		; store it in ram_check
		inx				; increment X and repeat until
		cpx #$06			; X is 6
		bne @write_rom_ram
			lda #$00		; Now throw a zero in all of the
			sta hi_ten		; hi score bytes. This means it
			sta hi_hundreds		; was a hard power up, so there is
			sta hi_thousands	; no hi score saved. If we don't do
			sta hi_ten_thousands	; this, the NES will print garbage
			sta hi_hun_thousands	; on-screen as the hi score
			jmp @done_check		; routine is done
@fill_ram_check:
	inx					; if the original comparison matched
	cpx #$06				; then we increment X six times
	bne @start_ram_check			; to be sure the whole string matches
@done_check:
	rts					; and we're outta here

It seems to work for me fairly well. It can also be used in other pages of RAM. I had heard that the 700 page was for stuff that needed to be saved, but it works in other places I tested. Anyway, I just thought it was cool and that I’d share : )

I’ve always been really fond of 3D mazes, like those found in the Golgo games, Ultima, etc. What I was looking to do was take the speed of the Golgo 13 – Top Secret Episode mazes, and combine that with the smoothness of the Mafat Conspiracy mazes. I opted to use the same kind of screen layout from Mafat, with the big status bar at the bottom. In this way, I have less tiles to load. My initial build was good, because I got the actual maze loading and you were able to navigate around. The problem was with the screen loading, though. You could move VERY fast, but the screen flashed too much, kinda like Top Secret Episode. To play how it was in it’s original state, check out this ROM:

http://slydogstudios.org/download/maze_orig.nes

What I really wanted to incorporate was how Mafat Conspiracy loaded in one nametable, then switched to the other nametable to have a seamless transition. After alot of time debugging, going through my code, and some folks in #nesdev testing it out via different emus and a powerpak, I finally found the right balance I was looking for. The thing that topped it off was my buddy Phil’s suggestion to be able to hold down the FORWARD button, instead of a constant pressing of it each time you wanted to move. This added to the feel and pacing that I really wanted in it, being an action game. Here’s a quick vid I whipped up a few minutes ago to show the nametable switching while playing (quality isn’t great):

http://slydogstudios.org/video/aa_nametable_switch.wmv

So that’s the basics of how it came from a Top Secret Episode style maze to a blend of that game and Mafat Conspiracy. Now with a character in the mix, it has a weird blend of Cabal, Punisher, and Smash TV going on, too. Pretty crazy haha

For awhile he wasn’t firing when he was angled with his weapon facing to the right. Well, he was firing, but the blast from the gun wasn’t appearing at the end of it. I looked through the code over and over, kept watching certain places in memory and so-forth. I just couldn’t find it, and it ended up I had added and subtracted in opposite places haha The bad thing is, I looked at that quite a few times thinking that might’ve been the problem. For some reason I was thinking backwards the whole time, and it finally hit me. So dumb : P

The code isn’t really anything special enough to paste on here. It’s actually probably considered “bad practice” by some, but whatever. A person once told me on that same subject, “No, if you got it working, then you got it right.” Anywho, here is a quick vid of it in action:

http://slydogstudios.org/video/aa_shooting.avi

When you are facing dead-on forward and not angled, there was no way to know that you were firing, minus the sound effect. I wanted to have a visual of it, too. I ended up slightly changing the aiming sights and just have those two sprites shift in and out with two other slightly modified aiming sights. This gives it a bit of motion, though it won’t affect the actual hitbox when it is put in place. It’s just there to make it a bit more purdy-ful : )

All-in-all, I think it turned out good!

With that said, how many times have I heard that Castlevania II, Double Dragon III, Friday the 13th, Super Mario Bros. 2, etc., just out-right suck, and that people have always hated these games? So many times that it boggles the mind! Zelda II… apparently that sucks and no one liked it… ever. That’s always the implication or what is said. “Remember when you were so happy that a new Zelda was out, and you bought it and got home and then you were like, ‘what the fuck is this shit?’” Always. ALWAYS ALWAYS ALWAYS hear crap like this. As a matter of fact, no, I don’t remember thinking anything like that at all. As a matter of fact, I seem to remember everyone in our town loving Zelda II.

I have a friend that I have been getting reacquainted with on Facebook. He has been thinking about NES again lately, and what did I see in my updates today?:

Wait, you mean people actually liked it?! Damn right.

Yup, that’s right, another person that used to love Friday the 13th. It wasn’t too hard to find them around here. Funny how the Internet seems to say otherwise, but myself and all of my friends loved it.

The Super Mario Bros. 2 argument pisses me off more than anything. Like most people know, there was a Mario 2 in Japan, and a different one here in The States. Now, because we have a different game of SMB2, people call the Japanese version of SMB2 the REAL sequel to SMB. Real? What? So, you are telling me that growing up, I was playing a fake game. No, dumbasses. They also like to say things along the lines of, “SMB2 was always the oddball of the Mario trilogy on NES, so it’s no wonder that it doesn’t get much attention.” When I hear statements like this, it clues me in right away that they are a bumbling buffoon. If you were around to play these games when they came out, you would remember people saying things like, “Hey man, let’s go play some Mario 2!,” to which a reply like, “Alright!,” would follow. As a matter of fact, when SMB3 came out, a lot of people were disappointed because it reminded them more of the first game in the series! After some time, it grew on folks, but the whole ‘destroy blocks’ thing was a flash to the past at first, and kind of felt regressive. Only after you had played more into it did you realize that it was a pretty damn good game.

Oh, and how do people explain away why it is that we got a different version of SMB2 in the US? Well, that’s easy for them, because the Japanese counter-part was considered too hard for Americans. Yes, the good ol’ defeatist, “we’re Americans and Japanese are better,” crap that has been spilling into these folks’ brains. If something like this is true, then I beg these people to play the Japanese Ninja Gaiden 3 and compare it to the US Ninja Gaiden 3. How about the differences in the Bayou Billy versions? Did they just decide that Japanese people couldn’t handle the challenge on those games? I mean, Christ.

Castlevania II. The ENTIRE INTERNET HATES THIS GAME NOW. Sorry Charlie, but no one hated it at all when it came out. No one that I can think of, at least. It was considered a good game. People played it. People beat it. Now we have people on Youtube running around with friggin’ tourettes and yelling how much it sucked. Go play your Call of Duty, chumps.

And that’s just it. I can’t tell if some of these people are young and just weren’t around for the release of these games, or if they were the oddballs growing up that seem to be able to infect everyone with this crap.

There’s more to say on this, but I’m tired of thinking about it. Another time, maybe.

I am figuring that I will add in another row of bytes to go along with the hotspots and direction to face, that being the cluster type. Within each cluster type will be a listing of enemy types. Something like:

clusters_a:
	.byte <cluster00,<cluster01,<cluster02 ; low byte of cluster type
clusters_b:
	.byte >cluster00,>cluster01,>cluster02 ; high byte of cluster type
cluster00:
	.byte $01,$01,$00,$02,$01,$03 ; list of enemy types

I think of this in a similar way as metatile compression, since I could actually reuse clusters if the environment permits. The only difference here is that it isn’t really for compression, but more for organization as a whole. Anywhat, the code to set up for the init to battle will look something like this in its final form:

cluster_ram		= $590
cluster_direction	= $598
cluster_types		= $5a0

;-----------------------------

enemy_cluster_pos1:
	.byte $18,$6e,$86,$b1,$cb,$00,$00,$00 ; position of enemy clusters
	.byte $02,$02,$20,$80,$08,$00,$00,$00 ; direction to turn to at hotspot
	.byte $xx,$xx,$xx,$xx,$xx,$00,$00,$00 ; cluster type [where xx is data]

check_cluster:
	ldx #$00		; set register X to zero
:	lda cluster_ram,x	; load A with the cluster offset by X
	cmp player_pos		; check if it matches with the player position
	beq :+			; if it does, jump to set things up for battle
		inx		; if not, increase X by one and compare it
		cpx #$08	; to the max number of enemy clusters, which
		bne :-		; is eight. Branch back and check all eight.
			jmp :++	; If all checks don't match, jump over the
:				; init for battle.
	lda still_writing_bg	; If other nametable is still loading, wait
	bne :+			; until it is finished to setup battle init
		lda cluster_direction,x	; Grab the direction the player will
		sta battle_direction	; face and store for later use
		lda cluster_types,x	; Grab the type of cluster that will
		sta cluster_type	; be used in this encounter and store
		lda #$00		; Clear the cluster to zero using X
		sta cluster_ram,x	; as the offset so that we don't fight
		lda #$02		; these enemies again
		jsr music_loadsfx	; Load the sound for the alarm.
		lda #$01		; Make being_attacked non-zero so we
		sta being_attacked	; will jump to the proper loop for battle
:	rts

I think that will be all the changes I have to make to that code. I had to throw in the check of still_writing_bg from the screen loading routine in order to make sure it was finished up before loading the screen of the direction that Ace will have enemies attacking from. Glad I had that in the code, as it made for an easy check!

So the enemies are going to be done differently in this game than from NES Virus Cleaner. In that game, I had 5 basic types of enemies. What was bad about that is that I had to define how each one behaved. Such as, Shokr v1, it would move at a certain speed, and another Shokr 1 would move at a different speed. The speed was an extra byte that I had defined each time. It would’ve been better had I defined those as two different enemy types, but alas I didn’t. See the pic?:

Whoa, numbers are charging at me!

The 1 and 2 are representing where an enemy would start at, for example. The lines from each represent what their heading would be. In NES Virus Cleaner, they would’ve been defined as the same enemy type. In this, I am planning on making their behavior dictate the enemy type. Even though they might look the same, they behave differently, so it only makes sense to have the type be different. That should save a lot of headaches, too!

http://robertlbryant.com/video/aa_enter_combat.wmv

Sorry about the stretched look, but I had to encode this differently than the last one. When I tried using Microsoft Video 1 today, it looked HORRIBLE haha So I threw it in Movie Maker to export it as a WMV. Anyway, I wanted to get this bit done today, especially since I just got the angled look of Ace in my email. I think it turned out great : ) No shooting implemented yet, but soon enough.

Time to get ready for woik!

You start off at the beginning of each maze with no map on the HUD at the bottom of the screen. In the coordinates box, there will be a spot that represents where you are. There will also be a spot representing where the map is hidden at. So you will have to find your way through the maze to that spot to obtain it. During and, most likely, after you obtain the map, you will have to clear the level of all baddies. The HUD will contain the number of enemy “clusters” that are in the maze. Each cluster represents a predetermined spot where the enemies will be. When you hit a cluster spot, an alarm will sound and you will be attacked by a swarm of enemies, and you enter into battle mode. After getting rid of all the enemies in that cluster, you keep going through the maze to clear the floor of them all. Once that happens, an indicator on your map will show you where the exit to the next floor is. It will be unaccessable until all enemies have been defeated.

Anyway, the way I have it coded now, there are up to eight enemy clusters per level. I thought about using one byte to represent these, but I figured it would be easier to use a spot higher up in RAM and just have 8 bytes that represent the position of the enemies. For instance, here are the level one positions for the enemy clusters:

enemy_cluster_pos1:
	.byte $18,$6e,$86,$b1,$cb,$00,$00,$00

What happens is, when you land on a spot with a cluster, the byte that represents the position of the enemy cluster is then wiped out to zero. The player can never be at position $00, as it’s always a solid wall. In this way, it makes it easy to know if the player has destroyed that cluster yet or not. The code is pretty simple, too:

	ldx #$00		 ; set register X to zero
:	lda cluster_ram,x	 ; load A with the cluster offset by X
	cmp player_pos		 ; check if it matches with the player pos
	beq :+			 ; if so, branch to set things up for battle
		inx		 ; if not, increase X by one and compare it
		cpx #$08	 ; to the max number of enemy clusters, which
		bne :-		 ; is eight. Branch back and check all eight.
			jmp :++	 ; If all checks don't match, jump over the
:				 ; init for battle.
	lda #$00		 ; Clear the cluster to zero using X as the
	sta cluster_ram,x	 ; offset so we don't fight these enemies
	lda #$02		 ; again. Load the sound for the alarm.
	jsr music_loadsfx
:

There will still be a couple of things to add to the battle init, but that’s how it’s set up for now, just to get the ball rolling.

Shawn did a few graphics of an alien last night that look purdy good. The aliens all have the joe eyeball thing going on (read: the classic NES one eyeball on a baddie). Hopefully tomorrow I can get more going on in terms of setting Ace up for battle! That should be fun : )

The next issue was the controls. Shawn suggested doing something along the lines of Smash TV since one controller was already programmed to be held sideways. I liked that idear, and came up with a scheme like:

Controller #1
===============
(held sideways, so left is pointing at the screen[FORWARD])
During maze roaming
-------------------
FORWARD = Move forward
LEFT = Turn to face to your left
RIGHT = Turn to face to your right
BACKWARD = Turn around 180 degrees

During combat
-------------
FORWARD = Fire
LEFT = Move character left
RIGHT = Move character right
BACKWARD = [still open as of now]

Controller #2
================
Not used during maze roaming, but during combat is used to move an
aiming cursor for your weapon.

I haven’t implemented the combat portions yet, so I have no testing of the aiming sights right now. However, I really wanted to get Shawn more involved with graphics on this game. See, back when we were kids he always had a knack for drawing things up to look pretty good. I figure that as he messes with pixel art more, he will get better. So he whipped up how the character will look on the game, and I threw it in the ROM. It looks pretty good, I think! Even better than that, he drew up a GREAT screen of the character from the front. I really want to show it off here, but I think I’m going to save it for the ending screen. It looks really good, great shading, etc. I was really friggin’ impressed by it, honestly! It’s going to be one of those images where he will be mostly part of the background, but more than likely have to use sprites to show extra detail on him. I think that will be the first time that I actually do something like that, too. Should be interesting!

Anway, here is a video showing the character run around in the maze:

http://slydogstudios.org/video/aa_movement.avi

The way his arms move when he is running came in handy for when turning left, right, or behind. There’s more of a signal to the player which way you are heading, as I know these kinds of mazes on games throw some people off. Maybe that will help some, along with the compass and eventually getting a map on each level. At the end of the video you can hear a sound effect that is like an alarm. That is what the sound will be when you encounter a group of enemies. Just thougt I’d toss that in there for ya : )

Before I end this post, I figure I’ll fill you in on the name of the hero. Shawn and I are both big fans of Red Dwarf, and love the other-dimension Arnold Rimmer that only appears in a couple of episodes. They call him Ace, and we thought that would be awesome. Seriously, a hero named Ace? Gold. We started dicking around with his color scheme, and ended up thinking, “hm, what about Boise State colors?” That’s where the color scheme came from (though I may switch the color $16 to $17 and see how that looks). Finally, we figured we should give him a last name, and decided to honor Kendell Kellen Moore from Boise State. So, the character’s name is officially Ace Kendell Kellen : )

This project should be fun to finish off! Stay tuned.