NEWS, EDITORIALS, REFERENCE

Thoughts About Graphics

By today's standards, of course, the C64 has very limited graphics. But in the early 80s when the computer was first released, its graphics were pretty badass. Its 320 by 200 pixels was considered to be quite high resolution. It was high enough that Commodore redesigned the on screen font of the C64 to be thicker so it would be clearer and easier to read at the READY prompt. [See Update: Dec 19, 2016] That's because the higher resolution screen than, say, the VIC20 would have made its font thin and the monitors of the day weren't very clear. It would have been difficult having a much higher resolution on the same physical output, S-Video. This is also likely the reason they chose Lt. Blue on Dark Blue background. If you've ever messed around with various combinations of fore- and background colors, blue on blue seems to provide the least horizontal color bleed.

The C64 also only has 16 colors. Not only 16 colors, but there are numerous other limitations on how many colors can be displayed within an 8x8 pixel block. Only 2 colors in hires mode, and up to 4 colors (still a huge limitation) if you dramatically sacrifice horizontal resolution down to only 160 pixels. These limitations of course, like everything, are not just because the hardware was crappy but because the C64 already pushed its 8-bit CPU to its outer limits. With only 64K of ram, think about how much memory bitmap data occupies. Imagine if the VIC-II chip could somehow support 256 colors per pixel without any other limitation. 320x200 is 64000 pixels. 256 colors means 8-bits, or one byte, per pixel. Well... that's 64000 bytes, or ~64K. One single static image at the low-resolution of 320x200 and 256 colors, would require every single kilobyte, byte and bit of memory in the entire machine. There would be no room left over for code to set those bits!

The graphics limitations on a C64 are the result of careful design decisions around the right balance of power and flexibility, while not using up so much memory that you can't reasonably work with the graphics data along side your game or other code. Despite these limitations the practical graphics capabilities of a C64 definitely increased over the years, mostly due to the creativity of the artists and their increasing experience with the medium. But also due to some pretty clever programming tricks that when timed correctly allow the CPU to play some role in producing the graphics. Here are some examples of the progression:

M.U.L.E. is widely considered to be an excellent game. It was released in 1983 by Electronic Arts, only a year after the C64 was released. Its graphics are notably quite primitive.

But by the late 80s and early 90s in-game graphics had improved dramatically. Monsters in Mayhem was released in 1993 and is ranked by many as some of the best in-game graphics. Backgrounds move in parallax, foreground objects use shading techniques to make them look 3D and the sprites of characters are fast, rich and animated. And these graphics have to move on screen in response to the gameplay, so this level of graphics is extra impressive.

Demos and demoscene coders took graphics on the C64 to a whole new level. The above image is captured from a 2005 demo. It uses the CPU to change parameters of the VIC-II chip, timed very carefully, to produce an interlaced image. The result is stunning. From M.U.L.E to this! Wow.

There are a few downsides to demo-level graphics. First, because they use the CPU to assist in the display, and because that assistance is highly time-sensitive, and because it often involves storing more than one full-hi-res screen worth of bitmap data, the machine is being taxed heavily just to present and maintain that static image. Still, it looks great. If what you want to do is look at a really great graphic then the trade off is worth it. You just won't be able to create a game with graphics this good, you can forget about fullscreen animations and so on.

There is another problem with graphics like this. They are often the result of masterful artistry. The people who produce these images are artists, graphicians, who slave over their pixel-editing tools and tweak everything to produce a work of art that they submit to a competition. This in itself is not a bad thing, art is great, anyone can appreciate great artwork. The problem is that in the real world you might want to look at a picture of your kids, or a picture of your sister's kids. Or you want to see something out there in the world that exists but that has nothing to do with the C64 and no other C64-using artist has any interest in it.

For this, in steps what I considered to be one of the most amazing steps in C64 graphics ever taken. JuddPeg. Steven Judd and Adrian Gonzalez wrote a JPEG decoder for the C64 that decodes and renders any arbitrary JPEG graphic as an IFLI. IFLI is one of the most advanced CPU-Driven graphics modes that democoders can utilize. Interlaced Flexible Line Interpretation. JuddPeg can take any JPEG (as long as it's small enough) and make an IFLI out of it. The results speak for themselves. Here are some images from Star Trek Enterprise that I rendered up the other day just for fun.

It was hard for me to capture these with my camera, because the interlaced nature of them meant that when I snap a photo, the camera would often only catch one of the two rapidly shifting on-screen images. I caught these by taking a short film of the screen and then selecting a frame that somehow managed to blend both parts of the interlaced image. They don't quite do it justice, in my opinion they looked a bit better to my eyes than to the camera. I don't know if I can say these images are quite at the level of what a graphic artist can produce. There are still a few hard to avoid artifacts that creep into these renders. But, come on, they are extremely impressive considering that you can get this quality out of any old image of anything in the whole world, rather than just those select few subjects chosen and crafted by an artist.

Now for the downside. Is there a downside? Yes, actually, there is. Each of the JPEG files above were about 19 or 20K on disk. After loading the data fully into memory, JuddPeg took MORE than 5 minutes and 35 seconds, to decode and render one image. Ouch. That's a long time to wait for a picture of Captain Archer. Especially considering that you don't even know if it's something you really want to see until after you've had to wait to see what it is. The other problem is that the world wide web rarely serves up useful images of anything you might care to look at in a resolution so low that it's only 20 kilobytes.

Conclusion

When I was younger, and the C64 was more of my fulltime computer, and PC specifications were meteorically skyrocketing, I hated the idea that our C64 would have to rely on outside computing resources to accomplish something. What the hell was the point of getting a Linux PC installed and setup in your house, only to feed your C64 stripped down versions of things? If you had to have a PC beside your C64, then it wasn't really your C64 doing it any more. That really bothered me.

Something has changed a lot though in the last 10 years. The internet has become completely and totally pervasive. And many devices have become low-power, small screened, mobile devices. The internet is no longer just a source from which information can be downloaded, it has become a computing service layer. Cloud-Computing as the buzzword refers to it. Your smartphone for example which may have more limited storage capacity than your laptop, and a much smaller screen, no longer needs to have complete copies of all your photo library, at full resolution, stored locally. There is no point in that, those resolutions and that storage capacity is too big and overkill for the limitations of the device in your pocket.

Ah... something is starting to sound familiar. It is now common place and totally sensible to let a cloud-computing service feed to your device data that has been scaled to better suit the device's capabilities. Computers hosting content on the internet already process data on the fly before sending it out. Many webservers GZIP compress content in realtime and it hardly fazes them. Modern computing hardware, that is out there, serving up the internet, can scale a JPEG down to 320x200 or smaller, in negligible time. They could also convert a JPEG, or any other graphic format such as PNG or even SVG or PDF into a C64 IFLI format in negligible time. The only problem is that most webservers in this world don't have those abilities built in, and never will.

Here's what I'm proposing. That we create a suite of web-services, specifically designed for proxying, scaling and converting content from the web to a target size and format natively suitable for the C64. The most obvious use case is for graphics, but in future posts I'll be discussing what might be done with HTML, MP3s for music and podcasts, and more. Once a set of services like this are created, we could get a handful of people to configure these proxying services on Macs and PCs that already spend their lives just idly hanging out with persistent connections to the internet. And if we maintain a list of available proxy addresses we can distribute the load and uptime across many volunteers.

A C64, a breadbox C64, with an ethernet cartridge running appropriate software, such as C64 OS and a program written for it, could request a graphic from the web by sending the URL of the graphic to one of these proxies. The proxy downloads the graphic, scales it down, converts it to IFLI just like JuddPeg does, and sends us just the ready C64 data. And bingo-bango, we're staring at the highest quality images the C64 can muster, of anything we could possibly want to look at from the entire web, only seconds after we make the request to see it. And you don't need to install, maintain or configure a PC to do any of it in your own house. That's what I want, and this is one of the things I'm working towards with C64 OS.

http://c64os.com/services/xxxxxx will be one of the proxies that will be useable. Hell, maybe one of the services will be to maintain a list of other active proxies!

UPDATE: September 10, 2019

A suite of proxy services are indeed now available, and growing. See http://services.c64os.com/about for the most up to date information, and documentation. And also see the post Webservices: HTML and Image Conversion for further discussion.

UPDATE: December 6, 2016

After attending World of Commodore '16 I was reminded that I really should be keeping up with the latest demo competitions. Because, they really are stunning. Then I saw the following in one of the top ranked demos. If there was any doubt in your mind that demo coders see themselves as artists, this should help you get over that.

UPDATE: December 19, 2016

I knew that I'd read about this somewhere. Originally I saw it online when reading about PETSCII and changes between the VIC-20 and C64's fonts. As I was reading through the C64 PRG on graphics programming, I stumbled upon this nice little hint box. It recommends making the vertical strokes of custom fonts two pixels wide. This minimizes the CHROMA noise color distortion.

But, if I were to correct myself, it's not because the monitors of the day were poor quality, it's because the C64 and VIC-20 were originally expected to be connected to TVs, as indeed mine was for many years, via the RF-modulator.