Extra Large Bitmap (52 pixels)

Set COLUP0, COLUP1, and COLUPF to black; COLUBK to yellow. The players and two missiles are used for the right 50 pixels; the Ball can take care of blocking off the left portion.

supercat, on Sat Feb 25, 2006 6:20 AM, said:

That's just 51. And for 52 pixel you need 7 bits of PF2 enabled, resulting into 56 pixels. So the ball has to blank the superfluous 4 pixels then and you only get 50 pixels.

Maybe there are two completely blank columns?

BTW: The logo is looking very cool. Are the colors animated?

You could add an easter egg that makes it read fore-play

Thomas Jentzsch, on Sat Feb 25, 2006 3:42 AM, said:

I think you misunderstood my idea, but it could be improved upon anyway: 56 pixels wide (assuming the leftmost four and rightmost four pixels are as pictured), PLUS get a free highlight (as in the "DELUXE' of "STRAT-O-Gems DELUXE"). Use one missile for the leftmost four pixels and one for the rightmost four pixels (note that the pixels would sometimes have to extend outside their "zone", but that would be harmless). Use "score" mode to free up COLUPF for the highlight.

supercat, on Sat Feb 25, 2006 12:54 PM, said:

You mean quad-width missiles, right? So on either side you could have a row of 4 pixels or no pixels. If I understand correctly, that would limit the shape of a 56-pixel bitmap.

supercat, on Sat Feb 25, 2006 6:54 PM, said:

So you will shift and resize missiles to form the left and right four pixels, right? I wonder if you find enough cycles for that. Can you describe that a bit more detailed please?

Without resizing and double-width missiles, three pixel on the left and two pixel on the right seem possible.

Quote

How should that work?

Thomas Jentzsch, on Sat Feb 25, 2006 1:58 PM, said:

I think he's referring to the fact that the BL is a different color from the PF in "score" mode. One of Stella's more obscure quirks.

Anyway, here is how the 52 pixel bitmap works. Supercat's description is pretty close; the missing detail is that you can use a combination of ENAM0, HMM0, and NUSIZ0 to create a two-pixel sprite with a missile. In order to free enough cycles to update all those registers, I use immediate addressing to load the data. That means that there is a separate block of code for each line. The 52nd pixel takes a lot of overhead, but if you are already bankswitching and don't need a full 32K, you've got the space for it. Note that the immediate addressing also means the shape and colors are static.

The other issue Thomas brought up is what to do with the playfield. I use transposed symmetry, and leave a gap of 13 playfield blocks. The PF looks like this:

0000|00011111|11000000|0000|00011111|11000000

COLUBK is then changed twice per line.

Here is an example of one line of code:

;Line 39
sta HMOVE
lda #2
sta ENAM0
sta ENAM1
lda #0
sta ENABL
lda #%00000011
sta NUSIZ0
lda #%00010000 ; player sprite 2
sta GRP1
lda #%10001001 ; player sprite 3
sta GRP0
lda #$1e
sta COLUBK
lda #%00011100 ; player sprite 4
ldy #%11100010 ; player sprite 5
ldx #%01100010 ; player sprite 6
sta GRP1
sty GRP0
stx GRP1
sta GRP0
lda #$00
sta COLUBK
lda #0
sta HMM0
lda #%01100000 ; player sprite 1
sta GRP0
sta WSYNC

I wrote a quick C program that converts a BMP file to ASM code. I'll post it after cleaning it up a bit.

Zach, on Sat Feb 25, 2006 8:03 PM, said:

Hey, I didn't know that.

Zach, on Sat Feb 25, 2006 2:26 PM, said:

I would think that if you weren't having to change COLUBK twice per line you'd have enough cycles to move around two missiles like I described for a 56-pixel sprite. The Ball could then add a moveable highlight without requiring any cycles within your kernel (just load HMBL with $10 and leave it).

Note also that you can combine loads for things like enable, move, and NUSIZx in various useful ways to free up some more cycles.

supercat, on Sat Feb 25, 2006 10:40 PM, said:

I think I understand what you are saying. The technique you describe is for a bigger Four-Play logo, but not for a generalized 56-pixel bitmap. Correct?

Zach, on Sun Feb 26, 2006 1:13 PM, said:

Correct. It would accommodate the leftmost four and rightmost portions of your logo as you have them arranged, but some other arrangements could not be accommodated.

That's clever, supercat. Good thing I left it to your imagination before explaining the technique I used. If time permits, I'll make the logo a little wider.

I would like to see some working code, either from Zach or supercat. Both prefered!

Zach, on Sun Feb 26, 2006 2:30 PM, said:

Sometimes I like to see code, but oftentimes it's interesting to puzzle out what has to be going on first.

I think if you use the SELECT and RESET keys on my scrolling RPG demo you might be able to figure out how it works, but otherwise probably not; things really aren't as they seem on that one. Even using those keys, I'd suggest figuring out what's what (without using the object-disable keys) would still be tricky.