Monthly Archives: April 2013

Remember that Pebble I was talking about the other day? Well despite the fact that half the time the display looks like this:


I’ve managed to compile and run this:


The key to being able to use the screen is to hold the Down button quite hard… But unfortunately this isn’t always practical, like when I want to use the Down button repeatedly on a list. I have contacted Support but have yet to receive a reply…

But in the meantime I can keep writing watchfaces, just can’t use ’em.

But what if we wanted to change it? Well, here’s how you’d go about it:

  1. Load up Ubuntu Linux or a suitable VM, download the Pebble SDK (including dependencies and libraries) and set it all up as described here.
  2. Write the source file, with guidance from the SDK documentation. I’ve already done this (and you can read it in full here).
  3. Change this line to whatever you want this very basic watchface to say. 1
  4. Navigate to the watchface’s directory in a Terminal. For example: cd ./~pebble-dev/myWatchfaces/TextTest and build the watchface using ./waf configure build2
  5. Find the resulting package file in the ‘build’ directory. For example: ~/pebble-dev/myWatchfaces/TextTest/build
  6. Copy this file from Ubuntu to Windows if you’re using a VM (I couldn’t get the next step to work when inside a VM.) 3
  7. You need to get to the package file directly on the phone. The suggested method is to use a Python HTTP Server, which comes pre-written as part of the Python distribution.4
  8. On the phone, open a Browser and go to the LAN address of the computer running the server. On my network this would be
  9. There you will find the file. Tap the file name and the Pebble app will open and install the watchface in seconds. 6
  10. Now you should see the watchface with its changes on the watch!7

Now to work on some other ideas I’ve had…

Today is an exciting day. Why? Because I played a game with someone in Germany.

Why is this exciting you may ask? Good question. It wasn’t just any game. It was a ‘game’ I wrote! That makes it special, even if it is just moving a red circle around.

When another red circle appears with another player’s name above it, that circle is elevated beyond mere geometry and into an extension of that person.

How it is moved by that person becomes the first form of expression, beyond any language.

Anyway, dramatics aside, here’s a screenie of me playing against myself. When I have one of a proper multiplayer session I’ll add it:


Brief details for those interested:

  1. When a player is moved locally, it sends “#playerposition”, followed by its location x and y to the server. 
  2. This information is then sent to all connected clients in the form “#playerupdate”, followed by that player’s name, x and y. The name of each player is associated with each listening thread on the server.
  3. When each client receives “#playerupdate”, it updates that player’s local entity’s target position with the new x and y. If that player doesn’t exist, it is spawned and immediately given its current target.
  4. Each frame, every local entity representing another network player is moved linearly towards its last target position received from the server. This gets around continuously streaming all positions all over the place, and each client need only send data when the local player actually moves.
  5. When a player disconnects, it sends “#disconnect”. The server then issues a “#despawn” command to all connected clients, followed by the disconnecting player’s name. Each client then removes the corresponding local entity.

I am aware that this is a very crude ‘move to target’ system that will only really work in obstruction free scenes. Anything more complicated like an environment made of corridors and squares like ‘dungeons‘ and pathfinding will have to rear its ugly head once again.

But thats okay, because it seems to get easier and simpler to implement each time it comes around.

If you’d like to help me test this, send me a tweet and we can arrange something!

If you haven’t heard, this is a Pebble Smartwatch. Mine is in the post somewhere between Heathrow and my house… But there is no post on weekends!

Instead, I’ve spent a lot of today setting up the Pebble SDK toolchain and dependencies on a Ubuntu Virtual Machine, and brushing up on my C++ so that when it arrives, I can make my own watch apps!

The fantastic thing about it is that it is completely open, and there are lots of code examples, which I can understand thanks to my tinkering with C and Java.

As a sample of what the community has already achieved, here is John Cleese as a watchface app. Source here.

John Cleese Silly Walks Watchface

Working on the server software some more, with some help from a friend, it now accepts up to an arbitrary (currently 10) connections, each one handled in its own thread. When the server manager gets a new connection, it passes the Socket to the new thread, which then handles all the I/O for that connection. When that client disconnects, it sets a ‘in use’ flag, which the server manager can then use to re-allocate it if all the other threads are busy.

Here’s a demo image! I’ll also release some source code for this stage, as a simple proof of concept before it gets too much more complicated.


The next step is to set up server sending messages from one client to another, and become a real server! At the moment its just a listener…

Here’s a link to the source code.

The next step in any game development methodology is investigating networked games, ones that run on multiple computers and communicate to coordinate a shared experience for players. To this end, I started looking into for communicating in Java program. This yielded good results, and after about an hour of tinkering, I can show the fruits of this surprisingly easy labor:


Eagle eyed readers will be able to figure out the chronology of events. Simply, its a brief back and forth, with me entering commands in the bottom window, and the server program on top reporting the reception of these commands. The client also shows the time taken for the round trip. I have tested this on another computer in my local network and it works!

Next step, a networked game! But first I think I should clean up the format of the messages here, as it maybe a tad confusing…

After a misadventure into making my Android game engine threaded for higher performance, (A two threaded app on a single core phone was destined to fail!), I decided to do the same on PC, where multi-core processors are the norm nowadays.

There are two threads: a renderer and a worker. The worker does all the calculations for the next frame, and the renderer draws all the game objects to the window. The worker starts the renderer at the same time as it starts itself, then waits for the renderer to complete before starting the cycle again.

On Android with a single core, the switching between threads contained so much overhead that the performance suffered greatly. However, on PC, it still seems to be good, at least for a simple scene. I’ll see how things pan out as the scene gets more complicated.

Here is a screenshot, with the worker thread limited to 65 FPS, for good measure.


In a moment not quite unlike hearing your programming lecturer has written a debugger for debugging a debugger, I decided to have a delve into Swing and AWT to produce a small tool that would enable me to make better use of Eclipse and the Android SDK’s features.

When I test an Android app, I can see the phone’s logcat of events via ADB (Android Debug Bridge). In the past, this has involved using the Android Dropbox app to download the .apk file generated by Eclipse whenever I click ‘Run’ or ‘Debug’ onto the phone and installing it. For every revision. This didn’t annoy me too much, because I had the Android SDK’s Virtual Device Emulator to test apps. This emulator is very slow however, so I only used it for testing for NullPointerExceptions, which would render the time spent installing a revision via Dropbox a waste of time.

I have recently learned that I can run a new revision directly on the phone wirelessly by using cmd at the Windows Run prompt, then using adb connect address. After doing this, the phone shows up in Eclipse’s DDMS perspective, including the logcat!

Therefore, the only logical conclusion is to make a Java application that can do this for me. Presenting the latest in SELNP (Slightly Enhanced Late Night Productivity) technology, ‘ADB Connect’!

ADB Connect

It basically runs the command prompt command for me. Useful, and saves a minute or two. I learned a good deal about Swing and AWT doing it, so time well spent for future endeavours.