Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Prespective Projection has features that could be very well used even in 2D games. At least two very beneficial characteristics that come to my mind are:

  1. Using Perspective Projection to substitute Parallax Scrolling
  2. Using Perspective Projection to perform Depth Order of 2D sprites

On the other hand, perspective projection resizes objects (including 2D sprites in our case) with distance. This is why Mip Mapping has been developed. Mip mapping, however, does not always produce perfect results, as it relies on interpolation between two neighbouring mip-mapped frames. This might not be sufficient for a 2D game, where developers are sensitive for pixel based precision and detail.

My question therefore is, whether it makes sense to apply Perspective Projection for a 2D game. What will be the cost paid for that? Will the cost paid overweight benefits gained from 3rd dimension?

Has anybody applied Perspective Projection into 2D sprite based computer game? What were the results? Was the degradation of 2D graphics significant? Thank you very much.

share|improve this question
up vote 6 down vote accepted

It's not really a huge win in general.

You can use a perspective projection into a true 3D scene to get an effect like parallax scrolling background layers from classic 2D games, sure. But it's not really an easier to implement that than it is to implement scrolling layers.

You don't get any benefits with respect to depth ordering -- you'd still need to give each sprite an appropriate depth (Z coordinate) and this is no different in practice than assigning the sprite a depth layer. You get slightly smoother transitions between depth layers because they aren't discrete layers, but that's about it. You can use the depth buffer and test to get properly rendered sprites regardless of whether or not you use a perspective (versus orthographic) transform -- and either way that's a wash since you generally have to manually sort sprites back-to-front for rendering any that have alpha. You actually get that basically for free with a regular background layer index.

You can counter the resizing by pre-scaling the sprites based on depth, typically in a shader. This avoids the need to try to rely on mip-mapping to fix up the appearance (mip-mapping is a bit of a red herring here, as it only improves the visual quality of the resulting textured quad and does not fix the fundamental resizing problem and it's not why it was developed). On the other hand, you may find this scaling desirable if you're going for an obvious "2D in 3D" look, like Shadow Complex, versus an obvious 2D look like Super Mario World.

In short, like all things, it depends. If your game is meant to be a 3D game constrained to a 2D field of play, it makes sense. If it's not, and you don't need any of the small benefits (such as smooth layer transitions), it's probably not worth doing just because exactly equivalent results can be obtained with less work in another fashion.

If, on the other hand, your frameworks and toolchains are only set up for a perspective projection and cannot be changed or swapped out, and you are only doing a simple 2D game, you can certainly make it work. There's no clear answer to this and the differences between options are pretty minor.

Go with the option that involves the least work.

share|improve this answer
+1 for good answer. Hi Josh, thanks. Currently, I use two OpenGL Program IDs/Projections (one for perspective one for orthogonal projection) in my game. Is it possible from your viewpoint to combine the two projections so, that they can interact? Basically, I need a 2D ortho sprite to enter a 3D object (say a tunnel). I wisth to see, as I really enter the 3D object, not to be above or below it. Does any solution come to your mind? Does the 2D sprite have to be in Perspective projection to achieve that? – Bunkai.Satori May 26 '11 at 12:58

I am currently developing a sprite-based 2D game where we are using perspective projection instead of orthogonal one. Obvious reason for using perspective projection was that we wanted to have multiple layers with parallax scrolling and we didn't want to adjust properties for each layer (movement speed, scale) manually.

Using perspective projection in 2D game does not mean that you cannot render 2D images with full quality. We have defined a plane (Z=0) in which one texel from texture equals exactly one pixel on screen, and basically all elements that are relevant to game logic are places on this plane. Placing elements on other planes will scale the sprites as you would except. Also, note that using perspective projection does not deform sprites if they are facing the camera (as they should be). That is, a square sprite on plane Z=0 is a aquare also on any other plane (at least when you set up the projection properly; I'm not 100% sure if you can set up a projection that deforms sprites).


  • You get layers and parallax scrolling for free
  • You can add 3D objects to your scene so that they appear realistic (regarding to perspection)


  • More mathematics involved (you have to calculate plane where one texel equals one pixel)

And now, the most important thing: should you use it? Well, it's up to you. I'm very happy with our solution and it is really helping us to achieve the effect we want. On the other hand, if you simply want to draw some sprites and maybe a one background layer, then there might be too much overhead for using perspective projection instead of orthogonal one.

share|improve this answer
@user4241: +1 for great answer. Hi and thanks. As I was reading your text, few questions came to my mind: 1. what about very distand and very close objects, where the object itelf is resized. Do you keep mip mapped textures for them? 2. When an object is close to the edges to the screen and close to the camera as well, the geometry of the object changes, as the object is vieweved from an angle. Do you compensate this deformation? 3. Would you be possibly willing to share the math used to calculate plane where the one textex equals one pixel, please? – Bunkai.Satori May 26 '11 at 12:45
1) Currently we are not using mipmapping since we are not placing objects very far or very close to camera. Of course we have things like background etc. but we calculate their size so that they are pixel-perfect. However, I don't see any reason why mipmapping couldn't be used. 2) As I mentioned in my answer, geometry does not change if the sprites are facing the camera. In this case they are just like billboards and they will not certainly deform. – user4241 May 27 '11 at 5:38
About the maths: You have to find a plane in view frustum with an area equal to the area of viewport. This is very easy to calculate: plane = (1/2)*viewportHeight/tan(verticalFOV/2). Note that if you are using FOV=90 this simplifies to plane = (1/2)*viewportHeight – user4241 May 27 '11 at 6:01
@user4241: Hi and thank you again for your advices. Regarding point no 2, I have practical experiecne, that if an object is close to the camera, and if it is moved away from screen centre into corners, despite the sprite facet normal is perpendicular to the camera, it is then viewed from slight angle. But I think, this is not your case, as the sprites are quite far from the camera, so this angle is not relevant in your case. Thank you very much for your advice. – Bunkai.Satori May 27 '11 at 10:40
@bunkai: I really don't know about your case but it seems that you are doing something wrong. I'm 100% sure that you should not get any deformation if your sprites are really perpendicular to the camera. And no, you're not viewing them from "slight angle". Here is a simple proof (see next comment): – user4241 May 30 '11 at 6:24

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.