Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon
18. October 2013

I have an HTC One that I recently replaced my Galaxy Note with and I absolutely love the phone.  That said, I ran into an interesting problem with an outright mind boggling solution.  I recently upgraded the firmware to  Android 4.3.  Today when I attempted to run an app on it, developer mode isn't enabled.  So part of the upgrade apparently turned it off.  Then I went into the settings and… no developer option.

To enable the developer menu option, go in to settings and select:

About->Software Information->More.

Now click Build number 7 times.  After tapping a few times, you will get a notice.

SS1

 

After you do this, the developer menu will now be shown:

Screenshot 2013 10 18 10 34 45

 

Very odd experience.


17. October 2013

 

A few hours back I received the following email from Havok:

 

Calling all game developers!

 

PROJECT ANARCHY MOBILE GAME DEVELOPMENT CHALLENGE

Whether your studio is in an office building or a garage, we know you’ve had an idea bubbling in the back of your mind to create the next big hit on mobile! Now is your chance to wrangle your team, warm up your machines, and get your hands on some of the industry’s top middleware for video game development and a chance to win $100,000!

  • Download our FREE mobile game engine and get started developing the game that could win you up to $100,000 in prizes!
  • EARLY SUBMISSION deadline is Feb 1, 2014 that gives you an opportunity to get feedback from Havok's world class developer support team. These are the same guys that helped perfect Assassin's Creed IV, Halo 4, Uncharted 3, and Skyrim. They can help push the limits of what your game can do with the power of Project Anarchy
  • FINAL SUBMISSION deadline is May 31, 2014.

 

There are absolutely no revenue restrictions to develop your games with Project Anarchy. What are you waiting for? Get started at www.projectanarchy.com/contest and start making some games! Check us out on our social media outlets (below) and share with your friends!

 


Project Anarchy is some really cool tech and is a great option if you want to make a mobile game ( oh yeah… and it’s free ).  If you are new to Project Anarchy, you can get an overview right here.  I’ve actually done a tutorial series you can read right here.

 

To be honest, I kind of put the series on the back burner because Project Anarchy wasn’t as popular as I expected it to be (the traffic just wasn’t there), which is a shame, it was fun to write and PA is incredibly powerful.  Hopefully this contest will help in that regard.  If so, expect to see more tutorials here in the near future!

 

If you haven't already, you really should check out Project Anarchy.

News


17. October 2013

At their developer event today in Montreal, nVidia released a series of new developer tools.

 

The first one is FLEX which is an extension to the PhysX um… physics engine.  It is "a unified GPU physics simulation tool that allows two way coupling of effects".  For example with Flex, a particle simulation could accurately interact with a fluid body simulation.

 

Here is a video of Flex in action:

 

They also introduced GI Works, a real time solution for global illumination for doing accurate lighting in games.

 

Big nvidia lighting 2

(Image from hothardware.com)

 

Finally they announced Flame Works, a volumetric engine for implementing film quality fire and smoke effects in games.  nVidia announce they are already working to get the technology implemented in existing game engines.

Here is the Flame Works demo:

You can read more about the new tools on hot hardware.com.


15. October 2013

 

In this part we are going to look at how you handle mouse and keyboard input in LibGDX.  There are two ways to go about handling input, by polling for it ( as in… “Has anything happened yet? No, ok…  What about now? No, ok… Now?  Yes!  Handle it” ) or by handling events ( “Hey, you, I’v got this event for you!” ).  Which you go with generally depends on the way you structure your code.  Polling tends to be a bit more resource intensive but at the end of the day that is mostly a non-factor.

 

Polling the keyboard for input

 

Let’s jump right in and look at how you poll the keyboard for input.  Here is the code:

package input.gamefromscratch.com;

import com.badlogic.gdx.ApplicationListener;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.Input;
import com.badlogic.gdx.graphics.GL10;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.Sprite;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;

public class InputDemo implements ApplicationListener {
    private SpriteBatch batch;
    private Texture texture;
    private Sprite sprite;
    
    @Override
    public void create() {        
        float w = Gdx.graphics.getWidth();
        float h = Gdx.graphics.getHeight();
        batch = new SpriteBatch();
        
        texture = new Texture(Gdx.files.internal("data/0001.png"));
        sprite = new Sprite(texture);
        sprite.setPosition(w/2 -sprite.getWidth()/2, h/2 - sprite.getHeight()/2);
    }

    @Override
    public void dispose() {
        batch.dispose();
        texture.dispose();
    }

    @Override
    public void render() {        
        Gdx.gl.glClearColor(1, 1, 1, 1);
        Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
        
        if(Gdx.input.isKeyPressed(Input.Keys.LEFT)){
            if(Gdx.input.isKeyPressed(Input.Keys.CONTROL_LEFT))
                sprite.translateX(-1f);
            else
                sprite.translateX(-10.0f);
        }
        if(Gdx.input.isKeyPressed(Input.Keys.RIGHT)){
            if(Gdx.input.isKeyPressed(Input.Keys.CONTROL_LEFT))
                sprite.translateX(1f);
            else
                sprite.translateX(10.0f);
        }
        batch.begin();
        sprite.draw(batch);
        batch.end();
    }

    @Override
    public void resize(int width, int height) {
    }

    @Override
    public void pause() {
    }

    @Override
    public void resume() {
    }
}

 

Other than the highlighted bit and the translateX method, everything here we have seen before.  Basically we draw a simple sprite centered to the screen and each frame we check to see if the user has pressed the LEFT or RIGHT arrow.  If they have, we check if they also have the left control key held.  If so, we move slowly to the left or right.  If they don’t have Control pressed, we move instead by 10 pixels.

 

Here is the app, you need to click it first to give it keyboard focus:

 

If it doesn’t work in an frame, click here.

Just use the left and right arrows to move the jet. Hold down control to move slowly.  There is no clipping so the sprite can fly way off screen.

 

In terms of what the new code is doing, the Sprite.translateX method is pretty self explanatory.  It moves the sprite by a certain amount of pixels along the X axis.  There is a translateY method as well, as well as a more general translate method.  The key method in this example is isKeyPressed() member function of the input instance of the global Gdx object.  We used a similar instance member when we accessed Gdx.files.  These are public static references to the various sub-systems GDX depends on, you can read more here.  isKeyPressed is passed a Key value defined in the Keys object and returns true if that key is currently pressed.  As you can see when we later tested if the Control key is also pressed, multiple keys can be pressed at the same time.

 

Polling the Mouse for input

 

Now let’s take a look at how you poll the mouse for input.  To save space, this code is identical to the last example, with only the render() method replaced.

public void render() {        
    Gdx.gl.glClearColor(1, 1, 1, 1);
    Gdx.gl.glClear(GL10.GL_COLOR_BUFFER_BIT);
    
    if(Gdx.input.isButtonPressed(Input.Buttons.LEFT)){
        sprite.setPosition(Gdx.input.getX() - sprite.getWidth()/2,
                Gdx.graphics.getHeight() - Gdx.input.getY() - sprite.getHeight()/2);
    }
    if(Gdx.input.isButtonPressed(Input.Buttons.RIGHT)){
        sprite.setPosition(Gdx.graphics.getWidth()/2 -sprite.getWidth()/2, 
                Gdx.graphics.getHeight()/2 - sprite.getHeight()/2);
    }
    batch.begin();
    sprite.draw(batch);
    batch.end();
}

 

Here we instead are checking if a mouse button has been pressed using isButtonPressed passing in a button value defined in the Buttons object.  If the left button is pressed, get then poll the mouse position using Gdx.input.getX() and Gdx.input.getY() and set the sprites location to that position.  The math may look a bit overly complicated, why didn’t we simply set the location to the values returned by getX/Y?  There are two reasons.  First, our sprites coordinate is relative to it’s bottom left corner. so if we want to center the sprite, we need to take half the sprites width and height into consideration.  The next complication comes from the fact that LibGDX sets the origin at the bottom left corner, but mouse positions are relative to the top left corner.  Simply subtracting the position from the screen height gives you the location of the mouse in screen coordinates.  We also check to see if the user as hit the right mouse button, and if they have we reposition the jet sprite at the center of the window.

 

If it doesn’t work in an frame, click here.

Once again, you need to click within above before it will start receiving mouse events ( depending on your browser ).  Left click and the sprite should move to the location you clicked.  Right click to return to default ( in theory… ), right click behaviour is a bit random in web browsers.

 

Event driven keyboard and mouse handling

 

Now we will look at handling the functionality of both of the above examples ( as a single example ), but this time using an event driven approach.

package input.gamefromscratch.com;

import com.badlogic.gdx.ApplicationListener;
import com.badlogic.gdx.Gdx;
import com.badlogic.gdx.Input.Buttons;
import com.badlogic.gdx.Input.Keys;
import com.badlogic.gdx.InputProcessor;
import com.badlogic.gdx.graphics.GL10;
import com.badlogic.gdx.graphics.Texture;
import com.badlogic.gdx.graphics.g2d.Sprite;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;

public class InputDemo implements ApplicationListener, InputProcessor {
    private SpriteBatch batch;
    private Texture texture;
    private Sprite sprite;
    private float posX, posY;
    
    @Override
    public void create() {        
        float w = Gdx.graphics.getWidth();
        float h = Gdx.graphics.getHeight();
        batch = new SpriteBatch();
        
        texture = new Texture(Gdx.files.internal("data/0001.png"));
        sprite = new Sprite(texture);
        posX = w/2 - sprite.getWidth()/2;
        posY = h/2 - sprite.getHeight()/2;
        sprite.setPosition(posX,posY);
        
        Gdx.input.setInputProcessor(this);
    }

    @Override
    public void dispose() {
        batch.dispose();
        texture.dispose();
    }

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

        sprite.setPosition(posX,posY);
        batch.begin();
        sprite.draw(batch);
        batch.end();
    }

    @Override
    public void resize(int width, int height) {
    }

    @Override
    public void pause() {
    }

    @Override
    public void resume() {
    }

    @Override
    public boolean keyDown(int keycode) {
        float moveAmount = 1.0f;
        if(Gdx.input.isKeyPressed(Keys.CONTROL_LEFT))
            moveAmount = 10.0f;
        
        if(keycode == Keys.LEFT)
            posX-=moveAmount;
        if(keycode == Keys.RIGHT)
            posX+=moveAmount;
        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) {
        if(button == Buttons.LEFT){
            posX = screenX - sprite.getWidth()/2;
            posY = Gdx.graphics.getHeight() - screenY - sprite.getHeight()/2;
        }
        if(button == Buttons.RIGHT){
            posX = Gdx.graphics.getWidth()/2 - sprite.getWidth()/2;
            posY = Gdx.graphics.getHeight()/2 - sprite.getHeight()/2;
        }
        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;
    }
}

 

And here it is running:

If it doesn’t work in an frame, click here.

 

The code is structured quite a bit differently from when we polled for input.  The most immediate thing to be aware of is our class declaration:

public class InputDemo implements ApplicationListener, InputProcessor {

 

We are implementing another interface, InputProcessor, which as you can see adds a number of overrides to our code.  The most important ones we are dealing with here are keyDown and touchDown.  Touch you say?  Yeah, LibGDX treats the mouse and touch input as the same thing.  We will look at this in a bit more detail later on.  In addition to implementing the various methods of our interface, we also need to register our InputProcessor with the global input instance, this is done here:

Gdx.input.setInputProcessor(this);

 

At this point, our various event handlers will now be called whenever an event occurs.  keyDown will be fired when a key is pressed ( while keyUp is fired when it is released, and keyTyped is fired after it has been fired and released ).  The parameter is the value of the key pressed.  Once again, these values are available in the Keys object.  One thing you may have noticed is that we still poll to see if the Control key is pressed.  The alternative would be to set a flag when the control key is pressed and clear it when it is released.  It is important to realize that a keyDown event will be fired for each individual key fired, so if you want to handle multiple simutanious key presses, this may not be the best way to approach the subject.  Another thing you might notice is that you have to hit the key multiple times to move.  This is because a key press generates only a single event ( as does it’s release ).  If you want to have the old behavior that holding down the key will move the character continously, you will need to implement the logic yourself.  Once again, this can simply be done by setting a flag in your code on keyDown and toggle it when the keyUp event is called.

 

The touchDown event on the other hand is much more straight forward.  It can be a bit confusing handling “mouse” events called “touches”, but it makes sense.  Generally the logic you handle for both would be exactly the same, so no sense treating them differently.  The parameters passed in to touchDown are the x and y coordinates of the touch/click location, the pointer and button clicked.  On a mobile device the Button value will always be Buttons.LEFT.  Once again, screen coordinates and image coordiantes arent the same, so we need to deal with that in our positioning.  Notice how I glossed over just what exactly pointer is?  Well, pointer is a bit oddly named in my opinion.  TouchIndex would probably have made more sense, especially with pointer having a pair of very well defined meanings already.  The pointer value is value between 0 and n ( defined as 20 in LibGDX, in reality much lower ) that represents the ORDER in which the touch event occurred in the event of multiple simultaneous touches.  Therefore if you have multiple fingers touching, a pointer value of 0 would indicate that this touch event represents the first finger to touch the screen, while a value of 3 would be the fourth finger to touch the screen.  Dont worry, we will talk about this later when we deal specifically with touch.

Programming


7. October 2013

 

On thing i’ve discovered working with GWT these past few weeks is, it’s slow… very very very slow.  I am developing on a newer laptop running a Haswell processor and SSD and my compilation times look like this:

image

 

254 seconds per compile is simply not tenable, especially during development.  You can avoid a compilation by working in DevMode, but this is exceedingly fragile at times.  As a result, I wanted to look into a way of speeding the process up.  Fortunately it’s a fairly simple process in the end.

 

The first culprit is the “Compiling permutation X” bit.  By default it is going to compile a version for every supported browser.  For release this is obviously advantageous, but during development it is bringing compile times to a crawl.  Fortunately, you only really need to develop for whatever browser you are testing in.  If you are working with a LibGDX project locate the file GwtDefinition.gwt.xml in the –html project.  There is one in the base project too, but that is not the file you are looking for.  It should look like this:

image

 

Edit that file to look like this:

 

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE module PUBLIC "-//Google Inc.//DTD Google Web Toolkit trunk//EN" 
    "http://google-web-toolkit.googlecode.com/svn/trunk/distro-source/core/src/gwt-module.dtd">
<module>
    <inherits name='com.badlogic.gdx.backends.gdx_backends_gwt' />
    <inherits name='InputDemo' />
    <entry-point class='input.gamefromscratch.com.client.GwtLauncher' />
    <set-configuration-property name="gdx.assetpath" value="../input-android/assets" />
    <set-property name="user.agent" value="safari"/>
</module>

 

The line highlighted in yellow is the one you are interested in.  Basically you provide an entry for each browser you want GWT to compile for.  In my case I am working in Chrome which (oddly enough) doesn’t have it’s own user agent ( in the form value=”safari,ie9,other_values_here” ).  As Safari and Chrome have a common ancestor in Webkit, this user agent works.  You can also specify values for FireFox ( gecko ) and IE.  By building for just a single browser, we see a massive speedup.  In my after making the above change:

image

 

Down to 53 seconds… much better, but still far to long in my humble opinion.

 

Then one other idea struck me… I’m running a 32bit version of the JDK ( because so many tools still don’t play well with JDK7, FlashDevelop being the biggest ), so after a great deal of effort, I got and configured a 64 bit JDK and version of Eclipse.  Coincidentally, Eclipse really doesn’t seem to like sharing a workspace between 32 and 64bit installs!  Once I eventually got it working ( an hour and a half later… oh Eclipse, I so hate you ), I ran the GWT compiler again:

 

 image

 

31.5 seconds, almost a halving in development time.  So either Java 7, 64bit or possibly both resulted in a large decrease in compile time.

 

There is one final optimization I found, which is ironically to not optimize.  Just like with C++ compilers, you can create and optimized and unoptimized build.  By default GWT performs a great deal of optimization and during development, this is probably a waste.  Fortunately it can easily be disabled.  When you run a GWT compile, in the options window you can pass an additional parameter, –draftCompile.  It is available under the Advanced tab:

image

 

And the result:

image

17 seconds!  Much much much better!  Coincidentally, playing around with the memory amount available made little to no difference.  I actually experienced slightly slower compilation time when I increased it to 2G ( of 8 available on my machine ).  Obviously the less optimized version is going to run slower, but it shouldn’t be by a huge margin.

 

Remember though, when building for release, you want to re-enable all of these settings!  But for day to day development, 17 seconds is a heck of a lot better than 254s!

Programming


See More Tutorials on DevGa.me!

Month List