Transformation matrices in 2D games

[Jacob A Stevens]

I made this presentation in order to help explain matrix use to Paul,
and I figured the rest of you might find it helpful:

http://plasmacore.googlegroups.com/web/matrix_tranformations_2d_games.ppt?gda=1O9o01QAAABu4IqxsQXUD9yENdTBOsDR_CepHloKEmAtjSynKOESHO4-dvVJZ3Yi0RhfBaKgztsh02AG8DhNx101TWhkd38xVervUohE3YNENn3wMh1Pnc3OAWZC50hVl-fZ6-QcRqg&gsc=jxgw-BYAAACnJnnYaOoxsBu3pItZ2zQy-vghgYgES8zAzJdW7J9-8w


Normally it would be overkill to use transformation matrices in 2D
games, since the math operations required to transform objects are
relatively simple and low in number compared to 3D games. However,
with our next WiiWare project, we're doing lots of crazy stuff like
camera rotation and zooming, and our DMorph objects (to be explained
later) consist of entire meshes of 2D points that have to be
transformed. Therefore we'll be implementing an entire transformation
system and we might as well use matrices since they're faster in cases
where lots of points are processed.

Part of me wonders if we shouldn't implement some sort of matrix
system on the C side to make things faster. It could be as simple as
having a user-settable world and object matrix that is applied to
render calls. This would also solve the problem Abe and I have been
discussing regarding screen origin and application scale. Thoughts?

Jacob

[Abe]

Awesome presentation! I've been meaning to add native matrix support
for a while actually... I'll do that.

On Jan 22, 2:28 pm, Jacob A Stevens <jacobastev...@gmail.com> wrote:
> I made this presentation in order to help explain matrix use to Paul,
> and I figured the rest of you might find it helpful:
>

> http://plasmacore.googlegroups.com/web/matrix_tranformations_2d_games...

[Jacob A Stevens]

Great! Any thoughts on how you'll be implementing it? I *think* most
3D engines use a stack of matrices that gets multiplied out every time
you push or pop. This allows multiple layers of transformations like a
hat that moves with a guy's head when he's standing on a moving tank
that's loaded onto a carrier. I'm thinking that's a little
overcomplicated though, and maybe we should just support an object,
camera, and screen matrix. In general, the game would set the camera
matrix once per frame, and change the object matrix once per draw
call, and of course we would have helper functions that change the
object matrix implicitly, like draw(Vector2). If the programmer wants
a more complicated system, they can multiply out different matrices
slagside and set the native object and camera matrices. The screen
matrix would probably be reserved by use by the application for
dealing with window size, widescreen, etc, so the programmer doesn't
have to worry about that when they make camera calculations.

> > Jacob- Hide quoted text -
>
> - Show quoted text -

[Abe]

Ah, hmm, I didn't read your first post closely enough Jacob. :)

Actually the only thing I was thinking about was having some standard-
sized matrices with native layer support for the actual
multiplications. I'd be happy to expand that idea though. I haven't
heard of the matrix stack idea before (new-fangled engines!) but I
like it - seems like that system might be the easiest way to offload
calculations to the hardware where possible.

[noe...@gmail.com]

If you were to implement native matrix transformations and/or the
matrix stack for transformations why not just implement some 3d
transformations as well ;)

> > > - Show quoted text -- Hide quoted text -

[Abe Pralle]

Absolutely - already planning to!

For full 3D I'd still rather hook Slag onto an engine that's geared
for 3D from the get-go - Ogre, perhaps.

[Jacob A Stevens]

Yeah, native-side multiplications would be great, but I think the real
performance win will be automatically transforming polygon renders by
matrices that are stored on the native side. If you look at your game
code, a significant amount of the operations performed on in the redraw
() cycle are used to offset sprites to the world and object positions.
Add in rotation and scaling, and you quickly end up with dozens of
operations per point. Again, for simpler games with straightforward
cameras this isn't a problem. But for games with fully-transformable
cameras and lots of freeform objects, I think using a natively
implemented transform will allow us to render significantly more
objects.

On Jan 24, 12:04 pm, Abe <abe.pra...@gmail.com> wrote:

> > > - Show quoted text -- Hide quoted text -

[Abe Pralle]

DWORD!