Elsewhere Games

[elsewheregames-blog-blog]

Boolean Parameters

In APIs, I prefer not to use booleans as parameters, since it will complicate reading code which uses that API. It is hard to tell why a particular parameter is true or false without navigating to its definition or reading the documentation (which of course is always up to date). Using an enum will make the API far more legible.

[elsewheregames-blog-blog]

Code Quality at First Glance

I have found a way which quickly lets me decide whether or not a particular file has well-written Jave code in it; If I open the file in my IDE and there are so many import statements I have to scroll down to see actual code, that file more than likely holds terrible code. 

[elsewheregames-blog-blog]

JemmyFX vs TestFX

Recently I have had the chance to work with JavaFX, the new UI platform built into Java. My main task was to provide a library of reusable UI components, and I wanted to make sure they were rock-solid.

One way of doing so is to use automated integration testing. Basically, you write a JUnit test which brings up the user interface, executes IO events like mouse drags or key presses, and then you test the state of the user interface.

I first created a test suite using JemmyFX. JemmyFX seemed very promising at first, but in hind-sight, that may just have been my amazement at being able to automatically do user interface testing. It turns out that JemmyFX tests are really sensitive to timing issues, which is a huge issue when your tests work okay on your development machine, but the moment you push them to the CI server, they fail. JemmyFX also had great difficulty finding PopUp controls. Perhaps even worse, JemmyFX tests are very verbose, which causes developers to write fewer tests.

Enter TestFX; No more timing issues, and even though the tests I ported had the same test coverage, line count went down 30 to 40%. I had written all these special classes to bootstrap an application to execute tests on different controls in JemmyFX, I no longer needed those either. TestFX will let you write multiple test-cases which will all execute without problem in the same VM process.

[elsewheregames-blog-blog]

IntelliJ IDEA vs. Eclipse

A few quick notes why I like IntelliJ IDEA much better than Eclipse:

IntelliJ supports Java 8, today. Eclipse claims it cannot support Java 8 yet, since it hasn't been officially released. This seems like an odd excuse to me, you can always have partial support for Java 8 specific features? I was using C++11 features in GCC, and that is also not finalized yet, but the parts I needed where there.

Git integration in IntelliJ is light-years ahead of Eclipse. Case in point: Eclipse's primary Git plugin, EGit, breaks in all kinds of mysterious ways when you use a repository with sub-modules. Perhaps even worse, it always reflects the status of the parent repository for files in a sub-module. IntelliJ deals with sub-modules intelligently by using VCS directory mappings.

Eclipse offers some plugins to change the look-and-feel, but nothing that is comprehensive enough to change the entire UI. Scroll-bars often stay the OS color when you are trying to create a darker UI for example. In IntelliJ, its a simple matter of selecting the Darcula theme.

[elsewheregames-blog-blog]

Gradle and Version Control

I usually would post my IDE-specific project files to version control. However, after making the switch from Eclipse to IntelliJ IDEA CE, I got the realization that this is not a good idea. Now, it is actually possible to import Eclipse project files into IntelliJ, but that was a lucky coincidence, and a good developer never expects portability, especially between competing tools.

I made the decision to switch to Gradle. As the homepage says, it seems to combine the strengths of Maven (dependency management) and Ant (flexibility). In my day-job I have some professional experience with Maven, and have always felt that dealing with pom scripts is a struggle, rather than helping me get my job done.

So, say you made the switch to Gradle, one thing you must then also figure out is, which gradle files do I put under version control? Here is a list:

Gradle Project Files

build.gradle

settings.gradle

Gradle Wrapper Files

The following folder and files are part of the Gradle wrapper, which allows a developer to build the project, even if they don't have Gradle installed:

gradle/

gradlew

gradlew.bat

As a final note, Gradle will generate .gradle folder, but it only holds cached information, and should not be committed to version control.

[elsewheregames-blog-blog]

You have to start somewhere right?

[elsewheregames-blog-blog]

Icons and Open Software

I was creating a launcher icon for an Android app today, following Google's launcher icon design guidelines.

While most of the requirements were easy to follow (especially since they did away with the 3d perspective requirements after 1.6), I felt that these guidelines were not very developer friendly.

For instance, the template pack they provide is only available as a PSD, and not many programmers will have Photoshop installed. The would sooner have Gimp or an even simpler tool installed. I use Paint.net for creating images and such, it is by far the best image editing software I have ever used.

I understand the need for Google to try to keep the Market looking professional, but if you set high barriers for that, you run the risk of developers rushing icons through because they are overwhelmed by what is required to it the right way.

[elsewheregames-blog-blog]

Vertex Arrays in Java

Something I always seem to forget, but is a crucial step, is to set the correct byte order when allocating byte buffers to use as OpenGL vertex arrays. I normally try to avoid using static methods, but I am making an exception here:

/** * Directly allocates a float buffer able to hold capacity * amount of floats. * * @param capacity The amount of floats the buffer will hold. * @return A directly allocated float buffer. */ public static FloatBuffer allocateFloatBuffer(final int capacity) { ByteBuffer backingBuffer = ByteBuffer.allocateDirect(capacity * 4); backingBuffer.order(ByteOrder.nativeOrder()); return backingBuffer.asFloatBuffer(); }

[elsewheregames-blog-blog]

Skinning the Android Emulator

I always felt the default Android emulator looked a little boring. Turns out, there is way to apply a skin so that the virtual device looks more like an actual Android device:

Google for the "Android emulator skin" + the name of the device you wish the emulator to look like. For instance, I found this Droid skin package

There will be a folder containing some image files, a layout file, and a .ini file. Copy this folder to the skins folder of your SDK, for instance android-sdk_r3-windows\android-sdk-windows\platforms\android-8\skins (where the number after "android-" specifies the API level this skin can be used with)

Run the AVD manager from inside Eclipse, click "New" to create a new virtual device

Select "Built-In" from the "Skin" section, then select the skin you just copied to the SDK folder

Now your virtual device will look just like an actual device when you run the emulator. I did run into an issue where the emulator is so large that my desktop was unable to contain it. Fortunately that can be fixed by opening the launch configuration for your project and, under the "Target" tab, adding -scale n (where n is a scale factor, e.g. 0.5) to the emulator command line options (near the bottom).

From looking at the folder containing the resources for the virtual device, it seems that is should also be really easy to create custom skins of your own. Experiment away!

[elsewheregames-blog-blog]

I can lose hours here!