There are plenty of algorithms to scale up pixel art. (I prefer hqx, personally.) But are there any notable algorithms to scale it down? My game is designed to run at a resolution of 1280x720, but if it is played at a lower resolution I still want it to look good.

Most pixel art discussions center around 320x200 or 640x480 and upscaling for use in console emulators, but I wonder how modern 2D games like the Monkey Island Remake could look good on lower resolutions?

Of course ignoring the option of having multiple versions of assets (i.e. mipmapping).

  • \$\begingroup\$ Mipmapping doesn't require multiple versions of assets; it can be done at content load time automatically by OpenGL or DirectX. Would that satisfy your goals? \$\endgroup\$ Dec 13, 2012 at 1:56
  • \$\begingroup\$ @SethBattin I'm not sure. I'm thinking about running a game made for 1280x720 in e.g. 1024x576. What do OpenGL and DirectX use to rescale if I give it an image that's 128x96 and is supposed to be displayed in 102x76? (which is even a rounding issue since it should be 102.4x76.8 pixels) \$\endgroup\$ Dec 13, 2012 at 2:08
  • \$\begingroup\$ Mipmapping blurs the image a lot. You would not want that for pixelart. \$\endgroup\$
    – Kromster
    Dec 13, 2012 at 5:19
  • 5
    \$\begingroup\$ Just FYI: Monkey Island Remake didn't require downscaling. The game ran on EGA and had an effective size of 320x200 pixels. There's no need to create downscaled versions of this for mobile-devices, since it's already smaller than the resolution these devices have nowadays. \$\endgroup\$
    – bummzack
    Jan 24, 2013 at 7:18
  • 2
    \$\begingroup\$ How does your pixel art look? You are asking us to answer in blindness. \$\endgroup\$ Jan 26, 2013 at 9:44

3 Answers 3


I'm currently making a game that has to run on a wide variety of display sizes and aspect ratios, and it hasn't been a very easy process. In addition, if you're making things in pixel art, and you want to keep the pixel art feeling while supporting many resolutions, you're walking into a world of pain, so be prepared.

In my opinion, there are several things you can do (some are exclusive, but others are not)

  1. Define a minimum resolution, and only upscale (everything) in integer terms with nearest neighbor. That way you can keep the pixel art feeling. I don't think downscaling is a good idea, as you will lose detail, and the entire purpose of using carefully crafted pixel art will be defeated. If your minimum supported resolution is too small for your sprites, either change your minimum supported resolution, or redraw all assets to support this minimum resolution.

  2. When you encounter a resolution, or aspect ratio that is not enough to cover the entire screen, extend your game (show more tiles), while keeping the assets intact. You should make your game so it is still playable with the minimum resolution/aspect ratio though.

  3. If extending the game is not possible, fill the non-game sections of the screen with black; either stripes at the top and bottom, left and right, or a black frame. This is what the iPad does when running iPhone apps in magnified mode. This is also widely used in emulators.

  4. Give up on keeping true to the pixel grid. But you then have to stop using pixel arty assets with sharp corners. Then upscale/downscale using bilinear (or optimally bicubic, if your platform supports it) filtering. This is the best choice for maximizing screen usage, while keeping the user experience similar across all supported resolutions.

For my game, I ended up doing option number 4, and I'm quite surprised at how good it looks on devices ranging from 320 pixels on the vertical (an old Android 2.3) up to 1536 pixels on the vertical (a 2012 iPad with retina display). The original assets are meant for 600 pixels on the vertical (originally for 800x600 display on a Windows PC). Although for subsequent games, I think that a better logical vertical resolution is 720 pixels.

The game uses a virtual 600-pixel high virtual resolution, scaled to the device native resolution with bilinear filtering. This means that all in-code Y-coordinates go from 0 (top of the screen) to 600 (bottom of the screen).

For the horizontal size, I suppose the maximum width is 1080 pixels, which is more than enough to cover even the widest 16:9 aspect ratios. My x-coordinates are centered, so x=0 is the center of the screen, and x-coordinates go from -540 on the left to 540 on the right. I make sure everything fits between -400 and 400 to support the narrowest displays (4:3)

However, if I had to keep the pixel art feeling, I'd certainly use options 1 and 2. Meaning that I'd only scale in integer terms to keep the blocky feeling of pixel art, and design the game so the amount of visible tiles is not fixed and can adapt to any screen resolution/aspect ratio.

So, in order to (not) answer your question. I think that downscaling pixel art is a very bad idea, so you should not do it. There are other ways to support different screen resolutions that will provide better results than simply butchering your carefully created art.

  • \$\begingroup\$ I'm in the same situation and it's driving me crazy. Our game is pixelart made for 600px height screen. But if I upscale to 720p screens (PC), it gets a really awful, slightly blurred look. I don't really know what to do here. I also thought in making a bigger map for 720p screens and keeping the pixelart as it is, but then I have the same problem for 1080p screens. I think we should have done 360p pixelart (or smaller), so we would have perfect x2 and x3 scaling for 720 and 1080p screens. Now it's too late for that. Any further idea or advice? \$\endgroup\$
    – Damian
    Dec 5, 2013 at 16:00

Consider actually generating the scaled down versions at development time, and including them directly in the game as a resource. Do this with Photoshop or whatever tool you find creates what you like. Then have the game dynamically select the right art set appropriate to the current resolution.

Here are a couple of reasons you might do this...

Saves Processing Work

If you did rescale programmatically at runtime, your software will probably create and cache the artwork anyway. So why not just include the scaled down versions in the art asset bundle? I suppose if it made the download bigger than you'd like it might matter, but you'll save on some CPU load, disk writes, etc.

Greater Artistic Control

If you rescale the art yourself, you will have greater control over the final appearance. That might not make a difference if you are scaling down a small amount, but when you get to much lower resolutions, you may wish to have better artistic control over the final appearance. For example if a specific character's eyes needed to be emphasized, you might actually draw the lower resolution versions with the eyes not scaled down as much to retain the effect -- something that programmatic scaling can't do.

Dynamic Scaling Isn't Perfect

You may make distinctive artistic decisions that do not work with dynamic scaling. For example, suppose you want to put a border, outline or highlight around an image. When viewed at higher resolution, this may look fine, but the scaled down version may muddy or entirely lose the effect. But if hand done you can specifically apply the effect to each size yourself and guarantee you retain the impact.

Other Thoughts

You could also do a hybrid approach, with a set of resolution-specific resources that are used where found, and a generic set that is dynamically scaled if no resolution-specific version is found. This is a bit like how the Android platform works. Some info on this at http://developer.android.com/guide/practices/screens_support.html


Resizing down is easier than resizing up because you're choosing information to throw away rather than having to invent new (and possibly incorrect) information to fill in the gaps. With that in mind, you probably don't need anything special here and most standard resampling algorithms from the realm of image processing should work fairly well for scaling down an image: bilinear, Gaussian, Lanczos, etc.

Lanczos in particular might be an interesting choice as it sharpens the image, possibly preserving detail that would otherwise be lost when combining several pixels into one. Obviously this comes at the cost of potentially introducing unwanted artefacts.

Some visual comparisons here: https://gis.stackexchange.com/questions/10931/what-is-lanczos-resampling-useful-for-in-a-spatial-context

  • 3
    \$\begingroup\$ -1, because scaling down pixel-art (which is usually hand-crafted pixel-per-pixel, example) will never look good with any of these algorithms. With a nearest neighbor approach you'll lose important line-segments. With interpolating you'll get blurry images. I fear there's no satisfying answer to the OPs question except to do it manually. \$\endgroup\$
    – bummzack
    Jan 24, 2013 at 7:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .