Those games that are not fortunate enough to run on a locked platform spec, like handhelds, need to run across various resolution formats and aspect ratios.

In a 3D game you might have a HUD or menu GUI based on raster graphics, and in a 2D game you might have a bunch of quads which are vessels for sprites.

So my question is, how do you approach designing and operating content across various resolutions and aspect ratio? Let's assume you have a sprite character that is 300x400 pixels sprite and surrounded by a level made of tiles. On different resolutions/aspect ratios you'd see a different FOV altogether. Or if you have a HUD or a GUI menu, you'd want to keep some stuff at same positions and of same size relative to the screen. Yet, graphics source is raster bitmaps, not vector.

Obviously, problem has been addressed numerous times. I'm interested to hear abut various approaches that worked for you so far. Do you keep an arbitrary dimension agnostic 'pixel' unit that you magically transform into needed dimensions via formula based on res and aspect ratio or other approaches?


So, conclusion is to enumerate your aspect ratios. Lowest combination of aspect:resolution is the one you design important stuff into. A safe area if you will. Same aspect ratios, but higher resolutions are simple scaling issues. Art content is designed for highest resolution. Larger aspect ratios simply show more of level/FOV with information presented which is not critical as is the one in safe area. Something like in this image I made. alt text

  • 1
    \$\begingroup\$ I don't see how you went from the answers in this question to the conclusion you've made after your "edit:". IMO, these answers are inadequate and you shouldn't have accepted any of them. EG: Your accepted answer only talks about a piece of the question (sprite scaling), not the whole issue. What you've said after the "edit:" is more useful than the answers here, IMO. But, I don't really "get" it well enough to implement it. Unfortunately, if I ask for elaboration in a new question it'll be marked as a duplicate. \$\endgroup\$ Dec 17, 2013 at 19:16

3 Answers 3


If your resolutions are similar to each other, you can just use the same art across all of them with maybe some downscaling at runtime for the smaller screens. If they differ by more than say a factor of 2x, you're going to need to author (or at least have an artist tweak) separate assets for the different resolutions.

With 2D, resolution has a huge affect on how you design images. A sprite that looks richly detailed and realistic at high-res will be muddy and indecipherable scaled down. Likewise, a sprite that's clean and sharp looking at low-res will look cheap and overly-simple at high-res.

  • \$\begingroup\$ Aspect ratio worries me though. For example, it's not a huge leap from 1080p to 720p since aspect is the same, we're deling with simple scaling then. What happens when you have say 1080p vs 1680x1050. Do I show more of level, wider FOV on larger aspect, sort of a margin? Like, design for wider aspect with a safe area where all of the important content goes, so as not to be cropped off screen on narrower aspects. \$\endgroup\$
    – Keyframe
    Jul 14, 2010 at 21:18
  • \$\begingroup\$ I'll update question with visual presentation of this solution. Seems like there is no other way. \$\endgroup\$
    – Keyframe
    Jul 14, 2010 at 21:21

One way is to make the image assets in a vectorial format (SVG, Illustrator, etc) and convert them into raster images as needed by the different versions of the game.

  • \$\begingroup\$ Sure, but I forgot to mention that is not an option. Major problem being that raster and vector content creation is totally different (raster being far better for artists). One option would be to create multiple raster assets though, but I strongly believe there must be a better solution. For example, creating assets for largest supported res/aspect ratio and scaling down in lower res runtime versions on the fly or somethign like that. Positioning remains the problem still though. \$\endgroup\$
    – Keyframe
    Jul 14, 2010 at 19:39
  • \$\begingroup\$ Yes, that's also an option, if you can bear the quality loss and performance issues. \$\endgroup\$
    – Dr. Snoopy
    Jul 14, 2010 at 19:44
  • 8
    \$\begingroup\$ I'm not sure it's correct that "raster is better for artists". My graphic artist uses Illustrator for these very reasons. When it was time to update to the iPhone 4's 2X resolution, it was a simple matter for her to just export everything again. Raster may be better for Photoshop artists who don't want to retrain themselves as vector artists, but in the long run they're probably better off becoming experts in vector based graphics. Physical platforms are changing too rapidly to think in pixels. \$\endgroup\$ Jul 16, 2010 at 18:37

When maintaining fullscreen across different resolutions, if you want pixel-perfection (i.e. "As the artist produced it"), then the problem is that there is no fully automated way to scale sprites up OR down (or to rotate them) that doesn't require human approval. Ultimately that's because the placement of pixels is a subjective thing. The rendering algorithm performs some scaling, or rotation, and has to use some approximation techniques to do this, eg. bilinear filtering. If you still want hard edges on the pixels in order to have that "pixel perfection" (i.e. not using AA or BF), then you are going to have to accept that scaling by some non-power-of-2 degree is going to produce some undesirable artifacting.

An interesting approach to a similar problem is found in RotSprite, an application/algorithm designed to perform "automatic" rotations of sprites. By that, I mean it produces a number of possibly desirable end results after intensive processing, for the human operator to pick from. The hand-picked sprites then end up going into the game, meaning this is a content creation step, and not a runtime one.

One possible answer to your "arbitrary magical dimension agnostic pixel" question: OpenGL (which you may well be intending to use if you're going cross-platform) works in a totally different way from a software raster renderer. It considers the width and height of the display in floating-point range 0.0->1.0, and maps pixels accordingly on the GPU. Of course this can itself result in artifacting, unless eg. BF is turned on for textures (which is what your sprites are in OpenGL).

  • \$\begingroup\$ This is flat wrong. You can use composition and repeatable elements(think tiles) instead of scaling to keep it pixel perfect at any aspect ratio. Of course if the elements are small at higher resolution it will get increasingly small. so you would need 2X scaling or different resolution assets. \$\endgroup\$
    – adrix89
    Sep 16, 2017 at 14:08

You must log in to answer this question.

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