I know that on the C64 sprites are supported in hardware via the VIC-II chip. What I don't understand is the fact that what I'm reading in documentation seems to contradict what I see on my actual C64.

C64 graphics documentation seems tells me to the effect of, "given multi-color sprites, three sprite colors are held in common, each sprite gets one unique color. There is also a fourth 'color' (bit pattern) that indicates transparency."

This seems to contradict what I see on screen. I'll use one of my favorite C64 games, Save New York as an example. It's an addictive single-screen game that I had a lot of fun with as a kid. Well, the bugs/aliens all have one color set. The fuel drop aircraft have another set of colors that aren't the same as the bugs. The player 1 and player 2 aircraft are mono-color, so they're treated a little differently than multi-color sprites.

My questions are:

* If the above is true about how sprites work (and I don't have it all backwards) how is it I'm seeing sprites that don't share few if any common colors?
* I know that today, given a cross development environment like 64tass or Acme, most programmers loop over their sprite data files and build the sprite in memory. I've even see the technique but now that I'm looking for an example of it I can't find it. Can someone point me in the right direction?
* I know that sprites have one of four bit patterns which get correlated with a color. Where is that set?
* Are there good books / reference articles that detail in depth different sprite tricks?

Don't know if it helps but this series of blog posts about the VIC-II seemed well done to me:

As BigEd notes, there are workarounds to give the illusion of higher-color sprites - since each sprite can have one unique color, you can overlay multiple sprites on the same space to create a single image with more than just the three colors. A common technique is to use a multicolor sprite for colors and put a black monochrome/high-res sprite on top of that for outlines, which (when used with careful pixel-art work) can make it look like a hypothetical high-res multicolor sprite.

Of course, the actual hardware limits remain (one or three colors per sprite, no more than eight sprites per scanline even with multiplexing,) but depending on what you're trying to accomplish and how well it fits into the visual style of your project, it's a useful trick.

The C64 Programmer's Reference Guide will walk through all the bit & register basics, to get your footing.

Each sprite has a dedicated independent color register ($d027-$d02e), then there are 2 other shared sprite multicolor registers ($d025-$d026).

Monochrome sprites use pixel values

• 0 = transparent
• 1 = sprite color

Multicolor sprites use pixel values

• 00 = transparent
• 01 = shared multicolor 0
• 10 = sprite color
• 11 = shared multicolor 1

So the shared color values are shared only between multicolor sprites. Hi-res sprites each only use their fully independent color.

In Save New York, looking at youtube footage, I would guess that the top of the screen uses 8 sprites, and the bottom (trains, walking characters, etc) are multiplexed separately from the top ones. There is likely a single x-expanded sprite per train, as it seems to fit in 11 4-pixel-wide colors in width.

The invaders use black, white, and blink red/light-red (eyes/mouth). The package-dropping planes use blue, white, and blink red/light-red (exhaust). The pakages are white and blink red/light-red. So it seems obvious that with the 2 shared colors, one is white and the other alternates between red & light-red. The invaders' individual sprite colors are set to black, the support plane's color is blue. The player sprites and bombs don't use multicolor, so they set their own directly.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

It's also worth noting that reusing sprites on different scanlines, and even reprogramming the VIC-II for individual scanlines, is not only possible but very common in the demoscene. The VIC-II can display a maximum of 8 sprites on a single scanline, but the sprites can be moved or reconfigured by the time it displays the *next* scanline.

Regarding this question, I'm not exactly sure of the scenario you're describing. There's a few cases where something like this might happen:

- Many programs use stock compression or linker utilities like exomizer, which can copy binary data to various areas of RAM. You tell the compressor which binaries you want to load in where, and it packs it all together into 1 executable that will decompress all the data to where it needs to be. So this can have program code in one place, data in another, and drop sprite data right in the proper locations for immediate display.

- The VIC-II chip only can see 16KB of memory at once, so if you have a lot of sprite frames, all of them might not fit simultaneously in a VIC-II bank along with fonts, character screens, bitmap screens, etc, and only those which are currently needed get copied into the VIC-II's view.

- It's kind of wasteful to have horizontally flipped versions of all your animation frames, so copying them in manually allows you to perform inline transformations on them, instead of just pointing to different statically defined frames.

- Keeping sprites compressed in RAM (like only storing 8x8 pixel sprite data for bullets or something) and decompressing them into full 63-byte sprite frames as needed can save a lot of memory footprint.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

.

I'm going to try to hunt down an example for discussion.