So I had all day to procrastinate on the display. I mean to work on the display.

 

Admittedly, for code I didn't get much done. I ended up reverting the main source code back to beta2 in preparation for the next display kernel attempt. Then I cleaned up the variables some and reorganized them a bit to make them a little easier to find (for me at least.) Then I sat down and thought about all the things I want the display to be able to handle in a single frame.

 

1. Ball display.

2. Sprite display for P0 and P1. (Graphics and color change per scanline)

3. Playfield/Background color changing.

4. Player display via missiles.

5. Playfield updating.

 

That's a mighty tall order. And one that's virtually impossible as I've been observing. Most of the impossibility comes from the playfield, and updating PF0/PF1 in time. I can vertically delay the ball and sprites so that I can update their graphics at the end of a scanline instead of rushing it in the hblank, but their colors still need to be set up in hblank I believe.

 

As I check timings and whatnot, I made a few compromises as I knew I would. (The above was only a wish list after all. )

 

1. Ball display, changed only on odd scanlines.

2. Sprite display for P0 and P1 (Graphics only. Color constant.)

3. Playfield color changing. (alternating colors)

4. Player display via missiles.

5. Playfield updating, checked only on even scanlines.

 

This keeps playfield and ball code separate so they'll never conflict with one another. Changing the color of the items wasn't a high priority and in most cases I can see it not being too useful anyway. The playfield changing is fairly limited, a simple altering between two colors, or more accurately two shades of the same color. Just something to liven up the playfield a bit compared to the bgcolor. I was worried about being able to turn on the player in time when updating playfield color and the playfield itself, but I think I've thought up a solution that should work with a couple restrictions in place. From what I've written, it looks like it just might work but it's not ready for testing yet.

 

And yeah, I'll be giving up the bgcolor changing. The way I was implimenting it was going to take up too much rom to store the data, and too much time on the scanline to load/alter. And for all that work it would still be too limited for the things I wanted to use it with. For this room display kernel tho, having it a single solid color will do fine. I plan on doing different rooms that should be able to have more detail here and there, or be able to display more monsters at once without flickering madly, etc.

 

I'm still working on the code, and fairly early in it so no screenshots/binarys to share this time. (And I'm about to go to bed for the night as it is!) but hopefully I'll have something to show next weekend. The plan for version 0.009's demo is to display 2 objects with a mostly symetical playfield - the ball will be used to slightly alter one side to give the illusion of it being an asymetrical screen.

 

I also plan on removing the hardwired player screen-clipping. (that keeps the player from moving off the screen.) and enabling the variable-based screen clipping. The variables have been declared for several versions now so might as well officially go in and replace those 4 constants with the variable names, and then init those variables. At this stage they'd just be inited with the same constants, but later on it'll be defined during room-loading.

 

Yeah, I have ideas for how I'd use those changable clipping limits already.

 

But for now, sleep.