It took a few days longer than originally planned, but I finally finished reformatting the old Action RPG code and it's dubbed Maze Realms now. Action RPG has a different code base that I haven't gotten too far with just yet. It's all good tho.

So now that the insane levels of potentially inaccurate comments and the like are taken out, I've started the second phase. That being fixing some of the bugs I spotted while I went through the first time as well as reworking some of the existing code.

For instance in Maze Realms there's no need to have a delayed-press-and-release to drop a held item so I took it out. I'll be needing that kind of code for Action RPG later but I'll just copy/paste it over from the older backups. There was also a couple of instances where I found buggy non-bugs... or would that be non-buggy bugs?

It was a few instances of "lda $FF" being used instead of the intended "lda #$FF". It just happened to be that address location $FF held value #$F1. For the purposes of the code, it just needed to have a value greater than $80 that was not $F0. $F1 fit the bill so the code acted as it was suppose to. Glad I caught that as I was reading through it otherwise it could have really had me stumped farther down the road.

The fire button now simply drops held objects. It has the side effect that a holdable object can be passed through without picking it up if you keep the fire button pressed. I wasn't sure if I liked that or not, but I can't really see the harm in leaving it that way. That only works if the object can be held and moved. Maze Realms, like Action RPG, will have instant-use items that activate on touch. Holding the fire button down won't affect them. It could be altered so all objects pass through the player, but we'll see how it goes. It'll just need a quick short-circuit based on the fire button's position in the object's collision code.

Otherwise I fixed a graphic glitch in the first castle room where an extra line would be generated if the player tried moving up past the closed gate. The kernel is pretty tight in some instances and in at least one case there's no room for cycle penalties. The glitch occurred because the castle gate's graphic was lying over a page boundary. That made one particular scanline case use too much time, generating an extra line in the process.

The next big scanline glitch occurs when you try to push a held object through the left wall. This causes a problem where the object's X position wraps around and the 2600 thinks it's over 200. The sprite positioner ends up waiting a LONG time since 200+ is outside the allowable 0-159 range and an extra scanline is generated. I'll be fixing that as well before I release the next rom. I already know how I'll be doing it.

So yeah, the next version is just going to be a less buggy version of what I've already released. >_>

After that's done, I'll be fiddling with the display code and changing the Status menu to be something far FAR simpler. Of all the things on it, the only thing I really want to keep will be the status bar. And if that's all I'm keeping, I'll probably consider centering it as well.