Zach's Projects

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.

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.

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

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.

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.

 

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.

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".

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.

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).

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.

 

Use "score" mode to free up COLUPF for the highlight.

How should that work?

Use "score" mode to free up COLUPF for the highlight.

How should that work?

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.

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.

Hey, I didn't know that.

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:

 

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.

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.

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?

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?

 

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!

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.

 

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.