michi's log

Recently I am very interested in creating a small game for Android. Since every game needs a proper working gameloop and a underlying drawing mechanism I started to look at some examples from the internet. My first attempt in searching a good example lead me to the Android Developers page. There is a good description on how to get started with 2D graphics. I decided to take the threaded aproach as described there. This means that there is a thread that draws everything into the view as fast as possible while not blocking the UI thread.

Some further poking on the Android Developers page lead me to the Lunar Lander example which looked right what I wanted to do. I installed it on my HTC and played around with it a bit when I suddenly received this error message:

What happened? To put it simple, there is a bug in Google’s Lunar Lander example. Let’s look at the implemenation of the thread that draws the game in LunarView.java and how it’s started:

1
2
3
4

public void surfaceCreated(SurfaceHolder holder) {
	thread.setRunning(true);
	thread.start();
}

The method surfaceCreated() is a callback method from the SurfaceHolder class. It is called whenever the Surface we want to draw on is created, for example when the application starts or when we return from a pause. Respectivly the method surfaceDestroyed() is called whenever the surface is destroyed, for example when the application terminates or another application gets the focus.

1
2
3
4
5
6
7
8
9
10
11

public void surfaceDestroyed(SurfaceHolder holder) {
	boolean retry = true;
	thread.setRunning(false);
	while (retry) {
		try {
			thread.join();
			retry = false;
		} catch (InterruptedException e) {
		}
	}
}

In the Lunar Lander implemention the drawing thread is terminated on the first time the surface is destroyed. If we then try to come back to the application, for example with a long click on the home button, the application throws this exception:

java.lang.IllegalThreadStateException: Thread already started.

We reached an illegal state because a thread is only allowed to be started a single time!

To fix this issue I don’t stop the drawing thread in my application if the app looses focus. Instead I just stop drawing and let the thread sleep for a while (and thus save the CPU resources etc). When the app gets focus again, the drawing starts over. In the example below this behaviour is controlled by the paused variable, running is the variable that is set to true when the game starts and is set to false when the app is terminated and the thread really needs to stop:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

@Override
public void run() {
	while (running) {
		while (paused) {
			try {
				Thread.sleep(50L);
			} catch (InterruptedException ignore) {
			}
		}
 
		Canvas canvas = null;
		try {
			canvas = holder.lockCanvas(null);
			draw(canvas);
		} finally {
			if (canvas != null) {
				holder.unlockCanvasAndPost(canvas);
			}
		}
	}
}

I’ve implemented this gameloop in a small example that displays Conway’s Game of Life:

Of course my implementation has a fixed timestep as suggested by the famous article Fix Your Timestep!

Download my example sourcecode here: android-gameloop-example-v1.zip
App in the Android Market: Gameloop Tutorial

There is a really useful setting hidden in the shallows of putty’s configuration menu. It allows to set an interval after which a keepalive message is sent to the server to prevent random disconnects. That saved me a lot of reconnecting…

In my current project I make heavy use of logging. To be able to customize logging I am using log4j. Unfortunately LWJGL doesn’t use a log framework of any kind and just outputs on the console via System.out.println(). To add these outputs to the logfile or a log4j console appender one has to reroute the output through log4j. Luckily there is a pretty easy way, I found it in a stackoverflow posting. So how does it work? There is a Java API that allows to set a new PrintStream for System.out and System.err:

1
2

System.setOut(PrintStream stream);
System.setErr(PrintStream stream);

So we simply have to add our own PrintStream implementation that calls the logger and we are done:

1
2
3
4
5

new PrintStream(realPrintStream) {
    public void print(final String message) {
        LOG.info(message);
    }
}

LOG would be our log4j Logger.

Hurry up! There is not much time left to buy the awesome Humble Indie Bundle #2. It’s a bundle of five awesome indie games: Braid, Cortex Command, Machinarium, Osmos and Revenge of the Titans. One very cool thing about this bundle is that you can pay as much as you like for it and even decide to donate a part of the money! Or just make a friend happy: It’s also possible to give it away as a gift. If you pay more than the average, which is around 7.68$ at the moment, you also get all the games from the first bundle. What an incredible deal!
There is a teaser video:

In Eclipse there is this wonderful little helper for adding Javadoc links while you’re typing a class name. It looks like this:

It suggests not just to put the classes name there but also use a @link tag so one can navigate the Javadoc sources later on. The finished comment:

Unfortunately this functionality is not available in JetBrains’ IntelliJ Idea. There is (of course) auto completion for classnames in Idea but it simply doesn’t put them in a @link tag. A simple trick saves the day: simply create a live template with context ‘Java comment’ like here:

EDIT: The screenshot is missing the word ‘link’. The complete template should be: ‘{@link $LINK$} ‘.

Don’t forget to click on ‘Edit variables’ and fill in ‘complete()’ as Expression. This activates the auto completion for classnames.

Now everytime a @link in the Javadocs is needed we invoke the Live Templates with Alt + J and enter a classname. The @link tag will be build around that name. It’s not as simple as with Eclipse, but works pretty well.

“Immediate mode rendering is dead” is the title of a topic on the Javagaming Forums I’ve been following the last two days. It is a really insightfull discussion about the use of Vertex Buffer Objects versus Vertex Arrays and the Immediate Mode.
One says the internet doesn’t forget and that is especially true for tutorials concerning OpenGL which have been around for a very long time now. Most of them start by showing how to draw simple geometry using the Immediate Mode and most people posting in the mentioned topic agree that this is the wrong thing to start learning with, at least nowadays.
The topic also includes some example code and benchmarking what methods and ways seem to be the fastest. The contributers just started comparing benchmarks and didn’t go very deep, but I really hope that there will be deeper insights revealed.
The whole discussion actually started here: Sprite!, where princec (from Puppygames) is writing about his sprite-engine. Also a very interesting read!

Almost two years ago I started saving the pictures of a webcam that shows the construction site of a new building at the university of Ulm. Meanwhile I got a collection of almost 50.000 pictures that take up 12 gb of my harddisk. I decided to make a new video. Like the last one this is only generated by a fraction of that pictures, namely the ones taken at 10 and 12 o’clock in the morning each day. Have a look:

It has been a while since I last used Vertex Buffer Objects (VBO) with LWJGL. It seemed as if they had changed some of the method signatures since I used them last time. I couldn’t even get the simplest example running. After experimenting for a while I finally figured it out. Have a look at the signature of the VertexPointer method:

static void glVertexPointer(int size, int type, int stride, long pointer_buffer_offset);

With the last offset one can specify where the vertex information starts in the buffer given to the VBO management. Well, I could/should have guessed that this offset has to be in bytes since I am dealing with a buffer here but instead I used the number of floats.. So next time I see an operation dealing with buffers that takes a long argument I’ll try the byte-count from the beginning..

Seit nunmehr einem Jahr speichere ich die Bilder, die eine Webcam über der Baustelle der neuen Uniklinik in Ulm macht. Das letzte Zeitraffervideo habe ich im Dezember 2008 erstellt und nun war es Zeit nochmal eines zu machen. Diesmal ist es etwas kürzer, da ich nur zwei Bilder pro Tag verwende.

Für die volle Pracht auf den HD Button drücken!

If you are using Meggy Jr with the Serial-to-USB Cable provided in the Evil Mad Scientist shop you might encounter the following error:

avrdude: stk500_getsync(): not in sync: resp=0×00
avrdude: stk500_disable(): protocol error, expect=0×14, resp=0×51

The error manifest while uploading a new sketch to Meggy. If you pull out the USB cable and plug it in again you can upload a sketch successful. But on the next time you try you’ll get the error again. Luckily there is a pretty simple solution. I found it while digging through the Evil Mad Scientist Forums. It involves setting the “Set RTS on close” flag of the COM Port. You can do this in the Device Manager. Find the COM Port that was installed when you first plugged in the USB-to-Serial cable. For me it’s COM3. In the connection settings click on details and mark the flag selected. That’s it. I tried this on Windows XP with Service Pack 3, but it should work similiarily on other Windows versions.

RTS Flag