Before I get started here, I'd like to say thanks VERY much to Joe Huckaby for reviving these old images. Since I've already heard people wonder, I should say that Joe did so with my foreknowledge and permission. I have known him since he was a high school freshman - and a very talented programmer even then. He and I both worked on a project for which some of the most elaborate of these images were created 17 years ago.

For years I have wished there were some way to show people visiting my website what these pictures looked like in motion, but, until recently, there was no way to display color cycling online. Apparently, the challenge had never ceased to intrigue Joe, and when he called me out of the blue a few weeks ago to say he'd finally cracked the case, and wanted to demo it with old cycling images of mine on his site, I was delighted, and told him to go right ahead, as long as there was no 'commercial use' of these specific images involved. Then I went back to what I was doing, having no clue anyone but him and I and ten or twelve of our friends would care. Joe had done this largely as a favor to me, I suspect, and had no more idea than I did of the interest these images would evoke.

Then, I got to work on Monday to find my colleagues glancing at me oddly and talking about articles on Kotaku - and Reddit - that I knew nothing about. Now, one week, a lot of rather shocking attention, and a few hundred thousand website hits later, Joe's asked me if I'd help him answer some of the questions most often being asked about these images. It is, of course, my pleasure and honor to do so.

I would also very much like to thank the many great and greater websites that have helped expand awareness of Joe's achievement and its possible relevance to the ongoing evolution of the HTML5-o-sphere, and to all of those who have written him and me so generously to express their enthusiasm and appreciation for these pretty old pictures. Thank you. Very much.

So then ... Those questions:

It will take some time to answer your question too! :D

At the simplest, most basic level, color cycling creates the illusion of animated movement in pretty much the same way light bulbs on a theater marquee do.

When the light bulbs on a theater marquee flash off and on in the right sequence it LOOKS like little dashes of light are chasing one another around the perimeter of the sign. But, as we all know, the individual light bulbs are not moving - only turning off and on in a coordinated sequence that creates the illusion of movement. In color cycling, each affected pixel on screen is holding completely still, like those marquee light bulbs, but changing colors in a looping sequence - which, in coordination with all the adjacent pixels changing colors in their own offset sequences creates the illusion of moving bands of color.

By carefully arranging different 'moving bands' of color next to or over one another, masking or blending or disguising those moving bands in various ways, all sorts of surprisingly convincing 'continuous and repetitive movement' effects can be simulated, as seen in the images recently revived by Joe Huckaby. If I attempt explanation here of all the specific tricks and techniques I've used to create the many effects achieved in these images, you'll have no choice but to quit reading long before I've finished, so I will leave my answer at this for now, with one important caveat:

While the following likely seems obvious, the ingenious open source code Joe recently made available finally enables this kind of 'apparent animation' to be viewed online now, but both the pixel art file itself and its attendant palette(s) must still be carefully constructed beforehand to make these effects possible, just as the light bulbs and wiring on those theater marquees must be carefully arranged beforehand to enable whatever illusions of movement they will create when 'plugged in.' One cannot just take Joe's open source code and apply it to any 8 bit image, and expect more than a simulated acid trip to result. :D

These versions of the scene are all the same piece of art 'shifted' to different palettes, and, in some cases, using additional 'baked in' overlays, (such as rain or the lighted windows at night). But those overlays are all 'baked in' to the same layer of the same piece of art that appears in any other 'day-time' or clear weather iterations, and are all deriving their color and motion from the same palette as the rest of the picture in that state.

While Joe's recent post finally allows us all to watch these images color cycle online, many of the scenes posted were actually 'built' to do much more than merely animate. By fading the one piece of art through whole sets of palettes, sometimes also using a very sparse set of 'baked in' overlays, a number of these scenes can go seamlessly through the 24 hour light cycle, and even change weather conditions 'naturally' and seamlessly in real time as you watch. I am not just talking about changing the brightness or color scheme of these pictures either. In the images built for it, over the course of 'sunrise and morning,' 'morning to afternoon' or 'evening and sunset,' light and shadow will actually gradually change angle, climb down the sides of things, move across lawns, up cliffs or building walls, as changing light does in life - all just by fading through palette series designed to make those things happen without altering or adding anything at all to the single layer of 8-bit pixel art.

In fact, for a little plug-in-controller "X-men" game I helped produce for Jakks Pacific four or five years ago, I built a single picture that changed from a Manhattan style city-scape full of buildings and smoggy sky, to a bucolic forested valley scene with far off hills and whispy clouds, to a high-atmosphere stratus-cloud-scape - each at three different times of day - just by switching the one picture to any of nine different palletes. Change the palette, and get a picture containing completely different content as well as different light and color. These scenes also scan-line parallaxed fairly elaborately - and all of this still left nearly half of the available 256 color pallete space unused. (Yes, aspects of this process do involve a fair share of chicken entrails and powdered dragon tooth applied by moonlight on the winter solstice, so don't try this at home, kids.) :D

As it happens, I do have quite a few other old color cycling images around than Joe hasn't posted on his demo site yet. He and I are looking into getting at least a few more of them up and viewable on my website and/or his in the near future. We are also looking into the possibility of getting some of the currently posted images more 'fully functional' again than they are right now. Hopefully, at some not too distant point, anyone interested will be able to watch some of these scenes not only animate but change in all the ways I have described above - on Joe's site and/or mine. (www.markferrari.com)

Thanks for asking. I do need to make it clear that all of the images Joe posted, and most of the remaining body of my as yet un-posted color cycling work, were used in various published products during the 80s and 90s. Such art was invariably 'work for hire' and is thus all encumbered by copyright and licensing restrictions that currently render them unavailable for any commercial and/or unauthorized use even by me. As far as I know, neither Joe nor I have any legal right to use these images in anything but 'display' capacity, and not even that in some cases.

That said, I think it safe to say that at this point we are very interested in talking with the current license holders about what if any new commercial use of these images might be arranged. So - stay tuned to find out what develops...

As for porting such images to Javascript or other formats, you'll have to ask Joe about that. While I am a reasonably talented artist and a creative and unconventional thinker, I am an astonishing techno-ignoramus. I was born waaaaaay on the 'dark ages' side of the techno-generations line. For me, 'Java' is still, and always will be, coffee.

I do not acknowledge this just to flame myself while everyone is watching again for a minute. I bring it up by way of saying that, ironically, most of the 'unconventional' uses I devised for dither, color cycling, and pallete shifting 'back in the day' came into being precisely BECAUSE I did not really know what I was doing.

Anyone who remotely UNDERSTOOD how techno-things worked back when I was first hired by Lucasfilm Games, purely on the strength of my artistic abilities, would have KNOWN that 'dither did not compress' and thus known better than to try making EGA art look like VGA art by dithering those 16 awful EGA colors into 'more useful and pleasing' combinations. But, being a techno-moron, I had no idea that I shouldn't try that until a bunch of coders charged into my office wailing like banshees after I tried using dither on backgrounds for Zak McKracken and the Alien Mindbenders... (Remember when games had titles like that - and humor like Ron Gilbert's and Steve Purcell's - instead of just a lot of grunting and squeaking things to punch, stab, and shoot? If you're thirsty for another taste of that kind of game sensibility, do go check out Ron's latest computer-game offering, "DeathSpank" :D The name says it all, I believe. LOL) Anyway, those programmers set me straight in a hurry, and I finished Zak M using only solid EGA colors, like a less clueless boy. ... But a few months later, they figured out how to compress dither at Lucasfilm, and we started working on Loom - with backgrounds using extensive EGA dither. That game won a lot of graphics awards that year, as I recall.

Someone who KNEW that Java wasn't coffee anymore would doubtless also have known better than to imagine that color cycling was good for much but garish bands of moving color or the 'parlor trick' effects demoed in the DPaint II example screens. A legitimate techno-savant would also have understood from the start that pallete swaps, like the ones that used to happen 'auto-accidentally' whenever you loaded one DeluxePaint art file before closing the previous one, weren't useful for anything at all - but I was much too out of touch to know such things. ;] So, if YOU know any clueless techno-tards, give'em a break, eh? Even they might grow up to be more significant has-beens than you'd ever guess at the time.

Just sayin' ...

Thank you! It took me anywhere from three days to three weeks, (8 to 14 hours per day), to create ONE of these images, depending on how many tricks of what complexity the picture was supposed to do - back when I was young and strong and still had an agile mind. Now ... it might take me a few days longer. ;]

The 'tool provided me' was the same one that almost all 2-D computer game environmental artists used back then to make PC games: Deluxe Paint - later Deluxe Paint II - by Electronic Arts. It was the industry standard background art tool for 10 years or more in the 80s, and handled both indexed pallete management and stencil management better than any other indexed color art tool I've ever seen since. 'DPaint's' palette management and stencil features, along with the tool's very useful array of gradient-fill options - were essential to producing this rarified species of 8 bit pixel art.

That said, I did 'work out as I went along' how to use these DPaint features in ways no one had intended or foreseen, as far as I can tell, until the advent of 32 bit un-indexed palettes and algorithm-rendered '3-D' art made all such techniques impossible and/or irrelevant ... at least, until now, possibly? One of the benefits of that age's comparatively slow-paced technological development was that any one tool COULD be an 'industry standard' for ten years before becoming obsolete. This gave people like me time not just to learn the basics, but to master the tool so completely that innovative 'unintended' uses became possible. These days, the tools you're using will be so transformed and 'improved' every few months that no one ever has time to become more than adequately proficient with one version before having to abandon it and start becoming adequately proficient in the next one. not a lot of potential for mastery or innovating 'misuse' now. Who knows what potential lurked in the vast mountain of toys we've so briefly fondled and then tossed aside hardly explored during the past decade or two?

Today, the only commercially available tool I am aware of in which indexed, color cycling art like mine can be produced at all is Pro Motion by Cosmigo. It will open and save the .LBM file format these images were made and saved in, and it does allow for the creation, use, and preservation of cycling ramps of color in the image's 256 color indexed palette. There are, however, a number of problems with the way Pro Motion manages both the retention and display of palette cycling information, and the creation and retention of stencil data, which make creating and displaying cycling images like mine much harder to accomplish and display than they were when created in 'DPaint.' Before I elaborate any further on these deficiencies, however, I want to say a few things in appreciation and defense of Pro Motion and Cosmigo.

First, I am VERY grateful to Cosmigo for preserving this kind of art generation tool at all, and persistently seeking to improve it all this time. I HAVE used Pro Motion to create this kind of artwork for several commercial projects in the past few years. Were it not for Cosmigo, there would have been no way at all, that I know of, for me to do so.

Secondly, there was really no reason, or even any practical way, for Cosmigo to know about, much less address, some of Promotion's palette management and stenciling deficiencies in regard to color cycling artwork of this kind. That's because, to my knowledge, no one in the country - perhaps in the world - but me was ever plain crazy enough to carry the pursuit and use of these techniques to such, um, ... 'extremes.' I think that's one reason why these techniques, and the color cycling feature itself, vanished so completely as digital art tools evolved. A number of people in the industry had seen what I could do with color cycling. They recognized the potential benefits of that kind of art, and were impressed with my 'knack' for it, but who was going to keep developing color cycling tools - much less a widespread place for color-cycling in game development - just to accommodate one elusive idiot-savant in Northern California able to 'shake this rattle,' so to speak? As 32 bit 3-D art took over in the late 90s, I too saw the writing on the wall - or thought I did - and just let go as well.

Early in the 21st century, an admiring ILM art administrator perusing my collection of old color-cycling images during a job interview quite understandably referred to it as 'the most stunning collection of digital scrimshaw' he had ever seen. I wasn't offended. He WAS complimenting me, and his assessment was already appropriate even then. (Also, I did get the job.) So how could Cosmigo have guessed what was or wasn't important in palette and stencil management for producing this kind of image? Until this last week, even I didn't think there was any compelling reason anymore to bother them about it. If they ever want to discuss it, however, I'd be delighted to talk with them appreciatively and respectfully.

Having said all that, last time I checked, (admittedly, a couple of versions ago), Pro Motion simply applied whatever palette gradient and cycling information was present in the first file opened after launch to any subsequent files opened until the tool was completely rebooted. This meant that although the .LBM file format preserves all one's cycling and gradient info when the file is saved, an .LBM file will not display any of these properties correctly next time it is opened unless it was the first file opened after launching the tool. This can become particularly problematic when working on several .LBM files with different cycling/gradient information at the same time - often necessary while producing images like those Joe has recently posted.

Also there are a lot of procedures involved in the creation of such images that rely on the ability to save stencils that remember the X-Y POSITION of 'open' and 'locked' pixels when the stencil is made. DPaint's stencil tool did this, but as of a couple versions ago, at least, Pro Motion stencils only acknowledged the CURRENT COLOR of any given pixel. So if you made a stencil that leaves, say, colors 145 through 152 open, those PIXELS remained open (unlocked) only until you painted over them with color from some other palette position. Thus, the areas stenciled open or closed were 'forgotten' and changed even as you painted over the stencil, let alone tried to open and use a saved stencil later. This creates really significant difficulties when producing cycling art of any complexity.

To address the palette issues as well as DPaint did, every file opened in Pro Motion would have to acknowledge and apply only gradient or cycling information contained in the saved file, and completely ignore any such information from other art files previously or simultaneously open in the tool since last launch.

To address the stencil issues as well as DPaint did, both stencils in use, AND saved stencils, would have to at least allow users the choice of remembering the pixel POSITION info of locked and unlocked colors at the time of stencil creation, not just locking or unlocking pixels in transient dependence on their current color from instant to instant.

All that said, I have come up with work-arounds for both of these issues, though they are rather cumbersome, and nearly every effect in the images shown on Joe's site CAN be reproduced in Pro Motion.

Wow - that answer was a little long, wasn't it? ... I will try to stop doing that.

Happily, In both DPaint and Pro Motion, I was/am able to watch the colors cycle as I work on the image, so I can literally edit my 'animations' in motion. That is VERY helpful, my Cosmigo friends, so please DON'T change that! (Thank you.) When it comes to creating all the separate palettes that make an image fade from one light-scheme or weather condition to another, I am able to see what the image looks like in the palette state I am working on, of course, but not the transition between one palette and the next until I see it implemented in code later.

(See? That one was MUCH shorter.)

Yes, in fact. Different effects work better or worse with different dithering methods. Most often I use patterned dither because I want the effect to look smooth and precise. This requires all the pixels in the syncopated array of shifting color offsets to be very evenly, regularly and precisely spaced and arranged. Using diffusion or random dither in these instances would produce effects too fractured and chaotic in texture. Sometimes, however, that's exactly what you want, so, for example, in the 'Sea Cave' beach scene, at the point where the wave collapses into gouts of foam, I wanted a chunkier, more particulate, chaotic' texture, so I used 'diffusion' dither in that spot. Diffusion dither on the smooth, rising wave face just before that point, however, would have looked terrible. For effects like snow - and often rain - one wants the snowflake or rain drop path filled with solid, straight-edged bands of color unbroken by any pixilation at all. So I use the 'no dither' setting to apply those gradients.

Well, that depends on how you mean the question. Joe's recent 'experiment' demonstrates that you can now run and display these images in such a color space. But if you're asking about creating such art in a 32-bit space, I'd say the answer is probably not with currently available tools. You need to arrange, change, and keep track of, all kinds of specific gradients, and even specific pixels that share a single color - not just their positions on screen, but their positions and behavior in the palette. Can't do that in any 32-bit space I've encountered. Most of the time there's no really accessible 'palette' at all, and when there is, it's 'color families' you're controlling, not a single, isolateable color. All this is not to say that someone like Joe could not create a tool that at least simulated such micro-palette control within a 32-bit color environment - if there were a reason to try ... or if they were merely as gratuitously bonkers as I am. (?)

For the most part, no, you can't, (and how many times have I wished you could!), for the following reason:

If the art you're converting contains only very simple effects using nothing but cycling gradients that are ALL of exactly the same length, and ALL shifting palette positions at exactly the same speed, then yes, you could make one frame for each palette-shift iteration. But cycling art that uses only such uniform and synchronized cycling gradients and cycling speeds usually looks very rigid, and produces animations with the very noticeable and unattractive 'pulsing flash' that 'color cycling' is so sadly famous for, as brighter and dimmer color arrangements are repeated in regular lock-step on screen. Unless the effects incorporated in your image are VERY few, or VERY simple, some textures will NEED to use gradients that are very long and/or slow to look right, while others will require very short and/or fast gradients and speeds to function correctly. All these gradients of varying length and speed moving together produce a much smoother, less noticeably syncopated, and much more genuinely organic looking result, but also a virtually endless sequence of combinations before all iterations have been repeated. This means that your GIF might have to be thousands or even tens of thousands of frames, OR that your cycling image would go through some incomplete portion of its possible combinations before 'jerking' noticeably back to its initial combination when your GIF sequence ends prematurely. ... Did that make any sense?

As mentioned earlier, copyright on all of these images currently belongs to the entities who published the products they were all once included in - or to their 'heirs' if those publishers no longer exist. Thus, we cannot legally make any of these images available to others for such purposes AT THIS TIME. However, as also mentioned earlier, we are increasingly enthusiastic about locating and communicating with said copyright and license holders about what might be agreeable to everyone in changing that sad state of affairs. Do stay tuned.

In one way or another, the creation of almost ALL the various effects in these images involved using stencils to lay many iterations of a single cycling texture down over itself in multiple color and/or value variations. The raindrop or snowflake that seems to be a dot or dash moving across the background surrounded by transparency is actually just a dot or dash of noticeably contrasting color on a long 'path' filled with equally opaque proceeding and following colors carefully adjusted to 'match' the background colors they are crossing, and thus seem invisible. If you look closely, you should be able to see at least portions of some of these 'apparently transparent' trails in the rain and snow scenes. The actual process to produce these trails is simple but tedious to do, and describing it in detail here would bore you all to smithereens! So I won't

As for why you can't find the raindrop trails or their palette gradients in the 'sunny' day version of the picture, that's because they aren't there! Occam's razor.

The waterfall image is one of those scenes designed to do a large array of different things over time, and palette space had to be used with even more strenuous economy than usual. Therefore, though I could have baked the rain lines into any or every version of the scene, and adjusted their palette space to disguise them during 'clear daylight' phases, just as all but the visible 'drop or flake' portion of the paths is disguised during the rain effect itself, it was just easier to clear both the paths and their unique palette space out whenever the scene wasn't displaying 'rainy' conditions. The screen of raindrops, and the screens of snowflakes, are some of those few 'overlays' we baked into the image only when needed, using their rows of palette space for rainbows or stars at other times since none of those things would ever appear simultaneously with rain or snow. It would always be one or the other, so why bother building them all in together?

This question should have been largely answered above, but I will add that most of these palletes contain at least a few rows of empty space, either because that space is reserved for effects not used at that time of day or weather condition, or because I simply didn't need all the available palette space to do everything that needed doing in that image. I never just 'expanded' into extra available palette space if it wasn't clearly needed, because there was always the possibility that we would want to add some other feature to the image later, and need the excess space to do it. These pictures were all about maximum economy - unlike a lot of graphics in this age of gigs and gigs of space for everything...

Well, Your Highness, ;-), your English is MUCH better than my Swiss would have a prayer of being. I salute you! If I interpret your question correctly, you are asking if I could do moving foliage as well as moving water?

If so, the answer is yes, I have done both moving grass and foliage using a similar technique to the one I use for moving reflections on the water. I'd start by edging the leaves in a one pixel wide line of two 'clown colors' - one clown color on the left sides of the affected leaves, and the second color on the right sides. Then I would use stencils to fill those edge lines with a moving gradient composed half of colors 'matching' the leaf color(s), and half of colors matching whatever background color(s)surrounded the leaves. As these bands of color moved along the edges of those leaves, they would cause the 'core leaf shapes' to seem to expand INTO the bands of moving color that matched the leaf, and shrink AWAY from the bands of color that matched the leaf shape's surroundings. If I laid these gradients down carefully so that the bands of color all moved together in the proper way, all the outlined leaves would seem to 'sway' a pixel in one direction, then a pixel in the other - back and forth. If I syncopated the gradient fills in some parts of the foliage differently than in others, not everything would sway in the same directions at the same time, thus preventing my tree top from looking like a metronome.

I hope that explanation is at all comprehensible. As I mentioned, you can probably see this technique operating if you look carefully at the wavering reflections in the 'Mountain Mirror Pond.'

Twelve of these images are from a desktop calendar/day-planner product called Seize The Day that came and went - along with the company of same name that produced it - very rapidly about 17 years ago. These twelve images appeared again - slightly expanded in width - along with all the other images currently displayed on Joe's site in a PC game from Acclaim Software in the late 90s that also came and went in something of a hurry - vanishing, along with Acclaim themselves, not long after. It was called 'Magic the Gathering - BattleMage.' Other cycling images I have around were mostly done as concept work for projects that were never actually produced. ... Back in the 90's, if you were a company needing concept art for a project you were never actually going to finish - I was your guy. ;]

Well, this has certainly been fun. Thank you all for your good questions, your interest in these suddenly unearthed artifacts, and the honor of your enthusiasm and appreciation. Means more to me than you can know. Should such interest persist, perhaps Joe and I will find ways to further gratify curiosity about this kind of artwork and/or its possible future HTML5 applications. If there's a use for this kind of art, perhaps I'll even think about how to teach these techniques more specifically to digital artists wanting to learn them, so that next time around, there will be reason to preserve and develop the tools for it, and a place for it in the expanding universe of approaches to online graphics.

Thanks especially, again, to Joe Huckaby for liking my pretty moving pictures 'that much' all these years later, and for inviting me to do this interview.

Sincerely,

Mark J. Ferrari