Subscribe to GameFromScratch on YouTube Support GameFromScratch on Patreon

23. November 2015

 

At the Android Developer Summit, Google just announced Android Studio 2.0 is available for download in preview form.  The two major new features will both be relevant for game developers, Instant Run which enables hot swapping of code on device and a GPU profiler, for profiling OpenGL ES code performance.

 

From the Android Developers blog:

Android Studio 2.0 Preview

Posted by, Jamal Eason, Product Manager, Android

One the most requested features we receive is to make app builds and deployment faster in Android Studio. Today at theAndroid Developer Summit, we’re announcing a preview of Android Studio 2.0 featuring Instant Run that will dramatically improve your development workflow. With Android Studio 2.0, we are also including a preview of a new GPU Profiler.

All these updates are available now in the canary release channel, so we can get your feedback. Since this initial release is a preview, you may want to download and run an additional copy of Android Studio in parallel with your current version.

New Features in Android Studio 2.0
Instant Run: Faster Build & Deploy

Android Studio’s instant run feature allows you to to quickly see your changes running on your device or emulator.

Getting started is easy. If you create a new project with Android Studio 2.0 then your projects are already setup. If you have a pre-existing app open Settings/Preferences, the go to Build, Execution, Deployment → Instant Run. Click on Enable Instant Run... This will ensure you have the correct gradle plugin for your project to work with Instant Run.

Enable Instant Run for Android Studio projects

Select Run as normal and Android Studio will perform normal compilation, packaging and install steps and run your app on your device or emulator. After you make edits to your source code or resources, pressing Run again will deploy your changes directly into the running app.

New Run & Stop Actions in Android Studio for Instant Run

For a more detailed guide setup and try Instant Run, click here.

GPU Profiler

Profiling your OpenGL ES Android code is now even easier with the GPU Profiler in Android Studio. The tool is in early preview, but is very powerful and not only shows details about the GL State and Commands, you can record entire sessions and walk through the GL Framebuffer and Textures as your app is running OpenGL ES Code.

Android Studio GPU Profiler

To get started, first download the GPU Debugging Tools package from the Android Studio SDK Manager. Click here for more details about the GPU Profiler tool and how to set up your Android app project for profiling.

Whats Next

This is just a taste of some of the bigger updates in this latest release of Android Studio. We'll be going through the full release in more detail at the Android Developer Summit (livestreamed on Monday and Tuesday). Over the next few weeks, we'll be showing how to take advantage of even more features in Android Studio 2.0, so be sure to check back in.

If you're interested in more Android deep technical content, we will be streaming over 16 hours of content from the inaugural Android Developer Summit over the next two days, and together with Codelabs, all of this content will be available online after the Summit concludes.

Android Studio 2.0 is available today on the Android Studio canary channel. Let us know what you think of these new features by connecting with the Android Studio development team on Google+.

 

I wonder how much of this functionality will be made available upstream to the IntelliJ IDE? 

GameDev News ,

23. October 2015

 

In a past life in which I sat in a cubicle and someone actually gave me a pay check every week I was a huge fan of Xamarin products.  They do very a good job of enabling .NET developers to leverage their skill across many platforms.  In fact, they are the technology that Unity is built on top off.  That said, I became increasingly less of a fan when the checks stopped and expenses came out of my own pocket!

 

There are many people out there that view making money from software as somehow evil.  I am certainly not one of those people.  In that corporate environment, where developers are paid salaries, rent is paid for office space, taxes are paid, etc…  the price of a software tool like Xamarin is trivial to justify.  In the world of indie game development though, this is often simply not the case.

 

Thing is, Xamarin has become a necessary evil for so many C# based game engines ( MonoGame, WaveEngine, Duality, Paradox, etc ) if you want to port to iOS or Android.  Many of these developers will never see a dime from their efforts, while a select few will become massively rich and a certain middle ground will eek out a living doing what they love.  It’s the later two groups that keep companies like Unity and Unreal afloat, and those two groups don’t come into being without the former group.

 

The challenge with Xamarin has always been their license structure has always been pretty awful for amateur developers.  How many people have chosenn not to work in C# simply because their is a price tag attached?  After years of awaiting a newer friendlier license structure (or Microsoft buyout), hope is on the horizon.

 

Today, in response to Xamarin’s recent acquisition of RoboVM, I ended up in this Twitter conversation with Nat Friedman, CEO of Xamarin:

 

First, in regard to the acquisition of RoboVM and how long the free for LibGDX developers offer will be extended:

image

 

Then more on the indie friendly nature of Xamarin, or lack thereof:

image

(Portion excerpted, Twitter message threading is bizarre)

image

image

 

This is news I am certain many C# game developers and tool providers are going to be delighted to hear.  Hopefully something happens fairly soon, as I’ve been waiting about 6 years and counting at this point! ;)

Programming, News , ,

31. August 2015

 

In this Closer Look At we look at take a look at the jMonkeyEngine.  The Closer Look At game engine series is a cross between an overview, a review and a getting started tutorial to help you decide if a game engine is the right fit for you.  The jMonkeyEngine engine is a Java based, open sourced, cross platform 3djMonkeyCloserLook_450px game engine that runs on most Java supported platforms and can target Windows, Linux, Mac and Android, with iOS and Oculus VR support currently being tested.  jMonkeyEngine is available as both a game library, or as a set of tools built on top of the NetBeans IDE.  For this closer look, we will focus on the full SDK experience.

 

 

This closer look is also available in HD video format here.

 

 

Although we are going to focus on the complete set of tools including in the jMonkeyEngine SDK, keep in mind it can be used in library form if you prefer working in Eclipse or IntelliJ.  You will however lose access to some very convenient tools.

 

 

Meet jMonkeyEngine

 

As I mentioned earlier, jMonkeyEngine ships in two forms, as a set of libraries, or as a complete SDK build on top of the Netbeans IDE.  You can download load the SDK for Windows, Mac or Linux right here.  As of writing, 3.0 is the current released version, while 3.1 is available in development on Github.  This version marks the first public release using the Github platform.  jMonkeyEngine has a few prerequisites before installing, but they basically boil down to having an OpenGL 2 compatible video card and JDK 6 or higher installed.

 

Once downloaded and installed simply run the jMonkeyEngine SDK application.   This is jMonkeyEngine:

image

 

As mentioned earlier, this is actually a preconfigured version of the Netbeans IDE with a set of plugins and extensions to support jMonkeyEngine development.  This means in addition to the various jME tools you get a complete modern Java development environment, meaning code completion, project management, refactoring tools, debugging and more.  I won’t be specifically covering Netbeans functionality in this guide.  If you’ve got prior experience in Eclipse or IntelliJ, you should feel right at home.  Personally I rate the Netbeans experience somewhere between the two, with IntelliJ being quite a bit better, while Eclipse is many many many times worse.  That all said, that is purely opinion, each platform has it’s strength and weakness, it’s fans and haters.  If you prefer to use Eclipse or IntelliJ you can.

 

Hello jMonkeyEngine

 

It is often easiest to start with a simple project, so let’s do exactly that.  Select File->New Project

image

 

A New Project wizard will appear.  All of the standard project types supported by Netbeans are available, but also the new jMonkeyEngine templates are available too.  Select BasicGame and click Next.

image

 

Pick a name and location and click Finish.

image

 

Your project will now be created.  You can have several projects open in the IDE at the same time, just be sure to select the right one in the Projects panel:

image

 

The wizard will have automatically created a project hierarchy for you:

image

 

It’s optional to use this layout, but you are making life more difficult for yourself if you do not.  File paths for textures in imported models are absolute, forcing your hand somewhat in how you import your data.  Again, you can code around this design, but you are making your life more complicated.  For the most part I found the layout fairly logical, but the suggestion to import your models into the Textures folder then relocating them to Models ( well discuss this more later ), well that simply a gross kludge.

 

The New Project wizard also generated a default source file for us, Main.java, with the following contents:

 

package mygame;

import com.jme3.app.SimpleApplication;
import com.jme3.material.Material;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Vector3f;
import com.jme3.renderer.RenderManager;
import com.jme3.scene.Geometry;
import com.jme3.scene.shape.Box;

/**
 * test
 * @author normenhansen
 */
public class Main extends SimpleApplication {

    public static void main(String[] args) {
        Main app = new Main();
        app.start();
    }

    @Override
    public void simpleInitApp() {
        Box b = new Box(1, 1, 1);
        Geometry geom = new Geometry("Box", b);

        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        mat.setColor("Color", ColorRGBA.Blue);
        geom.setMaterial(mat);

        rootNode.attachChild(geom);
    }

    @Override
    public void simpleUpdate(float tpf) {
        //TODO: add update code
    }

    @Override
    public void simpleRender(RenderManager rm) {
        //TODO: add render code
    }
}

The code is all pretty straight forward.  You game code extends the class SimpleApplication, which in turn implements Application plus implements some “out of the box” behaviour like key mappings for exiting the application and implementing a camera.  These default behaviours can easily be overridden as we will see shortly.  SimpleApplication exposes three critical methods as part of your games life cycle, simpleInitApp(), called when your app is created, then simpleUpdate() and simpleRender() called over and over by the game event loop.  Basically stick your setup code in the init() method, your update code in the update() method and drawing code in the render() method.  If these methods start getting overly complex, you can refactor your design to use States, something we will cover later on.

 

You can run or debug your project using the toolbar:

image

 

Or via the Run menu:

image

 

Once launched you will see a configuration Window.

image

 

Select your preferred configuration and click Continue.  You may be asking, can I get rid of this damned window?  The answer is yes you can, but you have to use code to do it.  I can’t really fathom why there isn’t a “Remember my settings” check box.  Once you click Continue, your first app will run.

FirstApp

 

As you move the mouse cursor around, the camera implemented in SimpleApplication is moving the camera position around.  You may also notice the debug details and of course that startup window.  As said earlier, this can all be override, let’s look at how.

First we can get rid of the configuration window ( which I admit, gets old very quickly ) and set a default resolution using the following code:

    public static void main(String[] args) {
        Main app = new Main();
        
        // Dont show window
        app.showSettings = false;
        
        // Create a new app settings loaded with defaults
        AppSettings appSettings = new AppSettings(true);
        
        // Override resolution
        appSettings.put("Width",720);
        appSettings.put("Height",480);
        
        // Add a title, just because
        appSettings.put("Title", "Super Awesome Megagame 9000!");
        
        app.setSettings(appSettings);
        app.start();
    }

 

Next in our init we add the following logic to disable the camera and debug info. These need to be called after app.start(), thus why they are in init.

    @Override
    public void simpleInitApp() {
                
        // Disable fly cam
        this.flyCam.setEnabled(false);
        
        // Turn off debug info and FPS window
        this.setDisplayFps(false);
        this.setDisplayStatView(false);
        
        Box b = new Box(1, 1, 1);
        Geometry geom = new Geometry("Box", b);

        Material mat = new Material(assetManager, "Common/MatDefs/Misc/Unshaded.j3md");
        mat.setColor("Color", ColorRGBA.Blue);
        geom.setMaterial(mat);

        rootNode.attachChild(geom);
    }

 

Now when you run your game, you should no longer see the config window, nor display stats when running.  Instead you should see:

image

 

Importing a 3D Model

 

One of the first things I do when testing a new engine is check to see how hard it is to get a 3D model imported.  In jMonkeyEngine you have a couple of options, you can import to their native format, use a Blender plugin, support an OBJ file, or import files converted using the Ogre XML toolchain, which is also available as a Blender plugin as well as several other packages.

 

I will use the native format (j3o) later, for now, let’s look at the process of importing a Blender model, since jMonkeyEngine has solid Blender integration built in.  In fact, jMonkeyEngine actually ships with a copy of Blender as part of the SDK install, currently version 2.69 (as of writing, 2.75 is the most current version).  When you run Blender from within jMonkeyEngine, this included version is the one that is run.  (Note, for performance, you should always prefer using the native binary format unless you have a very good reason not to).

 

You can add a new textured Blender cube (you don’t have to by the way), right click the desired location and select File->New->Other…

image

 

Then select Blender->Box prepared for UV texturing.

image

 

Name it and confirm the location, then click Finish.

image

 

This will run a copy of Blender and set up a cube with textures defined for you.

image

 

What’s extremely odd here is the configured cube isn’t actually ready to go.  You still need to UV unwrap the cube, attach a texture and set the UVmap.   You can see the entire process in the video if you need more details.

 

You can confirm that the blend file works fine, right click the blend and select View Model.

image

 

This will open the Viewer.

image

Be sure to click the light icon (top left) to enable lighting in the viewer.  Now that we know the Blender file works, let’s move over to the code to load a Blender file.  there is a bit of a challenge first, Blender support is actually added as a plugin, we need to add it in first.

 

Right click Libraries and select Add Library…

image

 

Select jme3-libraries-blender then click Add Library.

image

 

We need to add a light to the scene or the model isn’t going to show up.  Simply drag and drop SunLight from to the drop of the simpleInitApp() code and it will drop all the code we need.

image

package mygame;

import com.jme3.app.SimpleApplication;
import com.jme3.light.DirectionalLight;
import com.jme3.math.ColorRGBA;
import com.jme3.math.Vector3f;
import com.jme3.renderer.RenderManager;
import com.jme3.scene.Spatial;

public class Main extends SimpleApplication {

    public static void main(String[] args) {
        Main app = new Main();
        app.start();
    }

    @Override
    public void simpleInitApp() {
        /** A white, directional light source */ 
        DirectionalLight sun = new DirectionalLight();
        sun.setDirection((new Vector3f(-0.5f, -0.5f, -0.5f)).normalizeLocal());
        sun.setColor(ColorRGBA.White);
        rootNode.addLight(sun); 
        Spatial blenderModel = assetManager.loadModel("Models/demoBox.blend");
        rootNode.attachChild(blenderModel);
    }

    @Override
    public void simpleUpdate(float tpf) {
        //TODO: add update code
    }

    @Override
    public void simpleRender(RenderManager rm) {
        //TODO: add render code
    }
}

And run it:

image

 

So other than Blender configuration, getting a model into a jMonkeyEngine app is fairly straight forward.

 

Tools in jMonkeyEngine

 

Code Palette

We briefly saw the Palette in action in the previous example.

image

This is a selection of code snippets you can drag and drop into the editor.  One major gotcha however, many of these samples depend on a library, jme3-test-data, that isn’t included by default oddly enough.  We saw earlier when we set up the Blender plugin the process of adding a library.

 

3D File Importer

While jMonkeyEngine supports the Ogre XML format and Blend files, working with a game oriented file format is almost always the best performing option.  Fortunately jMonkeyEngine provides just such a format, j3o.  These files can be created easily using the menu File->Import Model menu:

image

 

Then select the model

image

 

Material/Shader Editor

You can easily create shaders right clicking an Asset folder such as Materials, New->Other…

image

 

Then Material->Empty Material file

image

 

You can then define a shader using a UI tool.  You can also set a template that other materials inherit from.

image

 

3D Scene Composer

image

 

The Scene Composer can be use to assemble and create 3D scenes.  There is also a corresponding scene graph:

image

 

A variety of game nodes can be created here:

image

 

Terrain Editor

In addition to the Scene Composer, there is also a 3d terrain tool:

image

You can create terrain visually.  Easily pull and push terrain into shape, paint with multiple textures.  The generated terrain can be used in the scene composer.

terrain

 

Engine Capabilities

 

We only briefly touched upon the code capabilities of the jMonkeyEngine due to time and space restraints.  jMonkeyEngine is a full functioning engine with the following functionality, excerpted from their website.

image

 

Documentation and Community

jMonkeyEngine is well documented, with a comprehensive collection of tutorials and guides available on the wiki.  I encountered a few entries that were out of date or invalid, but for the most part the document was solid and easy to follow.  There is also a good reference in the form of the JavaDoc.  I may not always be the biggest Java fan, but I almost always love JavaDoc generated references!

Until recently the forums for jMonkeyEngine were pretty terrible, but thankfully they’ve recently transitioned to an improved forum.  There is an active community and questions rarely go unanswered.  They have also recently transitioned the source code to Github.

 

Books

 

There are two books available for jMonkeyEngine.

jm1jm2

 

 

The Video

 

Programming , , ,

21. August 2015

Today marks the official release of jMonkeyEngine 3.1 alpha. Generally I wouldn't make a news post over a minor alpha release but a) jme has been pretty quite lately b) I'm currently looking at this engine right now c) it's a pretty massive release.

In addition to underlying changes like a move to github, transition from ant to gradle build systems and implementation of a commenting system that isnt from the 90s, there are some pretty huge new features, such as iOS support, FBX importing, VR support, render optimizations and much more.

 

The full release notes follow:

 

At long last, we have our first alpha release for the jMonkeyEngine 3.1 SDK.

Go get it on GitHub and start breaking things.

Not only does this release mark the introduction of some absolutely game-changing features (or shall we say, abbreviations: iOS, FBX, VR!); it also marks a significant step forward in jME’s underlying infrastructure. In the following weeks, we will explain each and every one of these changes in depth.

All the same bits, structured differently

  • First, we switched from using Google Code (SVN) to GitHub (Git) for
    our source code repository.
  • And then, as if that wasn’t enough, we went from using ANT
    for our build system to using Gradle.
  • We also migrated our forum to the ever more awesome Discourse, which was followed by a series of website updates, with more to come.

These structural changes will allow us to do our work more effectively, and with the combined power of GitHub and Discourse, we’re already seeing a big uptake in contributions and overall user participation.

Unified Renderer Architecture

Previously, there would be a Renderer implementation for each platform that jME3 supported, but all of these platforms supported OpenGL, so in the end, this led to a lot of code duplication. Each time we wanted to add a new renderer feature, all existing renderer implementations had to be modified in the same way.

The new unified renderer architecture means there’s only 1 Renderer implementation, “GLRenderer”, which then calls into GL interfaces implemented by each back-end – this is much easier to maintain. It means easier modification of renderer internals, including performance improvements, as well as the ability to add really advanced features to the renderer that wasn’t possible before. As a consequence, the OpenGL 1 renderer is now out, nobody will ever miss it and (probably) nobody used it for anything. There were some other changes around the rendering pipeline, reduce useless work and improve performance.

OpenGL 3 Core Profile Support

This is a significant improvement especially on Mac OS X and Linux where using the Core Profile actually allows more features to be used than otherwise. Do note that many jME3 shaders don’t support GLSL 1.5 which is required on some platforms when using OpenGL Core Profile – this is being worked on …

Geometry / Tesselation Shader Support

Added support for specifying geometry and tessellation shaders in the material definition. Note that this requires hardware capable of running such shaders. This feature is not used in the engine itself for any capability.

Scene Graph Optimizations

Previously, the engine would need to recurse into the scene graph 3 times every frame, even if nothing was changed! This has been improved so only the branches of the scene graph that require updating or rendering are actually walked into. This equals big performance boost for mostly static and large scenes. The only kind of scenes that don’t benefit from this are scenes where all objects and lights are constantly moving and the entire scene is visible in the camera the whole time. Those kinds of scenes are very rare!

In addition, hardware skinning is now enabled by default, which means a big speed boost when there are many animated models on screen.

Lighting Boost

Remy “nehon” already made a post about this which you can read here. With both single pass lighting and light culling you can now expect big performance improvements in large scenes with many lights. – When rendering shadows for lights, only casters that are inside the light’s area of influence are rendered.

FBX Importer (Beta!)

There’s a beta quality FBX importer currently in development. Unfortunately skeletal animation is not supported yet, but once it is finished, it should replace the semi-functional OgreXML support and hopefully be on par with the .blend importer.

Geometry Instancing

If you want to render a certain (complex) model many times in different places. E.g. a forest or asteroid field, you can use InstancedNode (requires OpenGL3 and higher support!)

Rewritten Audio Streaming

If you were using audio streams before, you might have noticed that they have quite a lot of limitations. They cannot be looped, reset, or stopped without the audio stream becoming useless. The new changes mean you can now stop, loop, or reset audio streams with ease. Also, updates about audio finishing playing now occur every frame instead of every 50 milliseconds (e.g. if you were relying on it for any events & such)

Further, there’s a new capability to determine current playback position of an audio source. Can be used to synchronize events or video to an audio stream.

Networking Improvements

HostedServices: Essentially like AppStates, but independent of jME3 Application infrastructure.

Gamma-correct lighting and high dynamic range rendering

Gamma-correct lighting – basically means lighting looks better or more realistic, or both. Oh, and if you’re planning on using this, you better make sure its always on because your scene will look different depending on if its on or off. While at it, you can also use the new tonemap filter for HDR rendering. The tonemap algorithm is based on a filmic curve from Uncharted 2.

Profiling Frame Times

With the app profiler state, you can see how long each part of a frame takes, e.g. rendering or updates, thus allowing you to detect stuttering parts in the game and optimize them.

iOS Improvements

  • Now iOS support is mostly stable (but still behind Android support). More testing is needed.
  • Texture loading issue fixed.
  • Audio support now enabled.

Android Bugfixes & Improvements

  • Texture decoding is now handled by C++ code so loading time is now much shorter. This also means the terrain alphamap issue is fixed. Previously you had to flip the alpha channel to use terrain on Android, this is no longer required.
  • OGG/Vorbis audio decoding is now handled by C++ code. This allows using the native OpenAL Soft audio library to handle audio instead of the Android built-in MediaPlayer, hence 3D audio, doppler effects, and reverb is now supported.
  • Support for Android Fragments (on Android 4.0+)
  • Added support for joysticks. For example, you can connect your Xbox 360 controller to your Android tablet and it will show up as an actual joystick in jME.

Blender Importer

  • Improved support for models animated with IK (inverse kinematics)
  • Support for loading linked .blend files

SDK Editor Improvements

dark_monkey

  • Enhanced shader node editor with many issues fixed.
  • 3D Scale / Rotate Tool.
  • New “DarkMonkey” theme which matches the forum theme (you have to enable it manually under the Look and Feel settings)

Bullet Physics

  • Added capability to change number of solver iterations – aka “physics accuracy”.
  • Added support native sweep test (previously was unimplemented)
  • Fixes to native ray test (previously was broken / crashing)
  • Allow 3D vector linear and angular factor instead of just a scalar factor

Misc Engine

  • Print out current build branch / tag / revision / hash in log

Misc Bugfixes

  • Fix inconsistent mouse coordinate origin on AWT panels
  • Fix translucent bucket on AWT panels
  • Fix using texture arrays with GPU compressed textures
  • Fix building engine on JDK8 and latest Android NDK
  • Fix point sprites on Android
  • Fix post-processing / FBO on Android
  • Fix running jME3 in the Android emulator
  • Fix shadow effect Z fade feature
  • Fix compilation issues on Java 1.8
  • Fix broken Material.preload() method
  • Fix water filter not working on GPUs without OpenGL 3 support
  • Fix crashing filter multisample support on OpenGL 3.2 contexts
  • Fix bounding volume not updated when geometry inside BatchNode is modified
  • Fix incorrect flipping of 2×2 DXT5 images
  • Fix audio source reverb being enabled by default
  • Fix batching with vertex colored meshes
  • And a trillion other bug fixes I forgot to mention, so you better start using jME 3.1 today!

 

News ,

24. March 2015

 

In this tutorial we start looking at 3D game development using LibGDX.  We explore creating a Camera, Model, ModelInstance and look at the basics of working in 3D using LibGDX.

 

You can watch the tutorial in HD here or embedded below.  The following is the source used in this example.

 

The 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.*;
import com.badlogic.gdx.graphics.g2d.SpriteBatch;
import com.badlogic.gdx.graphics.g3d.*;
import com.badlogic.gdx.graphics.g3d.attributes.ColorAttribute;
import com.badlogic.gdx.graphics.g3d.utils.ModelBuilder;
import com.badlogic.gdx.math.Vector3;

public class Demo3D extends ApplicationAdapter implements InputProcessor {
    private PerspectiveCamera camera;
    private ModelBatch modelBatch;
    private ModelBuilder modelBuilder;
    private Model box;
    private ModelInstance modelInstance;
    private Environment environment;
   
   @Override
   public void create () {
        camera = new PerspectiveCamera(75,Gdx.graphics.getWidth(),Gdx.graphics.getHeight());
        camera.position.set(0f, 0f, 3f);
        camera.lookAt(0f,0f,0f);
        camera.near =0.1f;
        camera.far = 300f;

        modelBatch = new ModelBatch();
        modelBuilder = new ModelBuilder();
        box = modelBuilder.createBox(2f,2f,2f,
                new Material(ColorAttribute.createDiffuse(Color.BLUE)),
                VertexAttributes.Usage.Position|VertexAttributes.Usage.Normal);
        modelInstance = new ModelInstance(box,0,0,0);
        environment = new Environment();
        environment.set(new ColorAttribute(ColorAttribute.AmbientLight,0.8f,0.8f,0.8f,1f));

        Gdx.input.setInputProcessor(this);
   }

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

        camera.update();
        modelBatch.begin(camera);
        modelBatch.render(modelInstance,environment);
        modelBatch.end();
   }

    @Override
    public boolean keyDown(int keycode) {
        // In the real world, do not create NEW variables over and over, create
        // a temporary static member instead
        if(keycode == Input.Keys.LEFT)
            camera.rotateAround(new Vector3(0f, 0f, 0f), new Vector3(0f, 1f, 0f), 1f);
        if(keycode == Input.Keys.RIGHT)
            camera.rotateAround(new Vector3(0f,0f,0f),new Vector3(0f,1f,0f), -1f);
        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 Video


Programming , , ,

Month List

Popular Comments