I'm trying to determine whether what I'm attempting to achieve is even possible mathematically. I'm obviously not a seasoned game developer so I'm having trouble even coming up with the terminology to pose this question.
My 2D game (and I must stress that it is 2D) has a perspective such that the "camera" looks down at the game world from 45 degrees. Here's a rough sketch describing the look I'm trying to achieve:
As objects move from foreground to background (such as the red box pictured), they not only get smaller but are moved towards the center of the screen. So whilst the on-screen representation is rectangular, the actual game world has this shape:
Now I suspect I can do all this without using a matrix. I've already got the scaling working and don't think it would be too difficult to offset on the x axis objects according to their distance from the camera.
However, what I'd really like to know is whether I can encompass this perspective inside a simple matrix. I've had a look around the web but have got lost in a sea of nomenclature that I don't understand and information that doesn't appear to be relevant to me (such as 3D camera positioning, etcetera).
Can anyone tell me whether I'm barking up the wrong tree? If it is possible, can someone point me towards some articles or blog posts that describe this in detail?
Answer
You are talking about doing manually something which is already done for you automatically by 3D APIs. One of the most basic functions of any 3D engine is to handle the transition from a bunch of objects in 3D space and a camera (naturally you must always have a camera) to a 2D picture (technically a projection) on the screen.
In your case, doubtless an object's representation moves more pixels per second going left or right than away from the camera, due to your angle (unless you deliberately have a fundamentally illogical physics model, like many such pseudo-3D games, and have those speeds be equal - not criticizing). This would be handled by what is known as the view matrix, which looks at where objects are in the world and says where they should be on the screen.
If objects far away did not get smaller, and the road away from you looked straight if it was straight (ie did not appear to narrow due to perspective) you would have the familiar isometric game. To make far away things smaller, and a few other similar things, you apply what is known as a projection matrix which pretty much takes what the camera sees, and "distorts" to show how it would look if the camera had an arbitrary lens. An isometric game has no projection matrix and thus everything is... Well, isometric.
There is usually a third kind of matrix, a world matrix, in 3D engines - because parts of 3D models are placed relative to the models origin, you need the world matrix for placing models in different points of your world. It's also like position and rotation (and scale, and skew if you have 4D matrices) of your object all in one handy mathematical entity.
So what you usually do is, you multiply (matrix multiply) these three matrices, and multiply the "model" (which is a bunch of points and polygons defined with respect to a model origin) in order to place a model's image on the screen. These matrices are not invariant, of course. For instance, the world matrix is generated depending on where your object moves.
I think isometric games are at the "2D threshold" - they are roughly the same amount of work Math-wise in 2D and 3D:
- You can make a "2D" isometric game with an identity matrix for a projection matrix, and put all sprites on billboards (in the computer graphics meaning) but you'll still have to muck about with a quite superfluous "camera" to create the 3D transformation matrices.
- You can make a 2D isometric game with sprite graphics, where you say directly where on the screen you want each sprite to be drawn (in the familiar x, y with regard to top left of the window fashion). But if you have, say an isometric RPG, and characters can jump, you'll still have to keep track of height and calculate the y coordinate accordingly, and if you don't do some trigonometry with sizes and speeds the game world will be very "strange" form a physics point of view.
However, once you do more 3D-stuff than a sprite-based isometric game would entail, as you are, I think it would be much less trouble to do everything in 3D, unless your goal is to make a 3D engine from scratch. As for your question, hopefully it is clear to you now that what you want to do can be done, it can be done easily, and it is routinely done by just about everyone out there who does 3D as a matter of course. To sum it up: Yes, it can be done, and it's fairly straightforward, but you shouldn't do it and would save yourself a lot of needless work if you just used a 3D engine.
For learning about linear algebra, you may find sources like the Khan Academy or the MIT lectures helpful. As someone who already knew linear algebra but had no idea how it applies to 3D graphics, I have found XNA and RB Whitaker's XNA tutorials very helpful and easy. They also explain using matrices for 3D like I did here, except better.
No comments:
Post a Comment