Jump to content


New Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

190 Excellent


About bluswimmer

  • Rank
    Star Raider

Recent Profile Visitors

2,576 profile views
  1. Very impressed by this. There's a lot of moving objects on the screen for a 2600 game. Plus, there's music too! Given that some of the rocks move extremely fast, maybe allow the player to move faster by holding down the fire button?
  2. Weirdest one by far would be this bug in Tumble Temple. When a block falls onto the one of the towers spanning the height of the screen, the whole screen freaks out and you lose instantly. Upon looking at the code after the livestream, apparently I had forgotten to check the bounds of the playfield array in RAM, so it overwrote other parts of RAM. While not entirely related to the subject at hand, both Tumble Temple and Cannonhead Clash have a couple of bug-turned-features. In Tumble Temple, the ability to run across one-wide gaps was not originally intended, it was just a quirk of how gravity was handled. Cannonhead Clash has the implementation of the fireworks, specifically its sound. Originally I was going to use the shoot sound effect for the sound, but what I got was a mix of the shoot and charge sounds. I liked it, so I kept the sound; that didn't stop me from accidentally patching it, and then having to reimplement the bug...
  3. The PAL60 and SECAM60 versions of Balloon Trip are finally here. Should've done this to begin with, but better late than never I suppose. balloontripPAL60.bin balloontripSECAM60.bin
  4. I didn't make a PAL version of Balloon Trip. Unfortunately this game was made before I had the sense to use constants for my color values. I'm currently pretty busy with school right now, but I'll see if I can make a PAL version soon. Frankly, it's long overdue...
  5. This sucks. My condolences go out to those who are affected. Hopefully this is dealt with quickly...
  6. 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.
  7. 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
  8. 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
  9. 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.
  10. 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.
  11. 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.
  12. 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.
  13. 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
  14. Ah, my mistake. Thanks for the correction.
  15. 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.
  • Create New...