Saturday, March 7, 2015


Making progress!

Last night, I've finished the last robo-ninja room before the "flying up high to find Dr Squidbrain" sequence (which is a room or two, then the big boss fight). It's so great to be close to being finished, although the boss fight is going to take a lot of work, a lot of code, and a lot of scrounging trying to find appropriate graphics!

I haven't been doing quite as much with Atari Anguna. (the great thing about having 2 simultaneous hobby projects is that when I get bored of one, I can get excited about the other!) A couple weeks ago I got it to the point where if you killed all the enemies in the right room, a key would appear. You could pick it up, take it to the matching locked door in the a different room, and open the door with it. It's almost like a real game at this point!

But like a said in a previous post, I did the math and realized I'm running out of code space in my primary rom bank. I considered moving a block of code to the 2nd bank (where the kernel and graphics live), but even if I do that, I'm still going to have to sacrifice a number of things I wanted to include (fewer room layouts, fewer enemy types, fewer rooms overall). The other option is a bigger rom, and a different bankswitching scheme!

The folks on the dev forums of AtariAge make a big deal about how the purists pack their games into a single 4K bank. Well, I'm no purist. I'm already using 4K, I have 4K left, and I'd like a little more wiggle room. So I did some research, and there were some good schemes I could use. There were a few weird games back in the day that used a particular 12K scheme, but that one also included extra RAM on the cartridge, which somehow feels like cheating to me. I don't mind using a scheme with a ton of ROM so I can include more content, but one of the fun challenges of this whole thing is working with the limited RAM. So that 12K scheme was out. There's a simple 16k scheme that Atari supposedly used in some of its 1st party games (although I couldn't any mention of what games actually used it), which works exactly like my 8K scheme, only with 2 more banks. So that's what I'm tentatively going to go with.

This week, the plan to make it easier to transition, was first to rearrange all my code. I've been mixing my code between actual subroutines (called with jsr/rts, the native 6502 opcodes for calling and returning from subroutines) and just macros (for most "functions" that I'm only going to call once, so I don't have the 12-cycle overhead of the jsr and rts.) This ended up being a big mess, as it's difficult to tell where in my rom the macro code actually ends up. So I yanked all the macros out of the files where they lived into separate files, so I can move the subroutines around between banks without worrying about where the macros get called from.

Next I need to figure out where all I have references to the room data. If I move the room data to a new bank, all the code that reads that data has to be in that bank as well. It's almost like I have some actual encapsulation and data hiding!

No comments:

NNNNNN in 12 hours

I recently announced my NESdev competition entry for this year: NNNNNN , a multiplayer NES port of the Gravitron from VVVVVV .  Now that it&...