As an old C64 hacker that implemented several sprite multiplexers I can write more about the difficulties they had. First, the characters used one multicolored

As an old C64 hacker that implemented several sprite multiplexers I can write more about the difficulties they had. First, the characters used one multicolored sprite(which gives you double-width pixels), and on top of that sprite they put a black-bordered monochrome(single-pixel widths) sprite to give the characters a cartoony feel. Maybe the memory savings was from reusing frames from one of these sprites, I don't know. All the above is for above the waist. Then, when the raster has painted the last line of those sprites, an IRQ occurs and the sprites are moved 21 pixels down and have different frames and perhaps even new colors assigned to them. This is where the difficulties happen. You have to update 8 sprite y-positions and 8 sprite frame indices. Also up to 4 colors if that is also changed. You only have one scanline(63 cycles) to do this and one update is LDA + STA = 2 + 4 = 6 cycles. So 8+8+4 moves is 20*6 cycles = 120 cycles. Just less than 2 scanlines. They could have solves this by spreading out the sprites a bit in the y-direction so they had to do less but one more scanlines. I don't think anyone would even see this. Most sprite multiplexers sorted the sprites by y-position and then did one IRQ per sprite. If you did this you'd do much less each time and if you could spare the IRQ overhead you'd easily could have 32 sprites on-screen.