Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
9. January 2015

 

I needed to create a sprite sheet for an upcoming tutorial series and managed to throw one together in an amazingly short amount of time with almost no artistic ability.  Good looking art with no ability is something many indie game developers are screaming for, so I figured I would share the process.

 

During the tutorial we use the following programs:

Mixamo Fuse (Free version available, MSRP $99USD)

Blender (Free and Open Source)

TexturePacker (Free version available, MSRP $50USD)

 

If you want more details on Mixamo, I extensively review it here.

 

The ultimate output from this entire process is the sprite sheet powering this animation:

bigguy

 

And here is the resulting sprite sheet, click it for the full resolution version:

a

 

Now finally, the video.  You can watch it in full 1080p on YouTube.

 

Coincidentally, if you want more information on how I created the above animated gif, I used a program called Cryotek Animated GIf Creator, and document the process here.  It’s a very cool program and completely free.

Programming Art General


4. January 2015

 

Gamefromscratch has a long running series taking an indepth look at various game engines available.  Today we are going to look at the Godot game engine, an open source C++ based game engine with a complete Unity-esque world editor.  Godot runs on Windows, Linux and Mac platforms and can target all of those, plus iOS, Android, PS3 and PS Vita, NaCL with HTML5 and Windows Phone both being in development.

 

In Godot’s own words:

Godot is an advanced, feature packed, multi-platform 2D and 3D game engine. It provides a huge set of common tools, so you can just focus on making your game without reinventing the wheel.

 

That description is incredibly apt as well, you will certainly be surprised by just how many tools are included.  Now let’s jump right in!

 

There is a video on this post available here (and embedded at bottom of the page) which goes in to a bit more detail.

 

The Editor

 

You get started with Godot by downloading the executable from the downloads page.  You probably expect this to be an installer, but you would be wrong.  Instead when you run it you get the Project Manager:

image

 

Here you can either create a new project or load an existing one.  Finally once you’ve selected or created, you are brought to the editor:

image

 

This is where the magic happens.  The above screenshot is of the Platformer demo being edited.  The left hand window is where your scene is composed.  As you can see from the four tabs above, you can work in 2D, 3D, Script editing or browse the built in help in this window.  The top left icons are actually menus and a lot of the functionality and tools are tucked away behind Scene and Import.

 

The top right hand dialog is your scene graph:

image

 

Here you can see ( and create/instance ) the items that make up your world.  Simply click the New Icon to add a new items to the world, or the + Icon to add a new instance instead.  The other icons are for wiring scripts and signals (events) up to the objects in your world.

 

Below the scene graph, you’ve got the Inspector window, which enables you to set properties of objects in your scene.  As you can see from the screen shot, Godot takes a very modular/component approach which is quite popular these days:

image

 

This enables you to visual inspect and edit properties of your game objects.  It also represents one of the first flaws of Godot… some of the controls are just awkward to use.  For example if you don’t hit enter after editing a text property, the values are lost.  Additionally modifying numeric fields can be a pain in the ass at times.  It’s all stuff that can be fixed with time ( Godot was only open sourced about a year ago after all ) but for now its clunky and somewhat annoying.

 

Coding

 

So that’s the visual editor… what about code? 

 

Well the majority of your programming is going to be done in GDScript, using the included editor.  GDScript is a Python-esque proprietary scripting language.  I don’t generally like this approach as it makes all the existing tools and editors worthless, lose the years of bug fixing, performance improvements, etc…  while forcing a learning curve on everyone that wants to use the engine.  That said, the idea behind a scripting language is they should be easy to use and learn.

 

The authors explained their decision in the FAQ:

 

The short answer is, we'd rather a programmer does the small effort to learn GDScript so he or she later has a seamless experience, than attracting him or her with a familiar programming language that results in a worse experience. We are OK if you would rather not give Godot a chance because of this, but we strongly encourage you to try it and see the benefits yourself.

The official languges for Godot are GDScript and C++.

GDScript is designed to integrate from the ground to the way Godot works, more than any other language, and is very simple and easy to learn. Takes at much a day or two to get comfortable and it's very easy to see the benefits once you do. Please do the effort to learn GDScript, you will not regret it.

Godot C++ API is also efficient and easy to use (the entire Godot editor is made with this API), and an excellent tool to optimize parts of a project, but trying to use it instead of GDScript for an entire game is, in most cases, a waste of time.

Yes, for more than a decade we tried in the past integrating several VMs (and even shipped games using them), such as Python, Squirrel and Lua (in fact we authored tolua++ in the past, one of the most popular C++ binders). None of them worked as well as GDScript does now.

More information about getting comfortable with GDScript or dynamically typed languages can be found here.

 

That covers the why anyways, now let’s look at the language itself.  As I said earlier, it’s a Python like (whitespace based) scripting language.  Let’s look at an example from the included demos:

extends RigidBody2D


const STATE_WALKING = 0
const STATE_DYING = 1

var state = STATE_WALKING
var direction = -1
var anim=""
var rc_left=null
var rc_right=null
var WALK_SPEED = 50

var bullet_class = preload("res://bullet.gd")

func _die():
   queue_free()

func _pre_explode():
   #stay there
   clear_shapes()
   set_mode(MODE_STATIC)
   get_node("sound").play("explode")
   

func _integrate_forces(s):

   var lv = s.get_linear_velocity()
   var new_anim=anim

   if (state==STATE_DYING):
      new_anim="explode"
   elif (state==STATE_WALKING):
      
      new_anim="walk"
      
      var wall_side=0.0
      
      for i in range(s.get_contact_count()):
         var cc = s.get_contact_collider_object(i)
         var dp = s.get_contact_local_normal(i)
         
         if (cc):
         
            
            if (cc extends bullet_class and not cc.disabled):
               set_mode(MODE_RIGID)
               state=STATE_DYING
               s.set_angular_velocity(sign(dp.x)*33.0)
               set_friction(true)
               cc.disable()
               get_node("sound").play("hit")
               
               break
            

         if (dp.x>0.9):
            wall_side=1.0
         elif (dp.x<-0.9):
            wall_side=-1.0
            
      if (wall_side!=0 and wall_side!=direction):
      
         direction=-direction
         get_node("sprite").set_scale( Vector2(-direction,1) )       
      if (direction<0 and not rc_left.is_colliding() and rc_right.is_colliding()):
         direction=-direction
         get_node("sprite").set_scale( Vector2(-direction,1) )
      elif (direction>0 and not rc_right.is_colliding() and rc_left.is_colliding()):
         direction=-direction
         get_node("sprite").set_scale( Vector2(-direction,1) )
         
         
      lv.x = direction * WALK_SPEED
         
   if( anim!=new_anim ):
      anim=new_anim
      get_node("anim").play(anim)
            
   s.set_linear_velocity(lv)


func _ready():
   rc_left=get_node("raycast_left")
   rc_right=get_node("raycast_right")

 

As someone raised on curly braces and semi colons it can take a bit of time to break muscle memory, but for the most part the language is pretty intuitive and easy to use.  You can see a quick language primer here.

Remember earlier I said the code editor was built into the engine, let’s take a look at that now:

image

 

As you can see, the editor does provide most of the common features you would expect from an IDE, a personal favorite being auto-completion.  Features like code intention, find and replace and auto indention are all available, things often missing from built in editors.   Like dealing with the Inspector window though their can be some annoyances, like the autocomplete window appearing as you are trying to cursor around your code, requiring you to hit Escape to dismiss it.  For the most part though the editing experience is solid and hopefully some of the warts disappear with time.

 

Now perhaps the biggest deal of all:

image

Debugging!  This is where so many home made scripting languages really suck, the lack of debugging.  Not Godot:

image

You can set breakpoints, step into/over your running code and most importantly inspect variable values and stack frames.  Once again, it’s the debugging experience that often makes working in scripting languages a pain in the ass, so this is nice to see!

 

Hey, What about C++???

 

Of course, one of the big appeals of Godot is going to be the C++ support, so where exactly does that come in?  Well first and most obviously, Godot is written in C++ and fully open source under the MIT license ( a very very very liberal license ), so you can of course do whatever you want.  I pulled the source from Github and built without issue in Visual Studio 2013 in just a few minutes.  The build process however is based around Scons, which means you have to Python 2.7x and Scons installed and configured, but neither is a big deal.

 

What about extending Godot, that is what the majority of people will want to do.  Well fortunately it’s quite easy to create C++ extensions, although again you need Scons and have to do a bit of configuration, but once you’ve done it once assuming you’ve got a properly configured development environment the process should be quick and mostly painless.  From the wiki page here is a sample C++ module:

 

Sumator.h

/* sumator.h */
#ifndef SUMATOR_H
#define SUMATOR_H

#include "reference.h"

class Sumator : public Reference {
    OBJ_TYPE(Sumator,Reference);

    int count;

protected:
    static void _bind_methods();
public:

    void add(int value);
    void reset();
    int get_total() const;

    Sumator();
};

#endif

Sumator.cpp

/* sumator.cpp */

#include "sumator.h"

void Sumator::add(int value) {

    count+=value;
}

void Sumator::reset() {

    count=0;
}

int Sumator::get_total() const {

    return count;
}

void Sumator::_bind_methods() const {

    ObjectTypeDB::bind_method("add",&Sumator::add);
    ObjectTypeDB::bind_method("reset",&Sumator::reset);
    ObjectTypeDB::bind_method("get_total",&Sumator::get_total);
}

Sumator::Sumator() {
    count=0;
}

 

Then in your script you can use it like:

var s = Sumator.new()
s.add(10)
s.add(20)
s.add(30)
print( s.get_total() )
s.reset()

 

If you inherit from Node2D or a derived class, it will be available in the editor.  You can expose properties to the inspector and otherwise treat your module like any other Node available.  Remember though, for productivity sake, you should really only be dropping to C++ as a last resource.  It is however quite simple to do.

 

Nodes, Nodes and more Nodes

At the heart of Godot, the world is essentially a tree of Nodes, so I suppose it’s worthwhile looking at some of the nodes available and how they work.  From the scene graph window, you add a new node to the world using this icon:

image

 

Next it’s a matter of picking which type, which could of course include modules you created yourself in C++.

image

 

As you can see from the small portion I’ve shown above, there are a LOT of built in nodes already available.  From UI controls, to physics controllers, path finding and AI tools, bounding containers, video players and more.  Essentially you create your game by composing scenes, which then are composed of nodes.  Once you’ve created a node you can then script it.  Simply select your node in the scene graph and then click the script icon:

image

 

Then a New Script dialog will be displayed:

image

 

And your script will be created:

image

 

As you can see, the script itself inherets from the node type you selected.  You can now script any and all logic attached to this particular Node.  Essentaily your game logic is implemented here.

 

In addition to wiring up scripts to game nodes, you can also wire up Signals.

image

 

Signals can be thought of as incoming events:

image

 

HELP!

 

So, what about Help then?  Well this is both a strength and weakness of Godot.  As you saw earlier, there is actually an integrated help tab.  You can look it up any time, or use press SHIFT + F1 while coding to get context sensitive help:

image

It’s invaluable, but unfortunately the resulting help file is often just a listing of methods/parameters and nothing more.  I often instead just keep the class reference from the Wiki open in a browser window.  For an open source project, the reference is pretty good, but it could still certainly use a lot more love.

 

Next are the tutorials, there’s a fairly good selection available on the Wiki but I think a good in-depth beginner series is really needed.  To someone that just downloaded Godot and is thinking “now what”… that presents a challenge. That said, I will probably be creating one, so this shouldn’t be an issue in time!

 

Finally, and perhaps most valuably, there are several demos included:

image

 

Publishing

 

So, once you’ve finished your game, how do you publish it to the various available platforms?  Well for starters you click the Export button:

image

 

You also need an export template, which is available from the Godot downloads site.  Additionally you need to  configure the tool chain for each platform, such as the Android SDK for Android, XCode for iOS ( and a Mac!  You can’t end run around the needing a Mac for iOS development requirement unfortunately), etc.  But the process is spelled out for you and they make it pretty easy.

 

Summary

 

I haven’t even really touched upon the plethora of tools tucked away in the editor…  need to import a font, there’s a tool for that.  There’s an improved Blender COLLADA plugin which just worked when I tried it.  There’s a tool for mapping controls to commands, there are tools for compressing and modifying textures on import, for modifying incoming 3D animations, etc…  Basically if you need to do it, there is probably a tool for it shoved in there somewhere.

 

On the other hand, the process itself can be pretty daunting.  Figuring out how to get input, a script’s life cycle etc isn’t immediately obvious.  It really is an engine you have to sit down with and just play around.  Sometimes you will hit a wall and it can be pretty damned frustrating.  However, it’s also a hell of a lot of fun and once it starts to click it is a great engine to work in.

 

I definitely recommend you check out Godot, especially if you are looking for an open source Unity like experience.  That said, calling this a Unity clone would certainly be doing it a disservice, Godot is a great little game engine on it’s own accord that deserves much more exposure.

 

The Video Version

 

Click here for the full resolution 1080p version.

Programming


19. December 2014

 

In this tutorial we look at the process of creating and using a Spritesheet in LibGDX.  This involves creating a series of sprites, putting them together with TexturePacker, then using a TextureAtlas and TextureRegion to display them with our Sprite.  We also quickly look at TexturePacker ( different product ) for those that prefer a UI.  Sample code and links to included assets below the video.

 

Once again, you can view the video in HD on YouTube by click here.

 

 

Example’s Source

package com.gamefromscratch;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.Input;
import com.badlogic.gdx.InputProcessor;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.g2d.Sprite;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;
import com.badlogic.gdx.graphics.g2d.TextureAtlas;
import com.badlogic.gdx.graphics.g2d.TextureRegion;

public class SpritesheetDemo extends ApplicationAdapter implements InputProcessor {
   SpriteBatch batch;
   TextureAtlas textureAtlas;
   Sprite sprite;
   TextureRegion textureRegion;
   int currentFrame = 1;
   int MAX_FRAMES = 19;
   
   @Override
   public void create () {
      batch = new SpriteBatch();
      textureAtlas = new TextureAtlas(Gdx.files.internal("ss.txt"));
      textureRegion = textureAtlas.findRegion("0001");
      sprite = new Sprite(textureRegion);
      sprite.setPosition(Gdx.graphics.getWidth()/2 - sprite.getWidth()/2,
            Gdx.graphics.getHeight()/2 - sprite.getHeight()/2);

      Gdx.input.setInputProcessor(this);
   }

   @Override
   public void render () {
      Gdx.gl.glClearColor(0, 0, 0, 1);
      Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);
      batch.begin();
      sprite.draw(batch);
      batch.end();
   }

   @Override
   public boolean keyDown(int keycode) {
      if(keycode == Input.Keys.UP){
         currentFrame++;
         if(currentFrame > MAX_FRAMES)
            currentFrame = 1;
         sprite.setRegion(textureAtlas.findRegion(String.format("%04d",currentFrame)));
      }
      if(keycode == Input.Keys.DOWN){
         currentFrame--;
         if(currentFrame < 1)
            currentFrame = MAX_FRAMES;

         sprite.setRegion(textureAtlas.findRegion(String.format("%04d",currentFrame)));
      }
      return true;
   }

   @Override
   public boolean keyUp(int keycode) {
      return false;
   }

   @Override
   public boolean keyTyped(char character) {
      return false;
   }

   @Override
   public boolean touchDown(int screenX, int screenY, int pointer, int button) {
      return false;
   }

   @Override
   public boolean touchUp(int screenX, int screenY, int pointer, int button) {
      return false;
   }

   @Override
   public boolean touchDragged(int screenX, int screenY, int pointer) {
      return false;
   }

   @Override
   public boolean mouseMoved(int screenX, int screenY) {
      return false;
   }

   @Override
   public boolean scrolled(int amount) {
      return false;
   }
}

 

The sprite art used for this example was rendered using this Blender file.

The texture packing application (near the end) was CodeAndWeb’s TexturePacker.

Programming


16. December 2014

 

Sorry… absolutely can’t resist that pun, no matter how obvious it is.  Anyways… the Godot Game Engine has been on my radar since they announced they were going open source at the beginning of the year.  Today they finally announced their 1.0 release today.godot

 

 

Never heard of Godot?  It’s a Unity-esque game engine, except powered by C++ and scripted using a Python-like scripting language.  It includes a surprising number of tools and most importantly, a complete game editor (pictured right).

 

Godot works in both 2D and 3D, with 2D being a first class citizen, not just 3D minus a D.  Godot runs on Windows, OSX and Linux.  Godot is able to target iOS, Android, Desktops, Googles’ NaCL, PlayStation3 and Vita, as well as HTML5 and Windows Phone coming soon.

 

You can read the complete feature list here.

 

You can browse available documentation here.

 

Godot is an open source project hosted on GitHub.

 

What do you think… are you interested in Godot, would you be interested in seeing GameFromScratch do some more in-depth coverage now that it’s reached such a milestone release?

News


8. December 2014

 

 

In this tutorial we are going to look at how to use Cameras ( and in the next, Viewports ) in LibGDX.  I will admit, I am a bit late in covering this topic, as I should have covered it much earlier in the series.  In fact, in some prior tutorials I actually made use of Cameras with little prior discussion.  Better late than never, no?

 

The first immediate question that comes to mind are probably “What’s a camera, what’s a viewport and how are they different?”.

 

Well, basically a camera is responsible for being the players “eye” into the game world.  It’s an analogy to the way video camera’s work in the real world.  A viewport represents how what the camera sees is displayed to the viewer.  Any easy way to think about this is to think about your HD cable or satellite box and your HD TV.  The video signal comes in to your box ( this is the camera ), this is the picture that is going to be displayed.  Then your TV devices how to display the signal that comes in.  For example, the box may send you a 480i image, or a 1080p image, and it’s your TV’s responsibility to decide how it’s displayed.  This is what a viewport does… takes an incoming image and adapts it to run best on the device it’s sent to it.  Sometime this means stretching the image, or displaying black bars or possibly doing nothing at all.

 

So, simple summary description…

  • Camera – eye in the scene, determines what the player can see, used by LibGDX to render the scene.
  • Viewport – controls how the render results from the camera are displayed to the user, be it with black bars, stretched or doing nothing at all.

 

In LibGDX there are two kinds of cameras, the PerspectiveCamera and the OrthographicCamera.  Both are very big words and somewhat scary, but neither needs to be.  First and foremost, if you are working on a 2D game, there is a 99.9% change you want an Orthographic camera, while if you are working in 3D, you most likely ( but not always ) want to use a Perspective camera.

 

Now, the difference between them.  A perspective camera tries to mimic the way the human eye sees the world ( instead of how the world actually works ).  To the human eye, as something gets further away the smaller it appears.  One of the easiest ways to illustrate the effect is to fire up Blender and view a Cube in both perspectives:

 

Perspective Rendered:

image

 

Orthographic Rendered:

image

 

When dealing with 3D, a Perspective camera looks much more like we expect in the real world.  However, when you are working in 2D, you are actually still in 3D but for the most part you are ignoring depth ( except for sprite ordering ).  In a 2D game, you don’t want objects to change size the further “into the screen” they are.

 

So, TL;DR version, if you are making a 2D game, you probably want Orthographic.  If you aren’t, you probably don’t.

 

Ok, enough talk, CODE time.

 

We are going to implement a simple Orthographic camera that pans around a single image that represents our game world.  For this demo I am going to use this 2048x1024 image (click it for the full resolution, non-squished version, or make your own):

TheWorld

 

Paint skills at their finest!  Now lets look at rendering this using a camera:

package com.gamefromscratch;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.OrthographicCamera;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;

public class CameraDemo extends ApplicationAdapter {
   SpriteBatch batch;
   Texture img;
   OrthographicCamera camera;
   
   @Override
   public void create () {
      batch = new SpriteBatch();
      img = new Texture("TheWorld.png");
      camera = new OrthographicCamera(Gdx.graphics.getWidth(),Gdx.graphics.getHeight());
   }

   @Override
   public void render () {
      Gdx.gl.glClearColor(1, 0, 0, 1);
      Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

      camera.update();
      batch.setProjectionMatrix(camera.combined);
      batch.begin();
      batch.draw(img, 0, 0);
      batch.end();
   }
}

The process is quite simple.  We simply create a camera, then in our render loop we call it’s update() method then set it as the projectionMatrix of our SpriteBatch.  If you are new to 3D ( fake 2D ), the ProjectionMatrix along with the View Matrix are matrix based multiplications responsible for transforming 3D data to 2D screen space.  Camera.combined returns the camera’s view and perspective matrixes multiplied together.  Essentially this process is what positions everything from the scene to your screen.

 

Now if we go ahead and run this code we see:

image

 

Hmmmm… that may not be what you were expecting.  So what exactly happened here?

 

Well, the camera is located at the position 0,0.  However, the camera’s lens is actually at it’s center.   The red you see in the above image are the portions of the scene that have nothing in it.  So in the above example if you want to start at the bottom left of your world you actually need to take the camera’s dimensions into account.  Like so:

      camera = new OrthographicCamera(Gdx.graphics.getWidth(),Gdx.graphics.getHeight());
      camera.translate(camera.viewportWidth/2,camera.viewportHeight/2);

Now when you run it, the results are probably more along the lines you expected:

image

 

In the previous examples I actually did something you really don’t want to do in real life:

camera = new OrthographicCamera(Gdx.graphics.getWidth(),Gdx.graphics.getHeight());

 

I am setting the camera viewport to use the devices resolution, then later I am translating using pixels.  If you are working across multiple devices, this almost certainly isn’t the approach you want to take as so many different devices have different resolutions.  Instead what you normally want to do is work in world units of some form.  This is especially true if you are working with a physics engine like Box2D.

 

So, what’s a world unit?  The short answer is, whatever you want it to be!  The nice part is, regardless to what units you choose, it will behave the same across all devices with the same aspect ratio!  Aspect ration is the more important factor here.  The aspect ratio is the ratio of horizontal to vertical pixels.

 

Let’s take the above code and modify it slightly to no longer use pixel coordinates.  Instead we will define our world as 50 units wide by 25 tall.  We then are going to set our camera to be the worlds height and centered.  Finally we will hook it up so you can control the camera using arrow keys.  Let’s see the code:

package com.gamefromscratch;

import com.badlogic.gdx.ApplicationAdapter;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.Input;
import com.badlogic.gdx.InputProcessor;
import com.badlogic.gdx.graphics.GL20;
import com.badlogic.gdx.graphics.OrthographicCamera;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.Sprite;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;

public class CameraDemo2 extends ApplicationAdapter implements InputProcessor {
   SpriteBatch batch;
   Sprite theWorld;
   OrthographicCamera camera;

   final float WORLD_WIDTH = 50;
   final float WORLD_HEIGHT = 25;

   @Override
   public void create () {
      batch = new SpriteBatch();
      theWorld = new Sprite(new Texture(Gdx.files.internal("TheWorld.png")));
      theWorld.setPosition(0,0);
      theWorld.setSize(50,25);

      float aspectRatio = (float)Gdx.graphics.getHeight()/(float)Gdx.graphics.getWidth();

      camera = new OrthographicCamera(25 * aspectRatio ,25);
      camera.position.set(WORLD_WIDTH/2,WORLD_HEIGHT/2,0);

      Gdx.input.setInputProcessor(this);
   }

   @Override
   public void render () {
      Gdx.gl.glClearColor(1, 0, 0, 1);
      Gdx.gl.glClear(GL20.GL_COLOR_BUFFER_BIT);

      camera.update();
      batch.setProjectionMatrix(camera.combined);
      batch.begin();
      theWorld.draw(batch);
      batch.end();
   }

   @Override
   public boolean keyUp(int keycode) {
      return false;
   }

   @Override
   public boolean keyDown(int keycode) {
      if(keycode == Input.Keys.RIGHT)
         camera.translate(1f,0f);
      if(keycode == Input.Keys.LEFT)
         camera.translate(-1f,0f);
      if(keycode == Input.Keys.UP)
         camera.translate(0f,1f);
      if(keycode == Input.Keys.DOWN)
         camera.translate(0f,-1f);

      return false;
   }

   @Override
   public boolean keyTyped(char character) {
      return false;
   }

   @Override
   public boolean touchDown(int screenX, int screenY, int pointer, int button) {
      return false;
   }

   @Override
   public boolean touchUp(int screenX, int screenY, int pointer, int button) {
      return false;
   }

   @Override
   public boolean touchDragged(int screenX, int screenY, int pointer) {
      return false;
   }

   @Override
   public boolean mouseMoved(int screenX, int screenY) {
      return false;
   }

   @Override
   public boolean scrolled(int amount) {
      return false;
   }
}

Now when you run this code:

image

 

Now let’s look at what happens when we change our application’s resolution.  Since we aren’t using pixels anymore, the results should be fairly smooth.

 

In case you forgot, you set the resolution in the platform specific Application class.  For iOS and Android, you cannot set the resolution.  For HTML and Desktop you can.  Setting the resolution on Desktop is a matter of editing DesktopLauncher, like so:

public class DesktopLauncher {
   public static void main (String[] arg) {
      LwjglApplicationConfiguration config = new LwjglApplicationConfiguration();
      config.width = 920;
      config.height = 480;
      new LwjglApplication(new CameraDemo2(), config);
   }
}

Here is the code running at 920x480

image

 

And here is 1280x400:

image

 

As you can see, the code updates so the results render in a pixel independent way.

 

However, and as you can see above, if your aspect ratios don’t stay the same, the results look massively different.  In the previous example you can see in the 1280x400 render, the results look squished and the world contains a great deal less content.  Obviously, the values I used to illustrate this point are pretty extreme.  Let’s instead use the two most common different aspect ratios, 16:9 ( most Android devices, many consoles running at 1080p ) and 4:3 ( the iPad and SD NTSC signals ):

 

16:9 results:

image

 

4:3 results:

image

 

While much closure, the results are still going to look rather awful.  There are two ways to deal with this, both have their merits.

 

First, is create a version for each major aspect ratio.  This actually makes a great deal of sense although it can be a pain in the butt.  The final results are the best, but you double your burden for art assets.  We will talk about managing multiple resolution art assets in a different tutorial at a later date.

 

Second, you pick a native aspect ratio for your game to run at, then use a viewport to manage the different aspect ratios, just like you use the aspect button on your TV.  Since this tutorial is getting pretty long, we will cover Viewports in the next section, so stay tuned!

 

Programming


GFS On YouTube

See More Tutorials on DevGa.me!

Month List