It's always been my secret dream to develop an adventure game with old-school art like this (my day job is an iOS developer). I am willing to put up all the development resources and a good portion of the game design, but the trick is finding a bored artist.
I suspect there's a market for a lovingly created adventure game, although not a really big one.
Normally I just upvote comments I agree with, but your post merits something more personal. Please do this, and please tell HN when you do so. I'll buy a copy.
Awesome atmospheric game screens by Mark Ferrari, brilliantly translated into HTML format with the color cycling animations looking "better than ever" thanks to a nice blending effect.
Does anyone know which game these screens originally come from? It's not mentioned on the site.
The resolution is 640*480 at 256 colors, which is better than VGA. That would suggest something fairly recent (perhaps 1994-96).
Most of the scenes are from an old, animated desktop calendar app from 1993 called "Seize The Day" (can't find a link anymore). I believe the rest are from one of the Magic The Gathering games for PC.
I have a question about this blending effect. In the article, the author writes "If only I'd invented this trick 20 years ago when it really mattered!" But wouldn't this blending have cost a big performance hit, since, to do this with 256 color palettes, you would need to switch to different color palettes very fast, to render all the in-between colors?
I think the idea is to interpolate the palettes "in-between" a shift of x and a shift of x+1. If you are going at 60 frames a second, but you only shift palettes every 6 frames say, then you see a jerky ever tenth of a second. If instead you shift the palette by 1/6 every frame (so after a shift of 1/6, you are using 5/6 of colour x and 1/6 of colour x+1), you get a much smoother effect. The computation is trivial, since you are only changing the palette, so you have at most 768 bytes to recalculate. You can also change palettes every frame by outputting those 768 bytes (in fact I think you can only output the changes), which is trivial to do fast.
What is interesting here is that the limited environment actually spawned a level of creativity that is unique to the era, once you have 24 bit colour and gobs of memory coupled with CPUs that would shame a supercomputer from not all that long ago you focus on different things rather than on getting the most out of such a limited environment.
To some extent mobile computing may revive this sort of sentiment. The 'demo scene' is another place where people still do absolutely amazing things with very restricted systems and/or environments.
Maybe there could be some kind of revival of this, webpages under 1K in size or something like that.
The art shines and becomes visible only through the limitations; that's why many artists choose to limit their technique, be it pointillist painting, writing 6510 assembly, drawing 32-color bitmaps, or programming a computer which has limitless limitations for the programmer to choose from.
You could replace painting realistic-looking objects with simply taking photographs, which seemingly does the same: reproduce an original setting in most realistic-looking way. But that isn't painting anymore, that takes away the art. In fact, photography is a whole another art: while it shares many basic principles with painting, the art of photography is very different from what makes painting an art.
Mobile computing isn't that far behind regular computing. We've already got 1ghz 3D accelerated phones with hd screens. Retro may be coming back, but the motivation isn't lowspec hardware, it's low budgets and nostalgia.
And if you mouseover the color swatches it highlights which pixels correspond to that color. Doing that really makes the intricacy of these images apparent.
I would also like to know which games these screens are from. The art is breathtaking and the fact that it is achieved with nothing but some cycling colours is nothing short of astonishing. Why don't we have games like these any more?
mainly because we have 32 bit colour and accelerated graphics drivers today. You can't palette cycle 32 bit colours because there's no palette to cycle.
An 8 bit display meant that you basically had a lookup table of size 256, and each entry mapped to an 18 bit colour (6 bits each for R, G & B IIRC). These days it's kinda normal for a bit geek to have numbers like 1024, 1048576, 16777216 and 4294967296 permanently burned into your brain. Back then we also had 262144 burned in -- the number of colours we had access to.
The best part about palette cycling was that you didn't have to wait for the VBLANK to make your changes. For most frame changes, you'd have to wait until the cathode ray hit the bottom of the monitor and was slowly making its way back up to the top to scan through again. You had to make all writes to video memory at this time to avoid screen fuzz, ie, half a screen with the old frame and half with the new frame. Palette cycling could happen at pretty much any time, so you'd just hook it up to the timer interrupt and let it go.
I believe for pixel art there's some kind of uncanny valley effect once you go true color. That's why even bad 3D pre-rendered graphics were better received once graphics went beyond the VGA limitations (plus the usual 3D hype).
And it's a very slow process, hard to automate. So as games got bigger, it was hard to have that many individual paintings. You're basically doing an animated movie when you've got 2D pixel graphics.
That's why mainstream games can't make too much money with that, and why on the other hand, pixel-based games have seen renewed popularity with the advent of downloadable indy games for major console platforms.
It's a general complexity issue with higher resolutions and larger palettes. You can restrict one or both, but if you try to apply a high resolution and extensive palette in a single image you'll go nuts trying to use a per-pixel method. Plus, as a general art principle it usually helps to restrict palette anyway, so that the image is focused around a consistent lighting style/mood. In a game based on sprite blitting alone, lighting has to be baked in everywhere, forcing the art style towards uniformity.
Much of the "pixel art" made even at ~320x200x256 is sourced from oil paintings, cels, 3d, or photography and cleaned up with pixel editing. Cleanups can work wonders for any source material at that resolution, but if you look at games from the later 90s which applied these methods to 640x480 and above, the art taken from other sources tends to look like a paper cut-out once composited, because the alpha is colorkeyed, not per-pixel, and no amount of cleanup could hide that. Now that we can use per-pixel alpha everywhere and apply shader effects, 2D is a lot more flexible than it used to be.
256 colors was actually pretty high-end, and basically the turning point for PCs. I fondly remember what some of the non-PC artists could do with limited color palettes… (What was the name of that odd 64-color mode again? Half-bright?)
Extra Half-bright. The Amiga's HAM mode was even stranger. 6 bits per pixel, but the first two bits were for control: 00 meant the other four bits would reference a standard 16-colour palette, but any other value would cause the pixel to take on the value of the previous pixel, modifying either the red, green, or blue component (depending on the two control bits). Total of 4096 expressible colours. Great for photographs, not much use for anything else.
Agreed about 256-color being a turning point. I remember being amazed by Nextstep's 256 color mode when they ported to PCs. It was an incredible concession for an OS that delayed supporting color until they could "do it right", which to them meant every pixel had 24 bits for RGB plus 8 for alpha. It was great for those of us with modest hardware.
The difference is that it's perfectly reasonable to prompt your users to install Chrome Frame. After all, it's just a browser plugin like Flash. It's a very valid solution, whereas installing a VM, for most people, is not.
I actually tried for hours and hours to get this working natively in IE with VML (which is what excanvas uses behind the scenes). Unfortunately, it is just WAY too slow (each pixel becomes an "object" in VML space -- yeech). So I had to cheat with Chrome Frame for now. I am looking at implementing this in Flash for IE 6/7/8 (should be totally possible with their high performance BitmapData and ByteArray objects in ActionScript 3).
It's also the best the author could do without wasting hours
(days?) of his life only to support a broken browser that is probably not even very widely used in his target audience.
Personally I'd have preferred a blunt "This page does not work in MSIE", but I understand that's still a risky thing to do, despite the market share figures having improved somewhat.
> It's like saying, "This software is Mac compatible!... inside a VMware instance running windows XP"
Hey, that sounds like FlashDevelop, which actually claims to be "Mac OSX/Linux compatible using virtualization software (VirtualBox, VMWare, Parallels)"
Apologies, my servers were overloaded with traffic yesterday. Was honestly caught off guard by the huge spike this demo caused. Now running with 3 EC2 Squid servers behind an Amazon Elastic Load Balancer. They're handling it much better :)
I suspect there's a market for a lovingly created adventure game, although not a really big one.