Palette shifting

Someone I follow on twitter shared this a while ago: 8-Bit color cycling in HTML5 canvas.

And while it’s basically a sort of HTML5 tech-demo, it shows a very old but interesting technique used in games and interactive media back in the day: Animating complex landscapes by cycling colors in the palette. This is how complex background scenes were given life in old games, where particle-based rain or big-sized moving cloud sprites were beyond the capabilities of the hardware.

It turns out that changing a color in the palette was a very quick and inexpensive operation, so they devised this method to generate rich environments using little to no processor time and a negligible amount of extra memory.

The only downside of this technique is that it requires a lot of extra and duplicate entries in the palette (depending on the animation). If you check the examples in the page above, a rich animated background can easily use more than 75% of the palette space, leaving little room for the rest of the game elements. And because every element or object in the screen that is supposed to stay constant in color (like the player, enemies, text, etc) requires entries in the palette apart from the ones that are being cycled (even if the colors are the same) this leads to a sort of race condition in design-time between background and foreground elements.

The technique -however- is unbelieavably clever and shows how creativity can solve big technical problems. Modern devices have no problem animating rain drops one by one, or simulating volumetric clouds or bodies of water, or even storing full-screen frames of a complex sequence that will play in the background, but back in the day that was definitely impossible due to memory and processor constrains.

This technique was also used in small elements to avoid creating full frames of animation where only a few details changed between frames.

And this helps to answer the question of why did old games run better on their contemporary hardware than current games run nowadays in ours. Or why do modern games lag even on the best hardware configurations? Is it because old games were “too simple” even for the hardware back then? Is it because they weren’t pushing their hardware to the limit? The fact this technique was invented gives us a hint of the answer:

I think it’s just that -for the most of it- we just stopped being clever.


Pixel Art: Shantae

Ok, so continuing with my experiments on pixel art I’ve done a small animated sprite of Shantae, the main character of the Shantae franchise by WayForward.

Shantae started as GBC game and later got a sequel for DSi/eShop. There’s a third installment coming out on the 3DS later this year and also an AMAZING kickstarter campaign for a HD Shantae game that will be released on PC and all home consoles. I truly encourage you to check it out and support the game. There’s a lot of goodies for KS and Paypal backers! There’s only 12 hours left before the campaign ends but they’ll keep receiving contributions/preorders through Paypal for a few more months.


Anyway, here’s the sprite:

Shantae running

Shantae running

Although it was a bit rushed I’m happy with the result.

I did this sprite while watching Wayforward’s TwitchTV stream (live campaign countdown while they play games! They are still streaming so join them if you have the chance!)



Pixel Art: The bouncy treasure box

So it’s been a while since the last time I did pixel art for a game or project (or just for the fun of it).

When I was younger I worked alone in almost every game project or demo/prototype I developed, so I was not only the coder but the artist as well.  And while it was not Paul Robertson-or-Johan Vinet level, my art was definitely not cringe material.

Then I started working with other people (real artists, which is great) so for the past 5 years or so I’ve had no need to make art for a game beyond REEEALLY rough concept art or placeholders.

Since now I’m working again in my own games and ideas I’ll be probably dusting off my art skills. I’m trying to get real artist to work on my most ambitious projects but there will always be a few game ideas I’ll most likely develop completely by myself.

So yesterday night I was thinking about a game I’m working on… and as a sort of exercise I decided to draw and animate something for it.

In this game whenever the player gathers a certain amount of diamonds, a treasure box appears from the ground as a reward. So this is how I pictured the box appearing:

Treasure text appearing from the ground

A treasure chest is born

Although it’s not perfect I’m really happy with the result. I wanted a bouncy blob jumping out of the ground and shaping itself into a treasure chest. As I was animating the sequence I decided to make the blob split in two and then merge back into the complete thing. The idea later evolved into making one of the parts become the lock and fall in place just as the rest of the chest “solidifies”.

This animation will probably not appear in THIS game (as I’m trying to get real artists to do the graphics for it) but I’ll definitely use it in a future. Treasure boxes are a common thing in the kind of games I like to make.