0
\$\begingroup\$

Hi I am making a 2D game, where the Camera is able to rotate / zoom in or out on the camera focus (the player usually).

However my game also contains a mini-map, and so far whenever I have to rotate / zoom my camera the mini-map rotates and zooms accordingly. This behaviour was expected, but now I am a little stuck on "un-doing" the changes the view transformation has on my mini-map. What I want to happen is to essentially keep my mini-map statically in the same position throughout the game no matter how the camera rotates or zooms.

I am extremely rusty with my linear algebra / 3D transformations but I have tried the following...

My first thought was, I thought all I had to do was to transform the mini-map origin point with the view matrix, then undo the scaling of the zoom against the mini-map width / height. The zooming was fixed, but the mini-map still rotated so this did not work.

My second try, I remembered to undo the change of a matrix, I would have to multiply the transform by its inverse. So I tried to calculate the inverse matrix, however the determinant of the view matrix was 0, so I could not find an inverse.

Ok... well I guess I'll just see if I can get the rotation down, since I got the zoom to work... So I transformed my mini-map origin by the inverse rotation matrix applied by the view matrix... The mini-map is rotating now, but is not staying in the fixed position I was hoping for.

I was wondering, if anyone here can give me a push in the right direction, or a hint towards a more elegant solution overall. If people would like more information I can upload images, show code... But what I wrote above is exactly how my code would look.

Thanks for any help!

\$\endgroup\$
  • 1
    \$\begingroup\$ Can you try to succinctly describe what you want to happen? I read this a couple times and all I can figure out is that you want to undo something, but you're not explicit. \$\endgroup\$ – RandyGaul Dec 21 '13 at 0:37
  • \$\begingroup\$ Sorry, I made an edit to the original post. What I want to happen is to essentially keep my mini-map statically in the same position throughout the game no matter how the camera rotates or zooms. However currently whenever I zoom or rotate the camera the map zoom or rotates along with it. I tried to undo the change by trying to transform the original point of the mini-map by the inverse of view transformation but there was no inverse. So then I tried the inverse of the rotation matrix but that didn't work. I tried a few other things but couldn't come up with a solution. \$\endgroup\$ – BZhang Dec 21 '13 at 0:46
  • 1
    \$\begingroup\$ @BZhang Is there some reason you don't just compute the mini-map's matrix once, and keep using the same matrix for the duration of the game? In other words, why is the mini-map matrix based on the current camera matrix at all, if you don't want it to mirror the camera motion? \$\endgroup\$ – Nathan Reed Dec 21 '13 at 1:25
  • \$\begingroup\$ You should figure out what sort of transformation you want to apply, and then apply only that transformation to your minimap. It sounds like you want a very simple model to camera type of transformation. Since the minimap is static you can, like Nathan Reed suggested, calculated this transformation a single time and use it upon the minimap images. To go from model to world you'll generally apply scale, then rotation, then translation. The scale and translation might be the only things you need to do. \$\endgroup\$ – RandyGaul Dec 21 '13 at 1:34
  • \$\begingroup\$ Calculating inversions will be harder, and these are transform inversions, not full matrix inversions. This requires some understanding you might not have right now. To invert a transformation I actually decompose a matrix into the scale rotation and translation components, invert those separately and build the final inverted result. You can try checking it out if you like: bitbucket.org/rgaul/sel/src/… \$\endgroup\$ – RandyGaul Dec 21 '13 at 1:35
2
\$\begingroup\$

No, usually you don't undo transform by applying inverse. Because precision errors love to accumulate. Instead, either precalculate desired transform and set it directly, or reset current transform to identity and start over.

This answer is api-agnostic. If there is way to manipulate current transform, then should be also way for resetting it. (I am not familiar with XNA, sorry.)

\$\endgroup\$
1
\$\begingroup\$

You would be able to render your minimap to a texture (or alternatively use a pre-existing texture).

This article helps with learning RTT: http://rbwhitaker.wikidot.com/render-to-texture

Once you have the texture, you can simply draw the minimap as a standard SpriteBatch.

\$\endgroup\$
  • \$\begingroup\$ Hi, this seems very interesting I'll definitely take a look into this. If I were to draw to a seperate texture, wouldn't that texture still be effected by the camera rotation / zoom changes? Would I need a seperate sprite batch to not be effected by the camera transform? \$\endgroup\$ – BZhang Dec 21 '13 at 13:00
  • \$\begingroup\$ SpriteBatches are drawn directly to the screen regardless of what your camera is doing in the 3d world. So if you have a texture of your minimap, you can draw it with a SpriteBatch and it will just work. You can use many techniques to get that texture, with RTT being just one of those possible techniques. RTT is affected by the camera rendering it, but you would likely use a separate camera/view dedicated entirely for the RTT. That way you get the desired view regardless of what your main camera is doing. \$\endgroup\$ – user39686 Dec 21 '13 at 13:33
  • \$\begingroup\$ I haven't tested the RTT thing, but having a seperate sprite batch does indeed do what I want it to. Thank you very much! However isn't having multiple sprite batches a bad practice? Is there another way around this? If not I will probably stick with two sprite batches for now. \$\endgroup\$ – BZhang Dec 21 '13 at 13:49
  • \$\begingroup\$ SpriteBatches allow you to draw multiple different sprites from the same batch. It's not evil to have multiple sprite batches, but you would get better performance by throwing related elements into the same batch. For example, all of my UI sprites are in the same texture, and it only costs me 1 batch. I also have separate batches for my maps, characters, and items. You just don't want everything in the same batch, otherwise you get a huge texture that's taking up too much memory. \$\endgroup\$ – user39686 Dec 21 '13 at 15:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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