When I was working on PlayStation 2 games, it was frustrating that all of the artists I worked with were creating textures that would ultimately end up palletized, but none of them had any concept of the techniques presented here even then. These days GPUs are getting powerful enough that I occasionally see kids reinventing these techniques using tricky shaders from first principles without knowing that they used to be the only way to get things done.
In the HN circles you have a chance to be familiar with Ferrari's work through 
But, in gaming circles, you might be more familiar with his work in Loom, Secret of Monkey Isle and Indiana Jones and the Fate of Atlantis.
Palatte shifting and limited color palates were born from the necessity of effeciency. Now he has to use an emulated DOS program to edit them. He uses an experimental web app to display palate shifting projects he created years ago and looks forward to the upcomming release of a pixel editor from the same author.
Additionally, he expresses extensive configuration necessary, mostly disabling anti-aliasing within multiple tools, which makes his process possible in Photoshop. He also has removed the limitation of color palate to make the final product more pleasing, regardless of weight and efficiency, as the concern is minimal on modern hardware.
His technique in Photoshop makes heavy use of the pencil tool one pixel at a time and even falls back to antiquated software (or manual technique) when he needs to implement dithered
I did not get the inpression that he was happy to be using Photoshop, but that it is currently the best option he has.
It's true he also said sometimes he still has to manually put in pixels, but that seemed to exception to me.
The dithering template only exists because dithering is not a concept in PS; the DOS application has a dedicated dithered gradient tool.
Called paradise lost, and the trick the graphic team are using to fit 8bit pixelated graphics to the modern taste are incredible, like having to tweak animations so no parts ever move half a pixel, which influences walking speed and dozen pther things. Their blog is quite informative.
I attempted to find an official page for the game but couldn't find any. Instead, I found a bunch of documents about the Gameloft business.
I'm a few days late and nobody will see this, but I had to say - I'm also of the opinion that this is a truly amazing game.
Looks like it's available here: http://dedomil.net/games/2743/category/2 (or just Google for JAD/JARs of it).
You can run it anywhere (including I think on Android) using MicroEmulator.
If you like sidescrollers and pixel art, this game is a little cramped, but it made a real impression on me around 17-18 (I think it was).
It then uses the metaphor of "Renaissance" vs. "Renaissance Faire" to talk about an 8-bit style, which doesn't have to reproduce the exact details of 8-bit colors, but rather the aesthetic - "8-bitish art". Followed by details of how to do it.
(this part is about 12 minutes in)
- One, like this, refers to 256 color (or less) graphics
- The other, refers to graphics made using the constraints of real world common 8-bit computers (in the US, the Apple ][ or C64, in Europe, the ZX Spectrum and Amstrad CPC, etc) or 8-bit consoles, such as the NES and Sega Master System.
There are a lot of games which try to emulate these styles, and there are very few true accurate 8-bit (or 16-bit in the case of SNES, Genesis/Mega Drive, Amiga, ST) games. I always appreciated the constraints of having small amounts of memory and so few colors to play with when I was messing around with my Amstrad CPC as a kid.
Just the other day I cooked up a legit Mode 0 "Monster Land" mockup after rediscovering the appalling Spectrum-port original.
Working with true 8-bit pallettes is fun; working with 2x1 pixels is "fun"
Environment was small enough that you actually could think about it.
8bit art is mentally and creatively manageable space to work in.
As an aside, I think Disasterpeace is doing for chiptune-style music today what Mark Ferrari has done for 8-bit graphics: https://www.youtube.com/watch?v=XB-pG7wEnzM
It's always interesting to me where this appears - you see a ton of it from Carmack in "Masters of Doom" and it's happening again with current hardware in VR.
There's probably something to be said for purposefully setting up constraints that otherwise wouldn't need to exist in order come up with something interesting - and learn more faster.
I can't believe how little crowd reaction there is to some of the things he's showing, eg. the cityscape reveal in the Storm game screens.
It really is a phenomenal program. I had to do some pixel-art drawing c.a. 2000 and found nothing remotely as good; fortunately I still had a machine that would boot to dos and my copy of DPII.
shameless plug: here's the paint program I've been working on:
(the most up-to-date code is the 'rgba' branch in github: https://github.com/bcampbell/evilpixie/tree/rgba )
I've had it running on OSX, but haven't tried it recently. I'd expect there to be a few hiccups, but nothing fundamental.
I've just downloaded it and looks interesting. Haven't ever used Deluxe Paint, though, so can't compare.
I can't believe how little crowd reaction there is
The split screen, pixel perfect zoom.
I've been looking for paint apps for Android for years, and one of my pet hates is that finding one that didn't do bilinear filtering was incredibly hard (I finally found one I like reasonably well called "Artflow").
But even without filtering, having a quick and easy (one keypress) zoom that keeps the un-zoomed image visible on one side, and shows the zoomed region on the other, was vital to me, because it was one of the most frequent operations. Pretty much every paint app I see either complicates this with multiple separate views in separate windows, or by showing only a zoomed in view.
I find one of the biggest problem with modern paint applications is that they crowd the screen and don't surface the most important paint tools very well - they try to be too many things.
When I used Deluxe Paint, I wanted as little clutter as possible. I'd paint with everything off except when I wanted to change a tool, or change colour - and this to was one keypress away.
Though (relatively) low-res pixel art also tends to lend itself to using far fewer tools. I tended to mostly use the "spray can", smooth, and zoom in and draw individual pixels.
His recent work:
His animation, called "Kings of Power 4 Billion%":
If you have a chance, watch without YouTube's compression artifacts.
Other original mirrors (most 404): http://probertson.livejournal.com/23973.html
(Ausgamers and culture.crypt.cx appear to be still up)
$ youtube-dl http://www.gdcvault.com/play/1023586/8-Bit-8 Bitish-Graphics
[GDCVault] 8-Bit-8-Bitish-Graphics: Downloading webpage
[GDCVault] 8-Bit-8-Bitish-Graphics: Downloading XML
[download] Destination: 8 Bit & '8 Bitish' Graphics-Outside the Box-1023586.mp4
[download] 61.0% of 714.86MiB at 12.99MiB/s ETA 00:21
> Back then video cards could only render 256 colors at a time, so a palette of selected colors was used. But the programmer could change this palette at will, and all the onscreen colors would instantly change to match. It was fast, and took virtually no memory. Thus began the era of color cycling.
At the time, the video cards worked by having a 4 or 8 bit image resident in video RAM and also a 16 or 256 entry pallete of colors as well (18 bit was common in VGA, you didn't even get 24bit palletes!). The card would do the pallete transform every frame pixel by pixel as it scanned out the image to the CRT. The point being: at no point in time did a 18 bit, full color image exist anywhere in RAM.
That meant even on a machine that was too slow to even just upload a whole frame of 320x200 8 bit pixels 30 times/second, you could still easily upload a pallete of 256 colors every frame. Just doing that would change how the whole image displayed without actually doing the work of touching any of the pixels.