> Sidebar: A note on frames per second. The European PAL C64 updated at 50fps, whereas the US NTSC systems updated at 60fps<p>This is because alternating current is 50Hz in PAL countries (eg Europe), and 60Hz in NTSC countries (eg America). Analogue TVs vertical refresh rate was synced to the AC frequency for a bunch of practical reasons, which meant gaming consoles had to send signals to the television at either 50Hz or 60Hz.<p>Result? Many PAL console games actually ran at 5/6ths of NTSC speed. Most notoriously, Sonic the Hedgehog, whose agility was more sluggish (and soundtrack less vivacious) for a large fraction of the world. More information in this video: <a href="https://www.youtube.com/watch?v=cWSIhf8q9Ao" rel="nofollow">https://www.youtube.com/watch?v=cWSIhf8q9Ao</a>
If you want to see how this type of colour magic works in video form, the 8-bit guy does a GREAT video on this:<p><a href="https://www.youtube.com/watch?v=niKblgZupOc" rel="nofollow">https://www.youtube.com/watch?v=niKblgZupOc</a><p>He shows all the interesting artifacting that makes these extra colours possible.
Here's a great older example of this technique (and a couple others) used on the TRS-80 Color Computer 3 to show "hi-color" bitmaps on a machine with a 16 color palette:<p><a href="http://users.axess.com/twilight/sock/hicolor/hicolor.html" rel="nofollow">http://users.axess.com/twilight/sock/hicolor/hicolor.html</a>
Reminds me of another piece of magic I used to use during my Amiga demo days. Infinite Bobs. A Bob was a BlitterObject, a graphic rendered by the hardware, not dissimilar to a sprites.<p>People would try many things to render as many Bobs as possible.<p><a href="https://www.youtube.com/watch?v=eDQTxbudvDg" rel="nofollow">https://www.youtube.com/watch?v=eDQTxbudvDg</a><p>At some point the infinite bob demo appeared (I couldn't find a video for this). Seemingly endless sprites rendered on the screen - all moving, with no slowdown. As a 15 year old programmer learning to code demos in assembly I was very confused, how was it done?<p>I did eventually (after many hours spent in devpac disassembling code) work it out. They were not rendering infinite bobs, they were rendering one!<p>If you create three screen buffers. On the first screen buffer draw the bob at position (x,y), then switch to the second buffer draw at (x+delta,y+delta), then switch to the third buffer and draw at (x+delta,y+delta) and then repeat the cycle through the buffers as you move the bob.<p>If you switch between the buffers on the vsync (50/60hz) then the difference between where you drew the bobs appears like movement. You can draw out infinitely complex patterns and make it look like you're rendering millions of bobs!<p>Happy days.
This overlooks a key detail, namely interlacing. The C64 wasn't producing 60 frames per second, but rather 60 <i>fields</i>: sets of odd or even scanlines. So on the CRT TVs of the time, you'd get one colour on the odd scanlines, and another on the even scanlines. Scanline striping, essentially.
I once toyed with Temporal dithering on VGA ModeX.<p>While the bullet point listed resolution for standard VGA was 320x200. Hitting the hardware registers and paying the price of a rather peculiar addressing mechanism for pixels you could get a lot more(and double buffering to boot).<p>320x240 was the most common tweaked mode, because it gave you square pixels and page flipping.<p>At the edge of what momitors could handle there was a 400x300 mode which ran at 87Hz Flipping two images with this mechanism give you a 43Hz shimmer, which is amost impossible to pick on colours if the two components are similar luminance.<p>I never saw this get used for anything, but it would have made an excellent paint program for standert VGA.
If using composite video and a PAL TV, you can also blend colors by using alternating horizontal stripes because PAL TVs use a delay line to cancel the chroma information with the line above it. Exactly what color you got would depend on the specifics of your TV's decoding.
This is very similar to how "grayscale" is achieved on a TI-83 calculator to make games like Zelda and Desolate (<a href="https://www.youtube.com/watch?v=5UHqPMxeZnY" rel="nofollow">https://www.youtube.com/watch?v=5UHqPMxeZnY</a>) possible.
Off topic-ish: There was a trick you could use on the Atari ST to display more than the allowed number of colours - you reloaded the palette data on each horizontal interrupt. Could this have been used on the C64 also?
Brilliant talk on using these techniques to draw hires color pix on c64. The NUFLI technique is based on combining hires mono images with color sprites underneath AND color flashing.<p><a href="https://www.youtube.com/watch?v=bKk0m-GDFdc" rel="nofollow">https://www.youtube.com/watch?v=bKk0m-GDFdc</a>
Incidentally, this type of temporal dithering is how 18-bit LCDs can approximate 24-bit colour:<p><a href="https://en.wikipedia.org/wiki/Frame_rate_control" rel="nofollow">https://en.wikipedia.org/wiki/Frame_rate_control</a>
I remember writing a piece of machine language on a C-64 which flipped the color palette as fast as possible. It was so fast that all you saw was individual horizontal line segments of different colors within every individual raster line. (I.e. it was faster than the <i>horizontal</i> refresh rate of the CRT which is usually what, well over 10 kHz.)<p>Sheesh, when was that? Probably 1985.
This is cool, but I've never understood why people like the C64 palette. It looked washed out to me.<p>I guess people grow to like the look of the machines they have fond memories of. (Apple II, Coco, Sinclair)<p>The Amiga was the first machine to really impress me with its pallete.
These kinds of tricks remind me a bit of how the Apple II produced color using the timing of the NTSC signal, or how Thexder tried to produce more colors <a href="https://www.youtube.com/watch?v=fBL2rtCdpZ0" rel="nofollow">https://www.youtube.com/watch?v=fBL2rtCdpZ0</a>, or how the demo 8088 MPH produces more colors than the CGA composite mode was intended <a href="https://www.youtube.com/watch?v=yHXx3orN35Y" rel="nofollow">https://www.youtube.com/watch?v=yHXx3orN35Y</a>
These were the "magics" you were able to do at that time!
You could achieve amazing and unexpected results going beyond common software programming, mixing software with phisical effects for example.
This was the reason the author of the article got so impressed.
I don't know what kind of todays's unconventional programming technique can achieve such a wow effect!
Side note: i was 14 too in 1991...incredible times, such as mid '80s!
I think this type of instance maybe why the C64 has the reputation of encouraging hackers that it does. This is the perfect example to me of hacking to make something better.
Question: the demos on the website are not smooth in my mobile chrome browser. Is it even POSSIBLE to get glitch free per display frame update in a browser? I grew up with the c64; the kind of tearing and frame-rate glitches we see on nearly every other platform since make me sad!
The page <a href="http://vik.cc/dvik-joyrex/download/105Colors.ppt" rel="nofollow">http://vik.cc/dvik-joyrex/download/105Colors.ppt</a> has an algorithm to convert a 24-bit RGB to interlaced 8-bit on the MSX palette.
Cool article, but the Spectrum really only had 7 colours and black. And at the time I hated the Commodore 64's colour palate (and any non ZX Spectrum palate, until I saw the beautiful SAM Coupé's) so I guess it's a matter of preference.
Near the bottom, I wonder if high-speed img flipping in js could be done by absolute-positioning the two images and toggling display:none/display:block (or flip the z-index above/below) on the upper layer on every animation frame?
I guess it's all about which 8-bit we have fond memories of but ... the C64 is not known for having a great palette. It looks rather dull and washed out.<p>The Amstrad CPC probably had the most vibrant palette of all of the 8-bits.<p>A C64 artist even tried to prove otherwise, but IMHO scored an own goal : <a href="http://www.indieretronews.com/2016/02/is-c64-palette-far-superior-to-amstrad.html" rel="nofollow">http://www.indieretronews.com/2016/02/is-c64-palette-far-sup...</a>
I would think answer is NO, but (why not) is there a way to synchronize painting of the picture with the vertical synchronization of the screen in modern browsers, to prevent flickering?
As an Australian user of the TRS-80 Color Computer I was always disappointed the artificating technique:
<a href="https://en.wikipedia.org/wiki/Composite_artifact_colors" rel="nofollow">https://en.wikipedia.org/wiki/Composite_artifact_colors</a>
... didn't work on PAL so I never got to see all the 'cool' colours promised on game adverts in USA-based magazines!
I'm wondering why they went with a dragon boss that flipped from one solid color to the other - wouldn't switching between a checkerboard pattern of the two colours have worked better?
Reminds me of the Future Crew demo that used similar techniques to emulate "thousands" of colors on a 256 color display. Very unimpressive in YouTube videos. Amazing on a CRT.