Using Intel RealSense with libGDX

Today i finished off the 1.0 release of our Intel RealSense SDK integration for libGDX. It comes in form of a dependency you can easily include in your desktop projects (Windows 8+ only i’m afraid) (build.gradle):

project(":core") {
    ...
    dependencies {
        ...
        compile "com.badlogicgames.gdx:gdx-realsense:1.0.0-SNAPSHOT"
    }
}

Watch the video above, and follow the instruction the project’s Github page.

Happy coding!

Beginning Android Games riding into the sunset

A few months ago i was contacted by Apress on wether i want to give my book Beginning Android Games another update. The fist edition was published in April 2011, with two subsequent updates, Beginning Android 4 Games (horrible title i objected to in vein), and Beginning Android Games 2nd Edition. You can imagine that there’s some kind of emotional band between me and that 700+ pages behemoth. So, allow me to close this chapter of my life by giving you a short history of Beginning Android Games.

I still remember those initial 6 months of writing the first edition as if it was yesterday. Android was still young, and i found a nice niche with the book. The book was the perfect outlet to document all the small and big issues i encountered during those early days on top of trying to teach people how i think one could approach writing games for Android.

For 6 months i had a bi-weekly 3 days crunch where i’d write an entire chapter (20-80 pages, including formating, figures, tables and of course lots of code). I’d write at night after work on my little ASUS netbook, cursing MS Word every few minutes. If you ever get approached by a publisher, ask for a Latex template. Chances are they may not know what that is. If they do, you got a winner. The use of Sharepoint may be the second filter you can apply.

After a stressful 6 months spree, the book went to the print shop, ready to be shipped around the world. For a month i didn’t hear from anyone. In April 2011, the book was finally available for purchase. It was one of those moments in your life when you couldn’t be happier. I seldomely felt such a feeling of accomplishment, irrespective of wether the book would actually sell or not. Shortly after i got 20 physical copies which i handed to friends and family. An equally satisfying feeling.

The books climbed the ranks on Amazon and eventually held the #1 spot for many, many months in the game programming section. This was another milestone, and it’s hard to describe how it feels. The book sold really well appearently. A fact that was later confirmed by royalty statements from the publisher.

A few months later, Apress approached me again, saying it was time to update the book. I’d barely recovered from writing the first edition, so i found a co-author in Robert Green. He was another early Android game dev with whom i exchanged a lot of gossip about Android’s peculiarities (broken multitouch anyone?). He singlehandedly updated the book which eventually became Beginning Android 4 Games. We had quite a few discussions with the publisher about the misleading title. They didn’t give in. End result: the book didn’t sell well, the first edition has always outsold it. Many readers were upset about the title choice, and i can relate.

Another few months later, Apress had another update request. This time,the book would be called Beginning Android Games 2nd Edition. I took over most of the update this time, adding a few new chapters, e.g. how to use the NDK to speed up performance critical code. This edition did quite well again and held the first spot on Amazon for quite a while.

Finally, i got approached earlier this year to update the book for Android 5.0. Again, i felt like i needed a co-author as i was just about to change job and felt quite exhausted from a long stressful period at my old job. I found a willing victim in Justin (Nex). Sadly this didn’t work out for various reasons (none of which can be attributed to any single person involved).

The book opened many doors for me and allowed me to go places and meet people i wouldn’t have meet otherwise. That alone was worth the effort. It also showed me what can be done if you are determined. I’m really proud of what we achieved.

It is thus with great sadness that i have to announce that Beginning Android Games will not be updated by me or any co-author. It had a good 4 year run. Apress may still chose to find an update author on their own, which i’d mentor if they want me to.

I’d like to thank many, many people. Stef for keeping me sane while writing the first edition and putting up with me and an empty bed for all these months. Robert for being a splendid co-author. All the editors at Apress who helped the book become what it is (who sadly weren’t available to correct this blog post). And last but not least, all you readers for sending me a lot of kind words over the years and sharing your stories.

Happy coding :)

Let’s write a Chip8 emulator in Kotlin [Part 2: The first refactoring]

Disclaimer

This series is a means for me to learn Kotlin. As such i might misuse some features of Kotlin, not follow best practices or simply to silly things. Please always check the comment section for feedback from more knowledgable people. I’ll also have follow up articles where i refactor the code to be more idiomatic. So, make sure to check back.

Refactoring

Part of learning a new language is to get to know the idioms. Thanks to feedback on the last articles, i have a pretty good idea how to reorganize the code to make it more maintainable and concise. Let’s get going.

Moving things around

In the previous article we created a few top-level methods, loadRom, decode, and disassemble. I put them in different files. Let’s clean that up. We want a single file that contains the top-level methods that make up the functionality of the emulator. (Chip8.kt).

package chip8;

import java.io.DataInputStream
import java.io.BufferedInputStream
import java.io.FileInputStream

fun loadRom(file: String): VmState {
    ...
}

fun decode(decoder: Decoder, address:Int, msb: Byte, lsb: Byte) {
    ...
}

fun disassemble(vmState: VmState): String {
    ...
}

That cleans up the files Disassembler.kt, main.kt. I think i’ll make it a habit to put top-level functions of a package into a file named after the package itself.

Extension properties instead of extension methods

We added a few extension methods to Int and Byte in the previous article. Ioannis Tsakpinis of LWJGL fame and avid Kotlin user pointed out a better way to handle these extensions. We’ll make them extension properties instead of extension methods (Extensions.kt):

val Int.hex: String get() = Integer.toHexString(this)
val Byte.hex: String get() = Integer.toHexString(this.toInt())
val Byte.hi: Int get() = (this.toInt() and 0xf0) shr 4
val Byte.lo: Int get() = this.toInt() and 0xf

I renamed the properties to shower names and fixed up any code relying on the old extension methods accordingly. This makes our decode function a lot more concise, e.g.

0x5 -> decoder.jeqr(msb.low(), lsb.high())

turns into

0x5 -> decoder.jeqr(msb.lo, lsb.hi)

It also cleans up our Disassembler, which is our next refactoring victim.

Shorter single line methods

Disassembler is composed of single line methods for the most part. We can omit all the curly braces and new lines, turning

override fun call(address: Int) {
    builder.line("call 0x${address.toHex()}")
}

into

    override fun call(address: Int) = builder.line("call 0x${address.hex}")

As per the definition of Decoder implemented by Disassembler, all of these methods need to return Unit. For Disassembler#before and Disassembler#unknown we can’t just apply the single line style. Remember, the return type of a single line style function is the type of the expression of that single line. In case of these two methods, we call StringBuilder#append, which returns the StringBuilder. That is obviously not of type Unit.

We can apply a trick pointed out by Andrey Breslav of Kotlin fame: create an Extension method called unit that returns, you guessed it, Unit. Let’s modify Disassembler.kt:

class Disassembler(): Decoder {
    val builder = StringBuilder()
    fun Any?.unit() {}
    override fun before(opCode: Int, address: Int) = builder.append("addr: 0x${address.hex}, op: 0x${opCode.hex}, ").unit()
    override fun unknown(opCode: Int, address: Int) = builder.append("Unknown opcode addr: 0x${address.hex}, op: 0x${opCode.hex}").unit()
    // as before...

Note the fun Any?.unit() {} extension method. It’s attached to any object (!= null) within the scope of Disassembler (i think). We can then rewrite the before and unknown methods to single line style, calling unit() to make the expression’s type Unit in accordance to our Decoder trait.

You can see the entire refactoring diff on Github.

Up Next

Next time we are going to write our first iteration of a simple interpreter.

Previously

Let’s write a Chip8 emulator in Kotlin [Part 0: Motivation & Setup]
Let’s write a Chip8 emulator in Kotlin [Part 1: A simple Disassembler]

Following Along

  1. Install the required tools (JDK, IDEA, IDEA Kotlin plugin, Git)
  2. Clone the repo: git clone https://github.com/badlogic/chip8.git
  3. Checkout the tag for the article you want to work with: git checkout part2
  4. Import the project into IDEA (Open Project, select build.gradle file, select "Use customizable gradle wrapper"