It's a nit, but this demo is "true" color cycling only in the sense of "faked" color cycling. The original hack used a series of color cells in the pallet to represent the object that was "moving", then updated the pallet (and only the palette) per-frame to effect the animation.
An HTML canvas has no palette. And in fact, for didactic emphasis, I just tried this on my phone -- where it works -- that has no color palette hardware at all. This code can only do what it does by doing what the original did not: modifying all the changed pixels every frame. It's emulating the original hack, not duplicating it.
Given that dosbox is an "emulator" (says so right there in the man page!), yes. You expected a different answer? Dosbox doesn't support "true" palette animation either (well, unless you give it access to the real VGA registers of real hardware, which can be done in some emulators).
The point was that the programming technique required to make this work is not the same as the one used on palette hardware, so calling it the "true" effect is going to be confusing to people who don't know exactly how this works.
How does that even matter? The technique being used is real color cycling. Whether the palette is abstracted in hardware or software hardly makes a difference...
The point was narrower: If you don't already know how this works, calling it "true" pallet animation is terribly confusing (imagine someone looking through specs for where the pallet API for the canvas is). If the title was "8bit-style Color Cycling in HTML" I never would have posted.
And to nit-pick even further: These images resemble the graphics of the Amiga and Atari home systems, which were 16-bit systems. To do this on a PC you would need XGA graphics (VGA couldn't do 640x480x256) which arrived at the PC around the time of the 386 processor, which was 32-bit. I think you could probably attach a XGA card to a 286 PC, but that was still 16-bit. I don't think anyone ever paired a XGA card with an 8088 PC, which actually was an 8-bit system.
So, this isn't even 8-bit art, it's more likely 32-bit art. :-)
Look at your CPU usage while viewing this page. The idea behind the original palette rotation tricks was to use less CPU. The actual palette values were deep inside the graphics adapter and was faster to change than the actual pixels on the screen.
Maybe we should do palette rotation tricks with (WebGL) shaders running on the GPU h/w to get a similar effect without the CPU hit.
Even that wouldn't pass the "true" test. You could implement the "pallet" using a texture lookup on the GPU of course, but could only apply it by rewriting all the pixels.
I think pixel art looks awesome even in 2012. What do modern developers/artists think about its future, given that high-DPI displays may become the norm? Will there be 264 DPI pixel art?
Pixel artists will probably use nearest-neighbor scaling to display their art on high-resolution screens (so one pixel would become a sharp 3x3 block of pixels, or 4x4, 5x5, etc). That is already the technique being used to create games with an “old-school” aesthetic on modern gaming consoles.
I don’t think that drawing 1920x1080 (or larger!) images pixel-by-pixel will ever be practical, and it probably wouldn’t even look like pixel art to the eye at that point.
Using a vector representation may be a more practical approach as retina-style screens become more pervasive. Microsoft Research has an interesting paper on this from last year's SIGGRAPH: http://research.microsoft.com/en-us/um/people/kopf/pixelart/
That said, once you switch over to more advanced scaling, the artist loses a lot of the fine control over the result that can really make pixel art shine.
The technique in that paper kills the effect completely. Its a way to de-pixel the pixel art. Also, vector representations quickly become much more CPU intensive. Would be more efficient to scale the pixels as suggested above.
I think it would be an interesting and awesome project to make a 3D renderer that generates 256-colour(per scene? per frame) graphics in this style. Perhaps it could be done with shaders? Imagine playing through Skyrim and it looking as pretty as this?
This hack does not date from the 90s, but from the 80s.I have seen this hack first in a Computer Chronicles episodes presenting the Amiga 1000 in 1984 or something. It's way older than 90s.
I don't know that I really have much to add about the color cycling; seems like everyone's covered the topic pretty well! Delightful to see so many people interested in these old techniques.
The thing that unfortunately gets a little lost in the demo is the way in which the color cycling (along with clever color palette fading and some sprite animation) was used as a means to create a world that looked like it was really alive for the whole month long… When you started the app up in the morning, you saw the sunrise. If you tuned in at night, you could see the fireflies. Each day the moon progressed in its cycle. Some days it was sunny, others it rained. Clouds slowly marched across the sky. The whole effect was quite enchanting. Regardless of if we use color cycling or not, I'd love to do something like that again.
If you think this is a clever hack, you also might be interested about the way programmers of 8-bit '80s machines used to increase the number of colours they could display at a time. My first computer, the ZX spectrum, had video memory that was laid out in such a way that you could only assign two colours to any 8x8 pixel block. However by changing the colours of that square in sync with the TV raster signal, you could get it to display 8 miraculous stripy colours in the same block. You could use a similar technique to get stripes in the theoretically one-colour border. I think some people even managed to do these things and still have time for some semblance of a game, which is fairly impressive on a 3.5MHz machine.
The article[1] linked from the demo mentions an optimization that the image is preprocessed so that the javascript code only updates the pixels that are cycling. I wonder how another method would compare - modify the palette table in the PNG or GIF in Javascript, then redecode the image for each animation frame using the browser's decoder (native code).
The guys at Effect Games were actually making a pretty kickass javascript game engine in basic non-HTML5 HTML, using all kinds of Flash hacks to get sound and other advanced stuff working... until libraries like impact.js came out and browsers made a jump forward to support canvas and HTML5 better.
Hi there, I won't speak for Joe nor Mark (the color cycling demo was their baby, but I'll pass along the sentiments), but thanks for the kind comments about Effect Games.
As far as Gold Cart is concerned, we're working mainly on some short "experiments". By way of a preview, http://itsmin.com/portfolio/goldcart/gbasp/ Again, thanks for remembering us.
As for where jhuckaby is and what he's up to, I don't know. But I respect his work and his code.
EffectGames is something I'm really familar with. I worked on the open sourced version, fixing bugs and adding features over the last 8 months as part of a school project. I've added libraries, fixed up the online text editor, and learned a lot. Now that the project is over I'm debating whether I should keep up the work and get a webgl rendering pipeline working or if my time is better spent on other things.
Definitely not just you. I loved DPaint, then later DPaint III. I would make cyclic animations using the symmetry tool and flood filling each section with the next cycling color.
DPaint III is where my animation skills took off. All animations where of a ball that launched off ski slopes onto trampolines, through conveyer belts, and other Rube Goldberg type contraptions.
I still have my A1000 in a closet. I should dust that thing off and see if it still works...
Not to be a smart ass, but what makes you think I haven't tried, and found that I lack a certain artistic eye for shapes, shadows, and colors that prevents me from even having the slightest chance at reproducing things from my imagination, or even physical source material, in any recognizable way?
Although I pretty much gave up on trying to improve years ago. I switched focus to creating things with code, and have been faaaar more successful. So your comment is fair, in that I certainly could put time in to learn to draw and animate well, but I have a lot of other focuses for my life right now that can't spare that kind of time.
> Not to be a smart ass, but what makes you think I haven't tried, and found that I lack a certain artistic eye for shapes, shadows, and colors
Well, mostly the fact that most people lack "a certain artistic eye" until they develop it, including people who later become competent artists.
>So your comment is fair, in that I certainly could put time in to learn to draw and animate well, but I have a lot of other focuses for my life right now that can't spare that kind of time.
A valid choice. So when you said you'd "give anything" what you really meant was not that you would actually give anything, but rather that you just wish that you could draw well.
If you haven't read Betty Edwards Drawing on the Right Side of the Brain, do so. I think it can teach that artist eye. She also has a book on colour - I haven't read it yet.
A few hundred hours? More like just shy of ten thousand. Would take roughly five to ten years of solid application of several hours a day to approach that level. Never underestimate just how many hours of hard repetition and practice it takes to be a decent artist.
To reach true mastery, yeah you need 10,000 hours, but the drawing we're looking at on this page, while nice and competent (and certainly better than I can do), does not look to me like the product of artistic mastery.
I'd suggest taking a look at Ferrari's other artwork, he's actually not an unknown and he's certainly on a level that's beyond five years in.
Actually, I boggle at anyone who thinks they're at 'mastery' at just ten thousand hours in. That's the point that you're competent, really. Masters are people who are in it for the long haul, the folks over on ConceptArt clocking in twenty+ years are masters.
Ferrari's other work or what you want to call "mastery" is all irrelevant. manuscreationis said s/he would like to be able to draw as well as what can be seen in this demo. Acquiring that level of skill does not require 10,000+ hours.
Given that you admittedly don't have that level of experience, who are you exactly to decide that again? You haven't even justified that position, you simply state it as fact. If anything, I've found your comments to mostly be "irrelevant".
Working in reduced resolution and color constraints is actually something rather challenging. Lesser artists are going to particularly suffer because they won't have experience to fall back on when they need to find workarounds, especially if their color theory is weak. You aren't going to hit Ferrari's level unless you've already got a solid foundation in place. That's easily five years to be competent at, then you can learn to work within those limitations.
I personally oversee a number of artists around five years in and I wish could get that quality of work out of them consistently.
Why I suggested you see his other work is because I don't think you're actually qualified to assess just how difficult the work is and you should see whose work you're dismissing as amatuer/entry level.
1. The concept of "mastery" is both relative and subjective, so if a skill is particularly common, then an aptitude which could be considered "masterful" in another field might simply be considered "experienced". In addition, for some skills there is not that much difference between competent work and masterful work; as a result, we'd be unlikely to consider someone a "master" of, say, bussing tables.
2. Most jobs are "unskilled", and those who have them are not practicing what they do with an eye toward improvement. They are completing the task to get their paycheck.
3. Jobs that do involve some skill typically also involve a fair amount of unskilled work (note that "unskilled work" in this sense can still require education and experience). They also tend to involve splitting one's time between multiple skills. Working full time as a lawyer for 5 years does not mean that you have spent 10,000 hours in a court room, much less arguing in front of a jury.
Now, with all that said, it's true that practice doesn't scale linearly such that you can simply say "you need x hours of practice". The human brain stops responding well to practice in the short-term and needs time to incubate, so practicing 40 hours a week for 5 years is probably not as effective as practicing 20 hours a week for 10 years.
Still, if you actually did practice the same small set of significantly overlapping skills full time for 5 years, you would be extremely good at those skills.
You might, if every one of those hours was spent perfecting your craft. For most of us, a lot of what we do at work is diluted by secondary tasks - meetings are the most common scapegoat.
From the interview [1] - twelve of the images were originally used in a calendar application called "Seize the Day" [2][3] and later modified and used again in "Magic the Gathering: BattleMage". Other images were concepts for games that never made it to production.
I've seen this image a bunch as well, and was almost sure it was from a game/demo I remembered on the Commodore64. I saw the comments in this thread saying it was from "Sieze the Day", so I spent a few minutes trying to find the Commodore64 demo I remembered from my childhood (because I thought it had the most amazing graphics at the time).
Anyways, after 5 minutes of searching, I found this:
It's pretty to look at, using Ubuntu 64 bit and nVidia 6800 here. It used about 60% to 80% CPU time. It reminds me of palette animations in games like King's Quest series from the 1980's.
I used a program caled Deluxe Paint to do it back in the late 80s/early 90s. Back then pretty much all pictures used a pallete anyway; it was a matter of creating a static image and just making sure you use a specific range for the parts you want animated. A lot of times it's just highlights you want to sparkle, lights you want to blink, or water you want to shimmer, and you'll create a range (with e.g. a gradient) for those specifically anyway). More complex effects are possible, but can be a bit time-consuming.
[edit] To clarify I did not do the drawings on this page. Also if you want to see a good example of slightly fancier effects than just shimmering, look at the "swamp cathedral - Day" sample there and hit options. See how there is one range that is just for the rippling water, but then a different more complicated range for making the reflection shimmer appropriately; in that one they had to cycle very specific regions from purple to green for the boundary between the reflection of the hill and the reflection of the building.
Yes, that's kind of the point of Blend mode. AFAIK from looking at it, Blend mode makes the colors smoothly animate from one color to the next, which basically bumps the frame rate. Standard makes it change instantly, and since the frame rate is actually pretty low, it appears jerky.
An HTML canvas has no palette. And in fact, for didactic emphasis, I just tried this on my phone -- where it works -- that has no color palette hardware at all. This code can only do what it does by doing what the original did not: modifying all the changed pixels every frame. It's emulating the original hack, not duplicating it.