Libgdx with Android For Game Dev
Game Dev Tutorial 6 : Viewport & Camera
Game Dev -All Game Dev Tutorials
In this gamedev tutorial, we are going to learn about 'Viewport'(extendViewport) and 'Orthographic Camera', for viewing our on screen game assets. There are lots of game asset types, like: an image(texture), a font(bitmapfont), a tiled map, a character(sprite), obstacle(sprite). For this tutorial, our assets are our two images - our textures. Our previous tutorial app and code, Game Fonts, will be used for this tutorial. However, we only require two images for this tutorial, so we can just remove the others from code. All code is at the Example Code section this page. Just copy and paste to replace what's on, 'MyGdxGame.java', code page now, or simply update the code where needed.
For this tutorial, the app shots are from a 5.8" smartphone, and shown both for portrait and landscape orientation. When making a mobile game app, you likely will preference one orientation or the other, portrait or landscape, or perhaps your game is suitable for both. This will mostly depend of the particulars of your game, and which orientation is best suited to it.
In our previous tutorial, we discussed image fonts, and how they can be used with different device sizes, and the importance of making them scalable across different device sizes. So you might make them for a 5" screen size, but want them to look good and scale to a 8" screen size; so you make the font the appropriate size for that.
The other consideration is making sure your image fonts(image with a font text added) or just textures(images) stay within the bounds of the screen on all your targeted device sizes, and, that they don't change shape when the screen is resized. A screen can get resized any number of ways: for example, when a user does something like; go from portrait mode to landscape mode, or uses their smartphone to play your game while traveling, but their larger tablet while at home. To address these game play scenarios, you want to make sure your game can scale well across devices and viewport sizes. To keep our game assets(fonts, textures) within the game screen bounds, and, also maintain their aspect ratio, we use something called 'viewport', and 'orthographic camera'.
This is Easy to do.
We can use the same code from the Example Code section for both. For the 1st app we RUN, we simply leave the code notated(this omits the Viewport & Camera code), and, with the 2nd app we RUN, we just remove the // notated forward lines so that those lines of code will RUN(include the Viewport & Camera).
Let's look at our next images of the app shots.
The portrait orientation shot also has the 256x256 image out of bounds. This is what can happen when you add textures to your game but do not include the Viewport or a Orthographic Camera.
App Shots -
No Viewport or Camera Added
With a 512 and a 256 size image, Screen size 5.8"
This next image shows the code we used to make the app without the Viewport and Orthographic Camera.
You can see the code for the Viewport and Camera is in the code but we notated it so it doesn't execute.
Imports and Variables - Notated(green text)
This code has been notated so that the Viewport and Camera will not be included
Create Method - Notated(green text)
The Extended Viewport & Orthographic Camera Code
We add the code for our Viewport and Camera. We must include an import statement for each, and, variables, and create, methods.
And, also at the create method, we add the code for the 'resize', and 'setProjectionMatrix' calls. This is important because this code is what tells the viewport to resize the texture, and then pass it along to the Orthographic camera using the 'setProjectionMatrix'.
So whenever you add a Viewport and Camera, the viewport will update the images on the screen based on the screen size.
The 'resize' method, shown at Create Method, in the image notated, tells the sprite batch to use the camera. Also at the Create Method, at the New Viewport, the sizes: 800,600, are the resolution at which our sprites are scaled to 100%. If the window gets bigger than that, the sprites will grow, if it gets smaller, the sprites will shrink, both while maintaining their original aspect ratios.
Lets look at the these next app shots with the Viewport and Camera added.
App Shots -
WITH Viewport and Camera Added
With a 512 and a 256 size image
Imports and Variables
This code, ExtendViewport and Orthographic Camera added
Create, Render, and Dispose methods
Then, when you want to incorporate that notated code back in to be executed, you need only removed the //, and then RUN your code.
That is how we coded in this tutorial. The green colored notated code is the code for the ExtendViewport and Orthographic camera. As you can see it is added at imports, at variables, and in the create method. It is not required at render or dispose methods for this tutorial.
If your not using or done using a particular asset just goto the 'assets' folder select the item and then select delete. This can be done in the AIDE editor. You can also delete items by using the device's File Manager. So, for this tutorial, we require only the 512 and 256 images, so you can delete the others from the assets folder. Keep these two: image_with_text_512.png, and image256.png, as shown at the code in the Example Code section.
FYI
App Shots -
No Viewport or Camera Added
With a 512 and a 128 size image
In this app we switched out the 256x256 for a 128x128 size image, and you can see that in the portrait orientation the image is within bounds of the device screen. However, when resizing the screen to landscape orientation, both of the images still display as squished. Always check your images and assets by resizing to the landscape mode, especially if your targeting your mobile game for both orientations.
Across Devices - 8" Tablet and 5.8" Smartphone
Viewport and Camera Added To The Code
I installed the app with the Viewport and Camera added, on the 5.8" smartphone, and also a 8" tablet. In this next image shot; you see they scale across the devices as they should while keeping their aspect ratios, including the portrait and landscape orientation. And, as mentioned previously in this tutorial, the resolution sizes set are the: 800,600. At this resolution the sprites are scaled to 100% on the 5.8" screen size. If the screen gets larger,(the tablet) the images will get bigger, and if the screen gets smaller than 5.8" screen, then they change proportionally to that screen size also, they get smaller.
Things to know about the orthographic camera:
Renders objects in the scene exactly as they are, without any size variation due to distance.(just to note; a perspective camera does show size variation due to distance)
Useful for 2D environments.
Parallel projection (no perspective).
Objects maintain their relative sizes regardless of their distance from the camera.
OrthographicCamera - which is required for attaching a 2D environment to a viewport.
In this tutorial, we used the 'extendViewport', however, there are several Viewport types that can be used for game dev, each with their pros and cons. The popular concensus seems to be with an ExtendViewport coupled with a FitViewport for layered games(screens). Based on your game type and objectives, you might find other viewport types more appropriate. To learn more about the different types of Viewports and their use(FitViewport, ScreenViewport, ExtendViewport, FillViewport) read this good article from the Q's at StackOverFlow - Viewports & Camera Explained
Game Dev -All Game Dev Tutorials
In this gamedev tutorial, we are going to learn about 'Viewport'(extendViewport) and 'Orthographic Camera', for viewing our on screen game assets. There are lots of game asset types, like: an image(texture), a font(bitmapfont), a tiled map, a character(sprite), obstacle(sprite). For this tutorial, our assets are our two images - our textures. Our previous tutorial app and code, Game Fonts, will be used for this tutorial. However, we only require two images for this tutorial, so we can just remove the others from code. All code is at the Example Code section this page. Just copy and paste to replace what's on, 'MyGdxGame.java', code page now, or simply update the code where needed.
For this tutorial, the app shots are from a 5.8" smartphone, and shown both for portrait and landscape orientation. When making a mobile game app, you likely will preference one orientation or the other, portrait or landscape, or perhaps your game is suitable for both. This will mostly depend of the particulars of your game, and which orientation is best suited to it.
In our previous tutorial, we discussed image fonts, and how they can be used with different device sizes, and the importance of making them scalable across different device sizes. So you might make them for a 5" screen size, but want them to look good and scale to a 8" screen size; so you make the font the appropriate size for that.
The other consideration is making sure your image fonts(image with a font text added) or just textures(images) stay within the bounds of the screen on all your targeted device sizes, and, that they don't change shape when the screen is resized. A screen can get resized any number of ways: for example, when a user does something like; go from portrait mode to landscape mode, or uses their smartphone to play your game while traveling, but their larger tablet while at home. To address these game play scenarios, you want to make sure your game can scale well across devices and viewport sizes. To keep our game assets(fonts, textures) within the game screen bounds, and, also maintain their aspect ratio, we use something called 'viewport', and 'orthographic camera'.
How Viewport & Orthographic Camera Work
Simply stated, a viewport and orthographic camera work together to keep our game screen assets visible in the game screen play area. The viewport keep the aspect ratios of textures in sync no matter the device's game screen size, and the camera shows the game screen at a particular position with a specified view.No Viewport, No Orthographic Camera
For our tutorial, we are going to make 2 variations of our game screen; one without the Viewport and Camera added, and then one with them added so you can see how the Viewport and Camera affect the positioning and aspect ratios of the textures on the screen.This is Easy to do.
We can use the same code from the Example Code section for both. For the 1st app we RUN, we simply leave the code notated(this omits the Viewport & Camera code), and, with the 2nd app we RUN, we just remove the // notated forward lines so that those lines of code will RUN(include the Viewport & Camera).
Let's look at our next images of the app shots.
Squished Textures and Out of Bounds
Looking at these next images of the app(app shots), we can see that in our landscape orientation shot, both the 512x512 image, and the 256x256 image look squished, and that's because they are squished. And, the image to the right of the screen is partially out of bounds - the 256x256.The portrait orientation shot also has the 256x256 image out of bounds. This is what can happen when you add textures to your game but do not include the Viewport or a Orthographic Camera.
App Shots -
No Viewport or Camera Added
With a 512 and a 256 size image, Screen size 5.8"
This next image shows the code we used to make the app without the Viewport and Orthographic Camera.
You can see the code for the Viewport and Camera is in the code but we notated it so it doesn't execute.
Imports and Variables - Notated(green text)
This code has been notated so that the Viewport and Camera will not be included
Create Method - Notated(green text)
Viewport & Orthographic Camera Added
These next app shots show the portrait and landscape orientation of our app that has the Viewport and Camera added. You will notice that the images have the proper aspect ratios, and that they are inbound, within the viewport area. And, also note that both orientations have the same aspect ratios, and are resizing as they should. This is accomplished by adding the Viewport & Orthographic Camera to your app code.The Extended Viewport & Orthographic Camera Code
We add the code for our Viewport and Camera. We must include an import statement for each, and, variables, and create, methods.
And, also at the create method, we add the code for the 'resize', and 'setProjectionMatrix' calls. This is important because this code is what tells the viewport to resize the texture, and then pass it along to the Orthographic camera using the 'setProjectionMatrix'.
So whenever you add a Viewport and Camera, the viewport will update the images on the screen based on the screen size.
The 'resize' method, shown at Create Method, in the image notated, tells the sprite batch to use the camera. Also at the Create Method, at the New Viewport, the sizes: 800,600, are the resolution at which our sprites are scaled to 100%. If the window gets bigger than that, the sprites will grow, if it gets smaller, the sprites will shrink, both while maintaining their original aspect ratios.
Lets look at the these next app shots with the Viewport and Camera added.
App Shots -
WITH Viewport and Camera Added
With a 512 and a 256 size image
Code For Viewport and Camera
All we need to do is 'un notate' the code,(shown in this next image) remove the // lines from the beginning of the code lines. Then SAVE our app code, then RUN our app. The code we unnotated we now include in our app BUILD. Just RUN, UPDATE, and open the app by clicking on the app ICON, (little green android icon), with the wording, 'Game Fonts'. Now, you see the updated app code showing the images properly displayed in both the portrait and landscape orientations.Imports and Variables
This code, ExtendViewport and Orthographic Camera added
Create, Render, and Dispose methods
Notating Game Code
Sometimes when coding, you want to try a variety of codes, and a simple way to include code for reference without having to retype it is to include it in notations or commenting it. As mentioned in our previous tutorial, notating code is easy to do; you simply add // forward slash lines in front of lines of code. If the code wraps to another line add notations to that line also.Then, when you want to incorporate that notated code back in to be executed, you need only removed the //, and then RUN your code.
That is how we coded in this tutorial. The green colored notated code is the code for the ExtendViewport and Orthographic camera. As you can see it is added at imports, at variables, and in the create method. It is not required at render or dispose methods for this tutorial.
Updating Game Assets Folder
If your not using textures(images,videos,mp3s,tilemaps) that were added to your Assets folder, you can delete them from the folder in your gdx-game-android file hierachy; so, for this tutorial app project: - Game Fonts. For mobile game apps(and non game android apps), the best practice is to remove game assets your not using, because over time this can possibly lag game play, depending on how many assets your game has.If your not using or done using a particular asset just goto the 'assets' folder select the item and then select delete. This can be done in the AIDE editor. You can also delete items by using the device's File Manager. So, for this tutorial, we require only the 512 and 256 images, so you can delete the others from the assets folder. Keep these two: image_with_text_512.png, and image256.png, as shown at the code in the Example Code section.
FYI
App Shots -
No Viewport or Camera Added
With a 512 and a 128 size image
In this app we switched out the 256x256 for a 128x128 size image, and you can see that in the portrait orientation the image is within bounds of the device screen. However, when resizing the screen to landscape orientation, both of the images still display as squished. Always check your images and assets by resizing to the landscape mode, especially if your targeting your mobile game for both orientations.
Across Devices - 8" Tablet and 5.8" Smartphone
Viewport and Camera Added To The Code
I installed the app with the Viewport and Camera added, on the 5.8" smartphone, and also a 8" tablet. In this next image shot; you see they scale across the devices as they should while keeping their aspect ratios, including the portrait and landscape orientation. And, as mentioned previously in this tutorial, the resolution sizes set are the: 800,600. At this resolution the sprites are scaled to 100% on the 5.8" screen size. If the screen gets larger,(the tablet) the images will get bigger, and if the screen gets smaller than 5.8" screen, then they change proportionally to that screen size also, they get smaller.
In Summary
In this tutorial, you learned the basics of ExtendViewport and Orthographic Camera, and how to add them into your game code. Viewport and Orthographic Camera are important methods to include in your game code to keep your assets within the bounds of the viewport and keep them looking as you intended for game play. Mobile games are played on many different device sizes so including appropriate asset sizes to accommodate for this is good game dev practice.Things to know about the orthographic camera:
Renders objects in the scene exactly as they are, without any size variation due to distance.(just to note; a perspective camera does show size variation due to distance)
Useful for 2D environments.
Parallel projection (no perspective).
Objects maintain their relative sizes regardless of their distance from the camera.
OrthographicCamera - which is required for attaching a 2D environment to a viewport.
In this tutorial, we used the 'extendViewport', however, there are several Viewport types that can be used for game dev, each with their pros and cons. The popular concensus seems to be with an ExtendViewport coupled with a FitViewport for layered games(screens). Based on your game type and objectives, you might find other viewport types more appropriate. To learn more about the different types of Viewports and their use(FitViewport, ScreenViewport, ExtendViewport, FillViewport) read this good article from the Q's at StackOverFlow - Viewports & Camera Explained
EXAMPLE CODE - Code For This Tutorial.
JUST copy and paste to update your code.
JUST copy and paste to update your code.