MarbleMice.com

Having finished writing a small game for Android I thought I would discuss the main loop code. I am fairly new to android so am not sure if this loop is ideal but here goes anyway.

As part of my abstraction layer I wanted to get away from thinking about Android specific code fairly rapidly. With this in mind I created my own state system and only used one activity for the game. I suspect a lot of Android game programmers do this.

One things that was not entirely obvious to me was how to get and update and render function called every x milliseconds, where x is something like 1000/30. The game then runs at a fixed frame rate. This has advantages and disadvantages which I won’t get into here but is certainly sufficient for my simple card based game I was creating.

To handle all this I created a GameView class that extended a View. Inside that I created a nested class that extends the Handler class

 class RefreshHandler extends Handler {

    @Override
    public void handleMessage(Message msg) {
      update();
    }

    public void sleep(long delayMillis) {
      this.removeMessages(0);
      sendMessageDelayed(obtainMessage(0), delayMillis);
    }
  }

Basically whenever it gets a message we call our update function. The update function then call the sleep method on the handler class. The sleep() method sends a delayed message to itself that will be processed by the handleMessage method. This gives a loop with a delay time between each each update, think about it for a while if you are confused.

So within the GameView class we created an instance of the handler.

 RefreshHandler redrawHandler = new RefreshHandler();

The update function looks a like this.

 public void update() {
   long now = System.currentTimeMillis();
    if (now - lastMove > MOVE_DELAY) {
      states.get(currentStateIdx).update(this);
      lastMove = now;
      invalidate();
    }
    redrawHandler.sleep(MOVE_DELAY);
  }

We check a minimum time has passed and also call invalidate that causes the view to be redrawn.

I have not check on the accuracy of doing this sort of game loops. It works well for slow or turn based application but if you are writing and arcade game then you will probably need to look at timing more carefully.

Finally we need a start method that calls redrawHandler.sleep(1000/30) to start the whole process. In this method I also set up all my game states and so on.

I am not taking credit for this code for the most I just rummaged around on the Internet to glued this together. I may have reused code from many places like the JavaGaming.org, CokeAndCode.com or some other random place. Hopefully this quick overview will save you having to rummage around quite so much.

This one caught me for a while. I could not figure out why layout_weight was having a weird effect. My simple UI is currently made up of a vertical LinearLayout that contains a series of horizontal LinearLayouts, 5 to be exact. I want the 3rd one of these horizontal layouts to consume all the spare vertical space. Think of the third layout as containing a couple of editor panes.

Anyway this sounds instantly like a job for layout_weight attribute. This attribute when set ditributes the free space according to the weight of each View/Layout. The default value is zero so setting the layout_weight to one should have let my “editor panes” consume all spare vertical space. It didn’t when I did this lots of UI elements disappeared! I was stumped.

Only when pulled right back and created an example test layout to figure out what was going on, it all worked. Turns out if you set and of the layout_height to “fill_parent” then they fill the parent and ignore the layout_weight. Makes sense when you think about it. You say fill_parent and it does. It seems that I had them all set to fill parent and for some reason it displayed everything ok until I started to set layout_weights. At least this one won’t trip me up again – Don’t mix the fill_parent and layout_weight attribute.

I have finally completed Pro JavaFX Platofrm. August is a month of reading I have ploughed through 3 books and have done much programming done.

Pro JFX, as I call it, is a well written book that covers version 1.2 of Java FX. although there are 4 authors their styles are close enough that I only occasionally noticed a change in writing style. The information contained in it seems complete. The core language is covered followed by the core libraries along with many examples. A chapter is devoted to mobile development and one to open source libraries that are available.

Overall well worth buying even it at the moment I am so time pressured I am reluctant to put the time in to do a full review.

Reading a few blogs seems to indicate that large scene graphs seriously hit performance. Is my little game hitting this? I certainly hopped not as I don’t have that many nodes.

The number I picked up from some blogs was that things go slow at about 256 nodes. Lets see I have 2 grids of 5 by 5 nodes each of these nodes contains 2 other nodes. That makes 75 nodes in total. We then have a couple of container nodes and some buttons on screen. I don’t know how many nodes are in a standard button but lets overestimated at 10. I am still struggling to break the 150 mark.

Well all nodes might not be even. I commented out the two grids to see how well it performed. To my surprise it things got significantly smoother. Wow I was not expecting that, I should have been as I use effects on the these grids.

It is funny isn’t it, 20 years ago I could get more action going on the screen using basic on a 8Mhz machine. Admittedly they were bitmaps at a much lower resolution but given Moore’s law I found it quite amusing as the computer I now own are capable of doing real time ray tracing but not rendering a few  moving squares smoothly using JavaFX.  I am sure JavaFX still has a lot of low hanging performance enhancing fruit to be put into the compiler, it is still at a very immature stage of a compilers life so I am not going to beat it up too much.

Besides I was working on the assumption I was doing something wrong, the bubble mark benchmark seemed to indicate I was.

My first find was putting canSkip:true into KeyFrames. This blog entry explains what the canSkip attribute means. canSkip made the game a whole lot smoother.

Next up was turning off the effects I had applied to nodes. It made the graphics look a little rubbish but the plan is to replace them. Nodes finally start to scroll around smoothly, acceptable at last.

So the tips are.

1. use canSkip, I cannot think of a time in game development when you would not want this set to true.
2. Be careful using effects.
3. From reading about the bubble mark optimisation, use bitmaps where possible.
4. Keep a contant eye on performance.

Other than the canSkip tip they are pretty obvious, what caught me out was I was not expecting to hit problems with such a simple scene graph. If I had been doing something more complex I would have expected trouble and instantly gone for bitmaps rather than vector graphics when possible.

Anyway it is time to draw some graphics for the game.

I have a love hate relationship with emacs, for the past few months working with clojure and emacs has been fun. As my programs start to grow in size I feel the need for a more integrated IDE.

My eye turned to enclojure, it is certainly in early stages and it seems the selection of keyboard shortcuts seems a little bit wrong to say the least. They map to the ubuntu change screen shortcut and some even map to keyboard shortcut already defined in netbeans.

It is also quite buggy.

Having said that is does work and has potential. After one night use if seems, err, usable. I look forward to some updates to it. Over the next couple of weeks I shall use it as my default editor and see how it goes.

I did actually try to download and compile the code for the plugin, with perhaps an eye to seeing if I could fix some of the bugs. They don’t seem to have placed all the dependencies into their subversion repository and tonight I was not in the mood for manually downloading jar files. Come on guys make it easy for others to build your code.