bluswimmer

My biggest concern with making a 2600 styled game for a modern platform is that the graphics would come off as lazy, even if that's not the intention. Pixel art has a pretty low barrier to entry nowadays; all you need to get started is MS Paint, really. Of course, making GOOD pixel art is a completely different story. Given the large influx of pixel art games in recent years, the art needs to really stand out if it wants to be noticed.

Hi all, Today brings another bugfix. I've had this one lined up since before PRGE, but since I wanted the version playable at the expo to be the same as the one online, I've held it back until now. Anyways, this update fixes a bug where, if the player is charging for a shot while the victory animation is playing, the charge sound is heard during the fireworks. All three versions (NTSC, PAL60, SECAM60) are in the zip file below. cannonheadclashV4.2.zip

Hi all, I've discovered a fairly major softlock in the game that activates if you press reset during the victory animation. This has been fixed and posted below. Additionally, I've tweaked the music timing and created PAL60 and SECAM60 versions of the game. All three ROMs are in the zip file below. cannonheadclashV4.1.zip

Looking at your code, I believe you can move this part to the end of the scanline. tya and #%11111100 ; Creates Playfield Ptr tax ; Playfield Ptr -> YX This way, you can load values from the playfield array and then store them directly into the PF registers at the beginning of the next scanline, rather than placing them in Temp in the middle of the line and loading those values at the beginning of the next line. I was able to save about 14 cycles doing this.

No, not quite- you're technically adding the memory address of PVrtPos instead of its actual value. To properly add them together, you'll need to do something like this: lda #<(YoYoGfx - ArenaHt) clc adc PVrtPos sta GfxPointer lda #>(YoYoGfx - ArenaHt) adc #0 sta GfxPointer+1 Essentially, I'm just adding an 8-bit number to a 16-bit number. If PVrtPos and the first part of the Pointer go over 255, the carry flag is set, allowing it to be added to the second part of the pointer.

Well, there's a few things to keep in mind. Currently, you're only changing the address of GfxPointer at the start of the game, when it should be done once every frame. Additionally, you aren't adding the Player's Y value to the GfxPointer. Also, I'd probably swap the purposes of the X and Y registers in your kernel- Y is supposed to be the line counter in the draw routine, but it's currently serving as the Playfield Pointer.

I am so sorry, I completely forgot one detail! the lda should look like lda #<(YoYoGfx - ARENA_HEIGHT) lda #>(YoYoGfx - ARENA_HEIGHT) I honestly can't believe I didn't catch this one sooner. ARENA_HEIGHT how tall the play area is.

Update time! This one is probably going to be the last major update, since I'm completely out of RAM and don't have much ROM to spare. Anyways, this one just adds some music to the start of the match, and some music for winning. Oh, and fireworks, I guess. You can check out the latest update in this video or download it below. Enjoy! Oh, and before anyone asks, PAL60 and SECAM60 versions will be coming soon... cannonheadclashV4.bin

Ah, my mistake. Thanks for the correction.

Well, there's a few things to note here. At the beginning of your program, the Pointer setup looks like this.... lda #<YoYoGfx sta GfxPointer lda #>YoYoGfx sta GfxPointer+1 When it should look more like this.... lda #<(YoYoGfx) sta GfxPointer lda #>(YoYoGfx) sta GfxPointer+1 The parentheses are actually pretty important here, since it tells the compiler that you're loading the memory address of YoYoGfx, rather than the value located at YoYoGfx. Also, lda (GfxPointer),x is NOT a valid instruction. Confusingly enough, you HAVE to use lda (GfxPointer),y. As for the string, you could probably use one of the missiles to display it, and turn off the missile once the yoyo starts to get drawn.

Looking at the code, I've noticed that drawing the yoyo alone takes up almost 50 cycles. Given that the system has 76 cycles per scanline to work with, that certainly won't do. It's more than possible to draw a sprite in only 18 cycles. Here's the code for drawing a sprite that I used in Cannonhead Clash (which in turn was taken from Spiceware's Collect Tutorial). Note that y is treated as the line counter in this program, rather than x like it is in your game currently. lda #PLAYER_HEIGHT - 1 ;2 dcp PlayerY ;7 bcs DoDrawPlayer ;9/10 lda #0 ;11 .byte $2C ;15 DoDrawPlayer0: lda (GfxPointer),y ;15 sta GRP0 ;18 The algorithm works as follows: The height of the sprite minus one is loaded into the accumulator dcp is a special instruction that isn't usually documented. Essentially, it operates like DEC and CMP, combined into one instruction. Here it is used to determine whether or not the sprite is ready to draw yet. Here, it compares PlayerY with the height of the sprite, and then decreases PlayerY. If it is not ready to draw, load 0 into the accumulator. The ".byte $2C" is a trick that skips the next instruction. Essentially, the processor interprets the $2C as the beginning of an absolute BIT instruction. Since the lda instruction is two bytes in length, it is treated as part of the BIT instruction. If it is ready to draw, the processor utilizes indirection to find what to draw. Indirection allows the processor to find values via a memory address that is stored in RAM. The correct memory address when drawing a particular sprite is the memory address of that sprite, PLUS the PlayerY value. Hopefully that explanation made some sense. Note that you'll need to change the PlayerY back to the way it was before the Kernel. If you have questions, feel free to ask.

A 7800 version would work, no doubt about that. The 5200 already has Qix on it, so I imagine it wouldn't be too demanding on the 7800.

Frankly, I'm not sure the stock hardware would be able to do Qix justice. The playfield would require the lines to be chunkier, as mentioned above. Qix also utilized a two-button control scheme, which wouldn't be possible on the 2600 (unless you had a Genesis controller). I think the best bet would be to utilize a coprocessor to display a monochrome 96 pixel venetian blinds display (in order to have a higher resolution "playfield"), but even then I'm not certain on how well it would play/look.

This is neat. I'm not sure if you're aware of it, but there's a bug with the clear screen feature where anything drawn at the lowest line doesn't get cleared. Overall, it seems to work well for what it sets out to do.

The terrain is generated using midpoint displacement. Right now the randomness is low enough that you probably won't run into many walls. Two high walls are able to be generated, though.

Today I finished the procedurally generated level feature. The terrain looks a lot more natural now, and to my knowledge there's no screen rollover. This was quite challenging to accomplish. I had to reorganize large parts of the cartridge in order to get everything to work properly. The level is labeled as "!" if you wish to play with random terrain. Enjoy! cannonheadclashV3.bin

Today I started work on procedurally generated levels, a feature that I think will make the game more interesting for experienced players. Currently, the algorithm is very naive, since it just chooses a random height from 1 to 8 for each column of blocks. It also causes screen rollover, though I think it's possible for that to be avoided by using a more efficient algorithm. Still, there's random levels in the dev build now, and they're playable somewhat... This will not be a replacement for the levels already developed, it will merely be an extra option for players to choose if they wish.

Hi all, A new update is out! This one adds a couple of new things. Added six new maps, bringing the total up to 10 Added a new random map function. This selects a random map every time the level reloads. Pressing reset now takes you back to the title screen Fixed a quirk in the CPU opponent where it would not walk off the starting platform on Level 3 If you'd like to the see random map function in action, check out this video. Download is below. Enjoy! cannonheadclashV2.bin

It's a neat idea. The sprites are great. I believe there should be sort of animation/sound attached to telling the dog to stay, though. I didn't realize this feature was in the game initially, and I thought I had encountered a bug. Perhaps some sort of whistlelike effect would work for that?

Hi all, The new update is ready! This one's a big one, so strap in.... A title screen! A new title, "Cannonhead Clash!" More maps to play on! Play to a certain amount of wins! CPU opponent! Fixed a bug involving the death animation that very few people care about! If you'd like to see the update in action, check it out here. Download is below. Enjoy! cannonheadclash.bin

Today I finished the kernel for the title screen. Here's what it looks like.... (Oh, and I've decided on an actual name for the game. "Bomb Game" isn't exactly the most appealing title.)

That's.... actually a good point. It's low priority, but I'll consider it.

No, I am the red player, while the CPU is the blue player. Right now it's not possible to do CPU vs CPU, and I don't plan on implementing it.

Here's a peak at the CPU opponent....