On an earlier version I was describing some of the bugs that I ran up against but ended up forgetting what I did to fix some of them. This time I wrote them down!

After I put in the initial code for the new Display kernel, and fixed the common typo-syntax errors (you'd be surprised how important "#" can be.) the displayed screen was... unrecognizable. The player was back as a pillar (wasn't turning itself off) and I had a display consisting of the status bar (lookin' normal) with just multicolored lines for the playfield. Plus the movement clipping for the bottom of the screen was broken. That was expected since I increased the size of the status bar just before but didn't adjust the clipping range to match it.

Anyway... from there I dove into the code and found the following fixes needed.

1. Forgot to set ScanLineCnt to PlayerY in Vertical Blank. (only inited it.) Screen started displaying random colors entire length instead of only a few lines.

2. Removed some old setup code at the end of StatusBar that mucked up what was needed in new code. Didn't notice much difference except in the colors displayed.

3. Forgot to change both instances/cases to turn off the player to #0. I had copied the code from the start-player lines. (I tend to find copy/pasting is causing almost as many problems as writing it all out by hand a second/third time would cause with typos.) Player was once again a proper square instead of a pillar.

4. Had to change:

 dex 
 stx LinesRemaining 

to:

  
 lda PF0_Base,y
 and #%00001111
 sta LinesRemaining	

Whenever we started a new zone. I mean really. COD HAMMIT. No need to decrement a lines remaining of 0 when it needs to be reset instead!! Playfield began displaying sorta, but the top row took a full 16 scanlines to display, I have 16 used for all the zones right now so that means I was doing something wrong! (Zones are one off? Damn 1-off errors I warned everyone about. ) Basically I was loading the counter for the first zone before entering the zone. Then having to wait those lines before the counter hit 0 to indicate it was time to update the playfield. roar.

5. 1-off error for the Ram copy of Playfield data. As a result, the bottom zone/row would grab data from the zone next PF over - from it's top-of-the-screen row. So we had the top of the castle's PF2 data in PF1's data on the bottom. Ick. Thing is, I need MaxZone to equal the one less value for the loops. So just fixed it for that declaration there.

At this point I've gone from a garbage display to the playfield looking proper - but with the intended changing colors based on rom tables (I swear there are uses for it, even if it's cosmetic! ) not changing properly. the code didn't generate errors on assembly and it looks right at a newbie glance... wth is wrong?!

Yeah, that's just a dramatic setup to bug 6.

6. 3 of 5 sections had THIS happening. (commented ora was not commented!)

 lda (ColorIndexLow),y
 and #%11110000	
;ora LinesRemaining	   
 sta BGColor	
 

After commenting, not much changed. It was just wasting time in there, and since LinesRemaining was always 0 at the time this code would execute, I guess it went as expected.

A walk in the cold later, I came back to look at it again. I wondered about the addressing mode being used you see. Obviously if "lda (ColorIndexLow),y" was compiling, surely it was legal!

And it was!

7. However, I was using "lda (LuminiousIndexLow),x" where the problem was. That doesn't exist. DASM however, ever so helpful, converted it to "lda (LuminiousIndexLow,x)" for me. Awww, how sweet. >_< (I found this out by checking the output.txt file) "lda (LuminiousIndexLow,x)" doesn't work the same way as what was intended, and was of course pulling in the wrong bytes. The change to correct that was hideous. It probably takes as much or more time than updating the playfield. ^^; To make sure it's done in time, I calculate the bgcolor a scanline in advance so I don't have to worry about it being done before the hblank finishes. As I said, bgcolor setting isn't critical to keep, but keeping it until the end is like a challenge in it's own. It forces me to think efficiently before I strictly need to, so if I run out of cycles and just can't squeeze anything else out... I have something I can remove.

8. Problem with too many lines generated when player was touching bottom of the screen. This was because there was no way for the player to quickly exit the screen display kernal and forced it to generate at least one extra line for the player-hide routine when it really isn't needed. I provided a short-circuit in the early half for when the playerY was supposedly touching the bottom of the screen. Fixed it almost up. Now the second last line doesn't always seem to work, but at least it doesn't fill the screen with garbage. This is one of those tempting bugs to leave alone, since in the real game the only time you'll hit that scanline is when you're moving out of the room. And it may be difficult to notice the line-jump that pops up on the second scanline that split second before you load up the next room.

I'm going to look through and analyze the code I've written so far so I can predict exactly how it works. I should be able to happen across a fix for that in the process. But that'll have to wait for tonight at the earliest. I have to add more things to the room details as well like exits and ball placement. Since the missiles are used for the players, I'm using the ball to augment the playfield by adding a small degree of asyncness to it. I can have solid lines hiding secrets or acting as left/right exit blockers this way and it'll look a little more uniform imo.

But I'll do that after I analyze the display code written.