No, pixel art is not at all about "big blocky pixels" - that's some silly 8-bit retro movement. Pixel art is about a crisp, distinctive look and intricate detail. For instance, this piece: http://www.pixeljoint.com/pixelart/29178.htm

Keep in mind that bad graphics are not retro! This is seen a lot in indie games - the creator isn't very artistic and so they use low-quality sprites to make up for it and call it retro (this is also happening with chiptunes/module scene).

Also, here's a wonderful guide/explanation on pixel art - a very very good read: http://forum.wesnoth.org/viewtopic.php?f=13&t=32273

> No, pixel art is not at all about "big blocky pixels" - that's some silly 8-bit retro movement.

At not point the article claims that pixel art should be all about big blocky pixels, only that understanding of pixel art is typically about (i.e what the layman knows about it), and even more typically in the context of video games. The only thing argued is that if any scaling is to be applied, it has to take place in the code, not in the image, which actually goes in your sense: the source image, although small, has to stay crisp.

So if you wish to really make a distinction, let's call it chip art then, or low-fi, or low-res, but there's no denying that this is pixel art, with the added constraint of resolution.

Calling this "retro", "8-bit", whatever movement "silly" is a bit disingenuous. From The Incident to The Last Rocket to Fez, the visuals are gorgeous. And not just the visuals, but from sound effects to music, the audio experience is fantastic. Disasterpeace [0] — the artist behind the Fez soundtrack — created rich electronic music, perfectly in line with my definition of quality (I enjoyed Rise of the Obsidian Interstellar way before Fez was known).

[0] http://itunes.apple.com/us/artist/disasterpeace/id411023239

I'm a big fan of pixel art. I've created a WebGL based low res pixel engine, a simple example of it is here: http://yaysarahandmatt.org (celebrating my wedding engagement)

I'm surprised he mentioned Photoshop. There are many dedicated pixel art programs that are far better for the task such as [Pixen][0], Graphics Gale[1], the new Pyxel Edit[2] and my own LoveToPixel[3] (done in HTML5 Canvas)

[0]https://github.com/Pixen/Pixen [1]http://www.humanbalance.net/gale/us/ [2]http://pyxeledit.com/ [3]https://github.com/city41/LoveToPixel

Old people who are still hung up on Deluxe Paint may appreciate grafx2: http://code.google.com/p/grafx2/

Deluxe Paint was the first painting software I used as a kid. In retrospect I've always regarded it as especially "hackerish", and though I TBH can't really tell the fidelity to the original in much detail, trying out grafx2 now only confirms this. I think the fact that the default background color is black and not white epitomizes it. So bad-ass! Thanks.

cough http://evilpixie.scumways.com cough

</selfpromotion kind="shameless">

I didn't know about this one, I'll check it out. Especially looking forward to an OSX package, as OSX is really lacking in pixel editors.

I hope it's not inappropriate, but that is now one of my favorite things ever. Fantastically done.

Thanks :) There's also a zombie mode easter egg which was fun to make: http://yaysarahandmatt.org?zombie

Why are they better than Photoshop for creating pixel art?

Photoshop is chock full of tools and features that a pixel artist wouldn't care about, and they can get in the way. On top of that pixel editors tend to have features only pixel artists would care about: mirrored output (pick one or two planes on the canvas and your work will be mirrored around them), ability to define simple, finite palettes and quickly move between the 5 or so colors you're using often. Also the ability to tweak colors in your palette and have the image adjust automatically (ie replace all of a certain color with another one), but not force you into an indexed color palette. Ability to zoom in very close but still maintain a 100% view, etc.

Most also offer nice animation tools such as looping your animation in real time allowing for effective tweaking. Even other simple niceties like they are always hard edged, always scale with a nearest neighbor algorithm, having both the right and left mouse button be full fledged tools, etc.

The canonical tool was Deluxe Paint on the Amiga, and most tools still around today emulate it at least to some degree.

I used to use Paint Shop Pro for (among other things) pixel art. Somewhere around version 6 JASC decided it was no longer a generic graphics package but should be a Photoshop-rivalling photograph editor. From then on, selections no longer had crisp edges along a pixel boundary but took the edge pixel at half alpha and the next pixel over even more transparent. I couldn't find an option to turn this off anywhere. Goodbye, ability to do pixel art in PSP.

I don't think Photoshop does this (I haven't used it for several versions and my art days are more or less over) but the above has made me forever slightly wary of attempting pixel art in a package primarily sold for photo editing.

Plus, Photoshop is expensive. If you have it anyway and it works for you, that's cool. If you're looking to install something just to make pixel art, you're spending a lot of money on a lot of features which are irrelevant to you and may make it harder to find the functions you actually need.

I still use PSP 9 for bitmapped/raster graphics (other than photos), and had used all of the versions from 3 on except 8. All you needed to do was to uncheck the "antialias" option box (and make sure that the feather value was at zero) to get a crisp (no alpha) selection. The setting were persistent, like a preference, so once you deselected the "antialias", it became the default until you selected it again.

Photoshops animation tools are woefully tedious to use too.

http://www.lovetopixel.com/ seems to be defunct, fyi.

yeah its temporarily down, but will be back soon. thanks for the heads up.

Really wish there would be something as good as GraphicsGale on a Mac.

Glad people are working on Pixen again, but it's got a long way to go.

> committing the grave sin of mixed pixel sizes.

Never thought about that before, but I completely agree!

Once the article pointed it out I couldn't un see it. Mixed pixel art will forever look off to me now!!

Mixed sizes of scaled-up pixels bug me, especially pixels not at power-of-2 scalings to each other, but I think the contrast between obviously scaled-up pixel graphics and native resolution antialiased graphics can sometimes be useful, e.g. smooth for text and UI elements, pixel for the actual game graphics.

I guess as with many things the rule is: try it and see what works. That or I'm just a pixel philistine.

Also, if you draw your pixel graphics pre-scaled, you're locking yourself into nearest-neighbor interpolation. There are plenty of other cool interpolation algorithms that you might want to use to use, like scale2x or hq2x.

Those are some of the worst things you can do to pixel art. Truly horrible.

It kills the "pixelness" of it, yes. Personally I do like them though. Those algorithms do create interesting looking graphics. Last year, me and my girlfriend decided to play some classic Mario again, and since we didn't have any old Nintendos nearby we used SNES9X which uses, I think, hqx. It's different but quite neat.

For making a dedicated pixel art game they're unusable though.

There was a cool SIGGRAPH 2011 paper from Johannes Kopf from Microsoft Research and Dani Lischinski from The Hebrew University that presents a new pixel scaling algorithm that really takes pixel scaling to a whole new level. Check it out here: http://research.microsoft.com/en-us/um/people/kopf/pixelart/

Actually the worst thing is just linear interpolation.

Why so many emulators default to that is mind boggling.

Another reason for doing this is motion. If the images themselves have double-pixels, then the game can still render moved/rotated images within the device's pixels and not the image's pixels. So scaling up your canvas makes development easier, in addition to the artwork creation.

I used this method with a little platform game I was creating, with the exception of text: http://minipenguin.com/?cat=32

Interesting that designing for iOS non-games is the opposite: design @2x and then scale down.

The scaling down can be tricky though. I'd love to see a similar post to this: a pro's take on retina graphics.

My workflow has always been to create everything as vector artwork starting at the 1x resolution and then scaling up and tweaking for the retina display. However I could see the process reversing if I were creating artwork on a retina display.

If you render everything to a small canvas which gets scaled up for display, movement will be less and less smooth the larger the display is...

Resampling without filtering like that is really fast.

Oh, sure, but I'm referring to something else. If you have a slow-moving object rendered on a 160x120 pixel screen, it may move 1 pixel, say, every 8 frames. Now scale this up to 1280x960, and your object will be 'jumping' 8 hardware-pixels every 8 frames, instead of smoothly moving 1 hardware-pixel every frame.

Of course, that can be an artistic choice, as long as you're aware of it.

I'm not sure I follow. It's all logical pixels. Let's say our example is a galaga-type game and the moving object is a missile fired down toward the player.

The goal is to have the missile move 1 logical pixel per frame regardless of hardware resolution.

At higher resolutions (without commensurate higher PPI) the logical pixel will become physically large and begin to look pretty weird/potentially undesirable at certain viewing distances. But the missile should always still move precisely 1 logical pixel per frame. It will pass the same amount of background art each frame. It will approach the player just as fast. etc

The example you give (1 pixel of movement per frame) is the only case in which there is no difference. Anything faster or slower will show smoother movement by using all the available hardware pixels.

In my example, the larger screen has e.g. 8 times the number of pixels horizontally to show movement in. Instead of waiting 8 frames and skipping ahead 8 hardware-pixels, you can render the sprite 1 hardware-pixel further along every frame.

I still don't follow why you're saying "waiting 8 frames". But I think I get what you're talking about -- essentially interpolation.

The problem would come from anything other than simple movement of a static sprite. If there's some much as a wispy smoke trail animation off the back end of the rocket as it flies through the air, the sprite data isn't going to give you any indication where those particles should be waving about during your interpolated frames.

You'd model the rocket exhaust as individual particles or suffer the blocky animation. But it's not rocket science :)

'Realm of the Mad God' works this way, with the added affront to purity of having rotated pixels. I think it works rather well: http://www.youtube.com/watch?v=hpMdFFxFbY4

It's so funny: I just saw an article on the Turf Geography Club and was wondering this very thing in their own design. Thanks for the post!

I'm always completely shocked when people design pixel art games and they can't grasp this concept.