28. September 2013

There are a new set of coordinated releases to the Cocos2d-x family of game development libraries and tools.  The changes include:

CocosStudio

• UI editor for UI graphic artists
• Animation editor for graphic artists
• Data editor for game data designers
• Scene editor for game designers

Cocos2d-html5

• Improved Sprite, Node, LabelTTF class, now it is clean and clear
• Added a new sample game Fruit Attack which works great on PC browsers, mobile browsers, and can even be run natively as an android and iOS app with JSB
• Replaced cc.Sprite and its subclasses's texture from DOM element to cc.Texture2D on Canvas mode,
• Improved cc.Texture2d. Now you don't need to wait for loading resources when creating a new scene or layers. Textures will pop up when they are loaded
• Improved the update function of Actions. Now Action objects use less temporary objects, making it better for GC performance.
• Improved LabelTTF rendering pipeline. Now it caches the result which is 100% faster on mobile browser
• Fixed API compatibility between Cocos2d-html5 and JSB: cc.ParticleSystemQuad has merged intocc.ParticleSystem. For more info, please read Upgrade guide v2.1.5 to v2.2
• Added Auto Hiding url address bar for mobile browsers. Please refer to the template and the Hello World for examples
• Added frame event, collider and blend type supporting for Armature. Now Armature supports 2 tools: 1.CocoStudio, 2.DragonBones
• Set auto render mode $Default value$ to canvas for mobile browsers and WebGL for desktop browsers

Cocos2d-x

• Initial version of Windows8 and WinPhone8 port
• Supported the first stable version of CocoStudio v1.0.0.0
• Almost no differnce between JSB and cocos2d-html5 v2.2
• Lua binding supports CCTableView and CCScrollView

The Cocos2d-html5 project also released a new sample game, Fruit Attack:

You can play it in your browser here.

26. September 2013

There is an old law, possibly predating the age of man, that all tutorials must start with Hello World.  I am nothing if not law abiding, so therefore let’s create a Hello World app.  Hello World is generally one of the simplest programs you can create, you simply display the words Hello World on screen.  Of course, there are always complications in life… that’s what makes it interesting!

To get started I created a simple project using the Project Setup tool we discussed in the prior tutorial.

We are going to jump in with the code in a second, but first let’s take a quick look at the code created by the project tool, gdx-setup-ui.  Your project should look like this:

Obviously your file names will vary depending on what you used during the project setup tool.  The key thing to note is the basics of how code is laid out.  The non-suffixed folder ( hello-world ) is where the shared code goes.  The –android, –desktop and –html folders are where platform specific code goes and hopefully you will have minimal need to use these.  I will look at them a bit closer in a few minutes, but for now it’s the file HelloWorld.java that we are interested in.  This is where a very important class called an ApplicationListener is implemented.  Here is the code I used:

package com.gamefromscratch.helloworld;

public class HelloWorld implements ApplicationListener {
private SpriteBatch batch;
private BitmapFont font;

@Override
public void create() {
batch = new SpriteBatch();
font = new BitmapFont();
font.setColor(Color.RED);
}

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

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

batch.begin();
font.draw(batch, "Hello World", 200, 200);
batch.end();
}

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

@Override
public void pause() {
}

@Override
public void resume() {
}
}

The first thing you may notice is… there’s no Main!  Well there is one and we will take a look at it in a second.  At the end of the day though, LibGDX is an event driven engine.  You implement an ApplicationListener and GDX calls a number of functions that you can respond to.  The render() method will be called each frame, so if you want to, you can think of that as your event loop.  Otherwise there are functions that are called in response to various events, these include create, resize, pause and resume.  I imagine you can guess what event each one is in response to!

The bulk of our code is in create() and render().  In create() we allocate a new SpriteBatch, BitmapFont and set the font to the colour red.  SpriteBatch’ing is a common activity in 2D game engines built over 3D libraries, if you’ve used XNA you are used to it.  Basically behind the scenes, LibGDX is using OpenGL ( or WebGL depending on platform ) to do the rendering.  In OpenGL there is a fair bit of overhead in drawing … well, anything.  A spritebatch combines them all into a single operation to reduce the amount of overhead.  In a nutshell, it makes 2D rendering a great deal faster.  A BitmapFont is exactly what it sounds like, a 2D bitmap containing all the characters.  If you don’t specify a Font in the constructor, you will get the default font Arial-15 included with LibGDX.  The font file looks like this:

In the render() method we clear the screen to white by making the OpenGL function call glClear() and glClearColor().  The parameters to glClearColor are the red, green, blue and alpha ( transparency ) values to clear the screen with.  The function glClear actually clears the screen.  As you can see, the underlying OpenGL functionality is exposed in Gdx.gl, although generally you wont work at that level very often.

Next we start our sprite batch by calling begin(), then render our text to the batch using the font.draw method.  The parameters to draw() are the batch to draw to, the text to draw and the x and y coordinates to draw the text at.  If you run this code ( right click hello-world-desktop and select Run As->Java Application ) you will see:

Voila!  It’s Hello World.

One important thing to be aware of is the project hello-world is not an application that you can run, its a library used by the other projects.  I’ll show you what I mean, take a look at code in hello-world-desktop for example:

Hey look, it’s Main!  Let’s check out the code:

package com.gamefromscratch.helloworld;

public class Main {
public static void main(String[] args) {
LwjglApplicationConfiguration cfg = new LwjglApplicationConfiguration();
cfg.title = "hello-world";
cfg.useGL20 = false;
cfg.width = 480;
cfg.height = 320;

new LwjglApplication(new HelloWorld(), cfg);
}
}

This is the actual entry point for your application, or at least it is for the desktop target.  This is where the Desktop specific configuration happens.  You then start your game off by creating a LwjglApplication object, passing in an instance of your ApplicationListener as well as the Lwjgl specific configuration settings.  If Lwjgl is new to you, it’s a Java based game wrapper over top of OpenGL and is what LibGDX uses for desktop rendering.  Beyond configuring it here, you will have no other interactions with it, LibGDX takes care of all of that for you.

To really understand how cross platform magic works in LibGDX, let’s also take a look at the Main for the –html project.  In this case it’s not actually called Main, but instead GwtLauncher.java.

Gwt stands for Google Web Toolkit, and it’s a technology Google provides for compiling Java into JavaScript for use in a browser.  It’s the secret sauce that LibGDX uses to make your game run in HTML.  It’s also horrifically annoying at times, you have been warned!  That said, if you dont care about HTML, you can remove this project completely and save yourself a number of headaches.

Let’s take a look at GwtLauncher.java:

package com.gamefromscratch.helloworld.client;

import com.gamefromscratch.helloworld.HelloWorld;

public class GwtLauncher extends GwtApplication {
@Override
public GwtApplicationConfiguration getConfig () {
GwtApplicationConfiguration cfg = new GwtApplicationConfiguration(480, 320);
return cfg;
}

@Override
public ApplicationListener getApplicationListener () {
return new HelloWorld();
}
}

Look’s a lot like the –desktop project main doesn’t it?  The basic concept is exactly the same, you create the platform specific configuration bits, and create an instance of your ApplicationListener.  The GwtApplication class is callback based however, so it looks a bit different.  Once again, you should rarely be working at this level.  One important thing to note though is the values being passed to GwtApplicationConfiguration… this represents the size of the HTML canvas being created.  So if you want your HTML app to be more than a small square in the middle of the screen, this is where you change it.

So basically LibGDX works by having you create a single common library that implements your game in a cross platform way in the form of an ApplicationListener.  To support multiple platforms, you have a project for each platform where you create a platform specific application ( an instance of GwtApplication in the case of HTML targets, LwjglApplication for desktop targets, AndroidApplication for Android targets, Application for iOS targets… not shown because I am working on Windows currently ) , configure it and pass in the ApplicationListener.  It is this application class that will be calling back to your ApplicationListener each frame.  The nice news is, most of the time, you wont care about any of this… but it’s handy to understand what’s happening behind the curtains.

Remember I said it was a bit of a pain?  Well let’s take a look at what happens when you run the hello-world-html application ( right click hello-world-html->Run As->Web Application):

Ugh…  so basically our code is trying to do something GWT does not permit.  If we flip back to Eclipse in the Console panel we can get a bit more insight into the nature of the exception.

It’s line 17 in HelloWorld.Java that is causing the exception:

font = new BitmapFont();

So, what exactly is going on here?  Well, remember earlier when I told you that BitmapFont’s default constructor would use the built-in arial-15 font.  Well, when I said built in, that file actually resides in gdx.jar which is included in your project.  A jar file is actually just a zip, so if you extract the file you can see all the code and assets that make up the gdx library itself.  Of particular interest to us is the folder \gdx\com\badlogic\gdx\utils, this is where the font file resides among other files:

Basically the GwtApplication is trying to access this file and doesn’t have permission to do so.  What’s the moral to the story?  Cross platform is awesome… but not always free!  Unless you need to support HTML, I would suggest not creating an HTML project, as it is by far the most fragile part of LibGDX and working with GWT causes all kinds of heartache and complication.  Your mileage may vary!

That said, there is a very simple fix to this, and it nicely illustrates how you deal with files between your projects… a process that may not be particularly intuitive.  The simple solution is to add the files arial-15.fnt and  arial-15 to the project and change the line:

font = new BitmapFont();

to

font = new BitmapFont(Gdx.files.internal("data/arial-15.fnt"),false);

This version of BitmapFont’s constructor takes a file handle of the font file you want the BitmapFont to use.  Gdx.files is used for file manipulation, internal returns a file handle to a file that is included within the project.  The false parameter is specifying that the font’s graphic isn't flipped upside down.

So, how do you actually add the file to the project?  You add them to the assets\data folder of the hello-world-android project:

You can add the files by simply dragging/dropping from Finder or Explorer to the data folder in the Package Explorer.

Now that the font file has been added, we can now run the HTML target:

So that’s Hello World in LibGDX.  Next up we look at something more advanced than Hello World.

23. September 2013

I’ve recently been having a bit of a fight with Google development tools, GWT and the GWT plugin for Chrome on Windows 8 specifically.  Following the linked instructions I did manage to get the plugin installed, however today I started experiencing a new joy…  Every few minutes I would experience:

It would sometimes happen on load, other times when I tabbed back to Eclipse.  Apparently the GWT plugin is notoriously fragile.  Given the fact it doesn’t even run on Windows 8 without something of a song and dance, this isn’t really shocking.  I did however find a fix.  If you experience a GWT DMP Plugin crash in Chrome, check the following.

Go to chrome://extensions in Chrome.  Locate the plugin and click options:

In my case, there were no inclusions set for some reason.  Make sure localhost is added like so.  ( I did 127.0.0.1 too just in case… )

And, no more crashes!  That said, I’m still fed up with the entire process.  There is a project called Super Dev Mode that removes the plugin requirement completely, but there is an element of complexity involved.

19. September 2013

In case you’ve never heard of it, LibGDX is a Java based game library capable of targeting iOS, Android, Desktop ( Windows, Mac and Linux ) and HTML5.  It provides a full suite of 2D game functionality including Input, Graphics, Fonts,  Physics, Storage and increasingly, 3D.  So basically LibGDX is pretty much a one stop game development library.  This series is going to look at all of those aspects of LibGDX eventually.

EDIT: Sept 9/2014

The setup process changed slightly again.  On the bright site, it’s easier now, read here.

EDIT: Jun 24/2014

The process for creating a LibGDX project has changed substantially since this post was created.  There is now a Gradle based application that makes creating new projects much simpler and allows you to use IDEs other than Eclipse.

Read this post on getting started.  The portions of this post on running/debugging in Eclipse should still be valid.  For configuring IntelliJ IDEA to run LibGDX applications, refer to this post.

** END IMPORTANT READ ME **

The first part of getting started with LibGDX is installation.  If you haven’t got a Java/Android development environment set up yet, this portion is going to be a bit annoying.  In a nutshell you need to install in order the Java JDK, Android SDKEclipse, then Google ADT and finally the Google Plugin for Eclipse ( for GWT ).  I am not going into specifics about how to install all of these, however I went into pretty extreme detail in these instructions for setting up PlayN that cover most of the Eclipse related configuration.  If you run into a problem during the install, those instructions might help.  The process is actually pretty straight forward, it’s just long.  Oh yeah, one more thing you are going to need of course is LibGDX itself!  You can download it here.  In my limited experience, the nightly builds are actually pretty safe to use.  Common sense dictates you should use the stable version, but I am neither common nor sensible, so I’m going to risk it.

From this point on, I am going to assume you have a properly configured Eclipse install.  I am no huge fan of Eclipse and you have other options like NetBeans ( instructions ) or IntelliJ ( instructions ), but they are the less supported and slightly more complicated route.  Like it or not, if you are working with Android, Eclipse is still the path of least resistance.  Android Studio is a very encouraging option but sadly it’s Android focus make it a poor fit for LibGDX.

OK, let’s get started…

If you haven’t already, unzip the LibGDX archive somewhere.  I personally went with C:\dev\libgdx-0.9.8.  Keep the zip archive however.

Located and double click gdx-setup-ui.jar in the root directory of the libGDX.

If it doesn’t, you appear to have a problem with your Java install.

Click Create.

Fill in the resulting dialog.  You can see the values I used above.  You can optionally create a desktop, html and ios project.  The core and Android projects are mandatory.  Note, if you change the destination, you will have to specify the path to the LibGDX zip file.

Once you’ve specified the LibGDX path ( or if you didn’t change Destination ), the Generation button should be enabled:

Click it.

The following screen appears:

Click Launch.

All things according to plan, you should see:

If you don’t see the above messages, welcome to the LibGDX forums.   StackOverflow is another good place for LibGDX related support as there are already 1,500 LibGDX tagged questions.

At this point we are done with the setup tool, you can close it.  If you navigate to folder you specified as the destination, you should see the following folder structure:

It should mirror the platforms you selected during setup.

Now it’s time to fire up Eclipse.

Now select File –> Import

Then select General->Existing Projects into Workspace and click Next.

Then the following dialog will appear:

With Select Root Directory checked, click Browse and navigate to the folder you chose as a destination earlier.  You should then see a list of available projects, all of which should be checked.  Then optionally choose if you want the project file copied within your Eclipse workspace.  When complete click Finish.

Now you should see:

hello-world ( or whatever you named the project ) is the common project, while each additional platform has a –platform suffix.

#### Running the desktop project

Let’s run the Desktop project now.

Right click helloworld-desktop, select Debug As->Java Application:

A dialog will appear and ask you what you want to run.  Locate your project main, then click OK.

Congratulations, your first ever LibGDX application!

#### Running the HTML project

Now try the same thing with the html5 appllication, right click, this time select Debug As->Web Application

A few seconds later you should see:

By the way, if you are running Chrome on WIndows 8, expect trouble.  This is why I hate working with Google tools…  anyways, the 5th suggestion in this post fixes the problem.  Or you could just use Firefox.

When working with HTML5 builds in Eclipse, there is something you should be aware of.  Running the web application again in the way listed above will fail.  It will try to start another web server and find the built in one already running and throw up.  You have two options, both in the Development Server window.

You can either use the red stop icon to shut down the internal web server, allowing you to run it using Debug As->Web Application.  Or you can hit the yellow arrows to reload your code.

#### Running an Android Project

When it comes to running an Android application, you’ve got a couple options.  First you can plug in an actual device.  If you use a device, make sure the ADB driver for it has been installed.  The ADB usb driver is part of the Android SDK.  This is by far the best way to work with Android.

If you don’t have a device, you can instead run the emulator.  If Eclipse doesn’t detect an attached device, it will try to launch the emulator.  If it cant find an emulator, it will fail.  Just a heads up, working with the emulator, especially for games, SUCKS.  Get a device, really, trust me on this one.

If you haven’t got a device and havent created an emulator yet, do so now.  You can do it from within Eclipse.  Select Window->Android Virtual Device Manager.

In the resulting dialog, click New:

Here is an example I’ve used.  Prefer emulating the Intel Atom chipset, it runs much faster.  If you are running an Intel chipset with HyperVisor support install the Intel Hardware Accelerated Execution Manager which can be downloaded here.  Or better yet, get a real device.  Did I mention that already?

The emulator is notoriously fragile, you will come to hate it quickly.  Did I mention you are better off getting a real device?

Now that your emulator is created, select it and click Start…

Go make some tea…

Perhaps a few crumpets?  A bagel perhaps?

Oh, hey, happy birthday!

Ok, it should be loaded now.  For the record… leave the emulator loaded.

Now you can run your Android application using Debug As or Run As->Android Application

And a few moments later, you should see:

Back in Eclipse, get to know and love LogCat.

It’s a great source of Android debug information.  This is where all trace, debug and error information is displayed.

So, what about iOS.  Well first off, I’m running on Windows right now, so there is no option.  Second, libGDX is currently in a bit of a transition state.  Previously it relied on MonoDevelop to deploy to iOS. Now it is transitioning to RoboVM for iOS support.  In the future I may specifically cover deploying to iOS… when I am on my Mac would be a good start!

In the next part we will look closer at project layout as well as get down to some coding.

19. September 2013

Although they didn't make an official blog post, nor have any information about it on their home page, there seem to have been some rather massive changes in the license structure for the Loom Game Engine.  I took a look at Loom several months back, it's an impressive 2D game engine using LoomScript ( an ActionScript/C# hybrid ) with a very Rails like workflow.  Previously it was 40$a month, that seems to have changed: From 40$ to 5$a month is a rather spectacular change in price. There is also now a free tier with the following restrictions. No access to the following: Easy Mobile Deploys Command-Line Workflow Live Reload Dev Team Forum Support Feature Request Voting On top of that, they've announced they have gone open source on the Apache 2.0 license. First, we have open sourced the Loom Native SDK! It is available under an Apache 2.0) license. The repository is available athttps://github.com/LoomSDK/LoomSDK. We are very excited to see you guys get directly involved in the development of Loom while we also offer more transparency about what we're working on. Not to mention that merging updates should be more convenient for you and - should you choose to do so - you also get to show off your involvement in an open-source project on your GitHub profile page! The source code is available on Github. I'll admit, I'm a bit confused what exactly you get from the free tier, vs the Turbo tier vs just getting the source code. TheEngine.co team are currently taking a vacation, so hopefully we will get a bit more clarification when they return. In the meanwhile they have launched a new website, loomSDK.com. #### Tag cloud #### Month List #### Popular Comments #### Legacy Links • ### New to Game Dev? Start Here! • ### Game Dev for Kids • ### C++ Game Tutorial Series • ### Blender Game Art Tutorial • ### LibGDX Tutorial Series • ### LibGDX Video Tutorial Series • ### Phaser/Typescript Tutorial Series • ### Godot Game Engine Tutorial Series • ### PlayStation SDK Tutorial Series • ### Cocos2D HTML5 Tutorial Series • ### Moai Tutorial Series • ### Gamedev Math Tutorials • ### SpriteKit with Swift Tutorial Series • ### HTML5 Game Dev Links • ### Product Reviews Using Netbeans 7.1.2 with PlayN 1.3 # Home > Programming > 24. May 2012 This tutorial is going to cover everything you need to know to get a PlayN project up and running using NetBeans. In the end you will know everything you need in order to be able to create and run the Java, Web and Android projects using PlayN 1.3. The iOS project should work as well, but I am not on a Mac. I have come to a conclusion recently. I hate Eclipse, every time I work in it, I am fighting with the IDE more than anything else. More specifically, I hate the M2E maven plugin more than words can describe. I have attempted to create a series of beginner tutorials for PlayN and each and every time, I end up jumping through a half hour or more of hoops in order to get Eclipse to build my project. Not much point in making tutorials, if my readers can’t even get PlayN up and running, right? I don’t want to spend all of my time troubleshooting PlayN installs! It seems like 90% of the support issues you see with PlayN revolve around Eclipse and M2E problems. So that is what this guide addresses. It is about getting a specific version of PlayN ( 1.3 ) running with a specific version of NetBeans ( 7.1.2 ), to the point you can run all of the different kinds of targets it supports. So if you want to get started with PlayN development, start here! It’s going to look long and daunting, but it really isn’t all that bad, I just go into a lot of detail. If you’ve already got Netbeans up and running, you can skip 80% of it! ## What you need to get started Before we go too far ahead, you are going to need to have downloaded and installed a Java JDK. Note, the JRE and JDK are different things, and you very much need a JDK installed. I recommend version 6 over 7 ( that link was to 6 ) at this point, but either *should* work. Additionally, if you are intending to do Android development, you will have to download and configure the Android SDK. Details on configuring the Android SDK are available here, just ignore all the Eclipse bits. You are now going to need a version of Netbeans. Here you have a couple of choices: You want either JavaSE or Jave EE. If you don’t care about HTML development, go with Java SE, otherwise go with EE. In this tutorial we are going to go with the Java SE version and add the bits as we need them. Download and install whichever version you choose now. Before you install, make sure you have a Java JDK installed already, you will be asked for the JDK path as part of the install process. Otherwise it’s just a next , I agree, next, I agree, click fest. Unless of course you are the type that reads EULAs… in which case, see you in a couple hours! ## Configuring NetBeans’ required plugins Now that you’ve installed Netbeans, fire it up. We need to configure a couple plugins right away. Select Tools->Plugins In the resulting dialog, select the Available Plugins tab, scroll down and check “Java Web Applications” then click Install. You can skip this part if you installed Netbeans EE. Dialog will appear, click Next Agree to the license agreements and click Install This process will take a few minutes, then request that it restart NetBeans, let it. Now we need to set up the NBAndroid plugin, which is the Netbeans Android connector. Once again select Tools->Plugins. This time select Settings in the resulting dialog: Then click add, and fill in the following in the dialog. For name enter whatever you want, I went with NBAndroid. For URL enter http://kenai.com/projects/nbandroid/downloads/download/updatecenter/updates.xml, now click OK. At this point Android should show up as an option under Available plugins. For me, as is the way with software, I encountered a bug and it didn’t. At this point I exited and re-launch NetBeans, go to Tools->Plugins and now the options are there under Available Plugins. If they don’t show up for you, restart Netbeans. Now select Android and Android Test Runner for Net Beans 7.x, like so: Click install, then as before, agree to the EULA and continue. You may run into this scary message, just click continue: All right, Android is now configured, let’s create our project! ## Creating your PlayN project Select the File->New Project menu In the resulting dialog, select the Maven category, then under Projects select “Project from Archetype”. Click Next. In the next screen, on the right hand side click the Add… button Fill the next dialog in with the following details; Group Id = com.googlecode.playn Artifact Id= playn-archetype Version 1.3, then click OK. Now make sure your newly added Archetype is selected and click Next. Now fill in the following details. Name your project in ProjectName, I am going with playndemo and assume you did too for the rest of this tutorial. Artifact Id will be set automatically. Group id is your url, in my case com.gamefromscratch. Be sure to specify 1.3, it will start as 1.0-SNAPSHOT, you don’t want this! Finally, and this part is extremely important, fill in the value for JavaGameClassName! I went with playndemo, but it is extremely important to click somewhere on the screen after setting it, another text box for example, or the setting will not be saved!!! If you get an error later on that JavaGameClassName was not set, you ran into the bug of this value not saving. Now click Finish. If all went well, it should have generated your project like this: ## Building your project ( resolve Maven dependencies ) This next part is incredibly important, we need Maven to bring in all the various dependencies. Right click the Meta Project and select Clean and Build. Maven is now going to download and configure all of the various dependencies, and there are a lot of them. Like tea? Perhaps now would be a good time to brew a cup. Just keep an eye on the bottom right of your screen: Ideally what you want to see is this: Fortunately, you only need to do that part once. If you are sitting there thinking… wow, this really took a long time, I wonder if something went wrong?!?!?! Nope, nothing went wrong, it really does take that long! Welcome to maven. ## Running the Desktop Java app Normally all you would have to do is right click the Java project and choose run. However as of right now there is a dependency on the LWJGL native dlls that you need to resolve manually. If you are reading this at some point in the future, you may no longer need to perform this step! Try running the Java App. Right click playndemo Java and select Run In the resulting dialog, select your main class if required and click Select Main Class. You will receive: Failed to execute goal org.codehaus.mojo:exec-maven-plugin:1.2:exec (default-cli) on project playndemo-java: Command execution failed. Process exited with an error: 1(Exit value: 1) -> [Help 1] If you scroll up the error, you will see: Exception in thread "main" java.lang.UnsatisfiedLinkError: no lwjgl in java.library.path at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1738) at java.lang.Runtime.loadLibrary0(Runtime.java:823) at java.lang.System.loadLibrary(System.java:1028) at org.lwjgl.Sys$1.run(Sys.java:73)
at java.security.AccessController.doPrivileged(Native Method)
at org.lwjgl.Sys.<clinit>(Sys.java:112)
at org.lwjgl.opengl.Display.<clinit>(Display.java:135)
at playn.java.JavaGLContext.viewWasResized(JavaGLContext.java:125)
at playn.core.gl.GLContext.setSize(GLContext.java:48)

This is because of the missing libraries, lets add those now.  ( Or if you didn’t, this problem is fixed and skip ahead! )

Head on over to LWJGL’s download site and download the binaries zip.  Now extract the contents of this file somewhere, it doesn’t really matter where.  I extracted to c:\temp, preserving folder names.  The end results looked like this:

It’s really only the native folder we care about.  Stick it anywhere, just remember the path.

Now back in NetBeans, right click playndemo Java and select Properties.

We now have to add a VM param to the Run options.  On the categories side, select Run, then on the right in VM options, add  -Djava.library.path=c:\path\to\lwjgwl\windows, like this:

Click OK, then right click the Java project and select Run.

Voila, your running Java PlayN application.  Now on the the HTML project.

## Running the PlayN HTML application

Right click playndemo HTML and choose Run:

If Run isn’t an option, something went wrong when you configured the Java Webserver plugin, or you aren’t running EE edition.  Go back and repeat that step until run appears.

On first run ( assuming you didn’t install a webserver as part of your Netbeans install ), you will encounter this dialog with an empty server list:

We now need to install and configure a web server, don’t worry, its an easy process.  In the menu, select Tools->Servers

In the resulting dialog, click Add Server…

Click GlassFish Server 3+, then Next

Save it wherever you want, I went with the defaults, click Finish ( unless you want to change default settings ):

If all went well, you should see the following screen, simply click Close.

Now right click playndemo HTML and choose run. Now in the deployment dialog, you have a server you can select, do so and click OK:

And voila, your app running in a browser:

If you have problems or need to maintain or restart your GlassFish install, you can do so via the Window->Services menu option:

## Running your PlayN Android Application in Netbeans

This part has a bit of a gotcha attached.  PlayN switched to use OpenGL 2.0 and the Android emulator simply doesn’t support Open GL 2.0 yet.  You can try to run it on the emulator, but it will crash every time.  If you have a physical device, you can get Netbeans to target it.

First right click playndemo and select Properties:

On the left hand side selection Actions.  In the Actions list, select Run Project.  Under Execute Goals: enter android:deploy android:run, and under Set Properties: enter skipTests=True and android.device=usb.  Finally click OK.  This is behind the scenes configuring a pair of maven commands.

Now with your Android phone plugged in, with USB debugging enabled, right click playndemo and choose Run.  Oddly enough, sometimes it deploys and runs the application, sometimes it simply deploys it and fails to run.  Worst case scenario, locate the app icon on your device and launch it manually.

Voila, PlayN running on my Galaxy Note  ( the black is because of the 1280x720 resolution ):

As you can see, you can successfully target all three platforms from Netbeans.  Trust me, that process looked a lot more complicated than it actually was.  Plus, you only have to do 95% of it once.