Move Only Camera Libgdx How To Do Various

All developers, with any skill level, are welcomed to join the B4X community.

For a better experience, please enable JavaScript in your browser before proceeding.

But if that only happens when you move the camera, the reason behind may also be a rounding problem of the coordinates.

All coordinates once converted to screen coordinates should give integers.

For performance, its better to avoid abusing of Spritebatch instances but 2 is not a problem at all.

By continuing to use this site, you are consenting to our use of cookies.

Anything referenced on this blog is copyrighted by the respective owner.

As part of my resolution to actually blog something useful and generally contribute to the world of programming, Ive decided to reinstate this blog and make a relevant new post.

So without further ado, this first outing will be about setting up a 2D orthographic camera with mouse scroll support.

Move Only Camera Libgdx How To Do Various

The forum contains many posts detailing how to do various solutions but for programmers like myself who just want an example, its a little frustrating.

Firstly, in order to have sensible scrolling speed and a decoupling of world dimensions from rendering dimensions, you need a ratio of pixels to world unit.

In this example well use a simple constant for this, along with a fixed world size.

Secondly we need to create the basic screen that well be using to render.

This is literally a Screen object and contains all the objects we need for rendering: public class ScrollableScreen implements Screen, InputProcessor, Constants.

What does this mean when were using Box2D It means we can simply pass the world position to the rendering call without worrying about any messy calculations.

Awesome The last critical thing we need to implement is the resize method content.

This is remarkably simple and, incidentally, is called before render, allowing us to dump all the dimension calculations in this method.

Remember that libgdxs camera handles the rendering transform for us, but in order to maintain this we must specify the camera in world coordinates as well.

Given that we have a fixed pixel per meter ratio and we know the new width of the screen, its simply the matter of calculating the number of meters the screen can now display and telling OpenGL to give us a window sized appropriately.

This is necessary as setToOrtho will reset the cameras position to WIDTH2 and HEIGHT2, which isnt ideal.

We recorded the old position of the camera on line 1 so the translation is the difference between this and the new position.

Now what we get when resizing the OpenGL window is more of the world being shown, rather than the same amount of the world being shown but stretched to the window resolution.

The camera will remain focused on the same position as before to prevent disorientation of the player.

Now that rendering is resolution agnostic we can implement scrolling.

This requires filling in the methods touchDown, touchUp, touchDragged and touchMoved.

Theres no need to unproject for translation as we already have a suitable translation distance: the difference between the current and last mouse position and the scale of the world to the screen.

By dividing the distance the mouse has dragged by the actual distance this represents in the world we can provide a sensible screen distance to move the camera.

Note that the Y parameter to the translate call uses the negative PIXELSPERMETER value, as Y is up in OpenGL.

The camera position will be maintained during the resize so that whatever it was looking at isnt suddenly displaced or off screen altogether.

Zoom is conveniently handled by the camera internals so doesnt need to be taken into account here.