
The Greatest Justification For Messed-Up Video Game Graphics - fogus
http://kotaku.com/5901905/the-greatest-justification-for-messed+up-video-game-graphics-i-ever-saw
======
Flow
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.

~~~
jaylevitt
That's also why Q-Link had the signature "squiggly menus" that acted as the
AJAX spinner of the day... it drew the menus by changing the background color
at a certain raster line, and the Commodore's serial routines (completely
implemented in software) had to disable interrupts while they sent or received
data.

I seem to recall Ray Kelm worked around this for the CNet/Image BBS sysop
console in his custom high-speed serial routines, but I may be conflating
stories. (Commodore's serial routines couldn't go far above 2400bps; Ray
managed to get 9600 working reliably.)

------
rbanffy
Without an explanation of why they had to make waistlines transparent to
enable multi-player mode, it doesn't look very convincing. Couldn't they just
move the torsos down or the legs up one pixel? I'm sure the C64 graphics
hardware allowed that.

On an Apple II, I was, once, asked to move something half a pixel to the left.
And I did it. ;-)

~~~
chris_wot
I'm going to sound very stupid, but how did you do it? :-)

~~~
rbanffy
On the HGR modes, every 7 pixels of a line were packed into one byte - 40x7 =
280 pixels per line. The 8th bit switched the whole byte half a pixel to the
left. This was also used to make different colors - the timing change shifted
the pixels in relation to the color cycler, making the colors available in
that 7-pixel group different (pink and green for off, blue and orange for on).
White was done with two contiguous pixels.

I think early IIs didn't have this 8th bit magig, but, from the II+and on, all
IIs had it.

~~~
chris_wot
Wow! I've heard of some neat performance hacks, but that's pretty cool - the
only one better was the hack that was done to get rectangles with circular
corners on the Mac.

------
antidaily
It was either that or remove Abobo's mustache. Clear choice.

------
bitwize
Man I wish Capcom had traded glitchy graphics for the ability to swap
characters in in PlayStation _X-Men vs. Street Fighter_...

