Jump to content







Photo

Extra Large Bitmap (52 pixels)

Posted by , 24 February 2006 · 110 views

Special thanks to Nathan Strum for the artwork.I'm sure that experienced programmers can imagine how to do a 51 pixel bitmap without flickering. Anyone care to guess how I managed 52? EDIT: Now explained below.

Attached Thumbnails

  • Attached Image

Attached Files






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.
  • Report

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

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?
  • Report
You could add an easter egg that makes it read fore-play :)
  • Report

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

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

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.
  • Report

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

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.
  • Report

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

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.

Quote

Use "score" mode to free up COLUPF for the highlight.
How should that work? :)
  • Report

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

Quote

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.
  • Report
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.
  • Report

Zach, on Sat Feb 25, 2006 8:03 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.
Hey, I didn't know that. :)
  • Report

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

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.
  • Report

supercat, on Sat Feb 25, 2006 10:40 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.
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?
  • Report

Zach, on Sun Feb 26, 2006 1:13 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?

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.
  • Report
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. :)
  • Report
I would like to see some working code, either from Zach or supercat. Both prefered! :)
  • Report

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

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.
  • Report

May 2012

S M T W T F S
  12345
6789101112
13141516171819
202122 23 242526
2728293031