Category Archives: Java

Kite Physics

I’ve finally managed to finish the Kite Physics Demo I started back in October:

Kite Physics Demo

It’s more of a plaything than anything else. It did give me a chance to try out writing some physics code again, something I don’t get much of a chance to do during web development. Though of course advances in Javascript speed and the Canvas tag may change that in the future.

Originally I made use of the keyboard to control the figure and the kite, but I switched to using the mouse as it makes interacting with the scene more pleasing. There’s a certain joy to being able to grab the kite to move it around or shift the wind direction by nudging a cloud.

It’s all written in Java, using maven to build and package. The code is available in my kite repo on guthub.

There’s about one third of a physics engine in the code. There’s no real collision detection for example. Most of the physics code is for handling constraints and basic forces. For the constraints I made use of the Gauss-Seidel technique, as outlined in Advanced Character Physics by Thomas Jakobsen. This was quite a revelation to me. Previously I’d experimented with rigid body dynamics (see my 2D racing game circa 2001), but the Gauss-Seidel method seemed much more intuitive. I found it much easier to think of bodies made up of points connected by lines. The “physics” naturally emerges from the way the bodies are then constructed.

The core physics code (in the com.psychicorigami.physics.* package) is fairly well structured. There a bit of compiler placation to (theoretically) allow for the same code to work for 2D and 3D physics. I’ve only actually implemented the 2D side of things, but have tried to use generics to make room for 3D too. When everything is points and lines, moving from 2D to 3D is not that tricky. Whereas for rigid body dynamics this can mean quite a big change in representation.

The code in the default package is used for the specifics of the demo itself, so is a bit messy really. Lots of tweaking and prodding was needed to get things how I wanted.

The physics for the kite and wind interaction were aided massively by this guide to forces on a kite. Particularly useful for understanding how to tweak the rigging, centre of gravity and centre of pressure of the kite to make it behave in a pleasing – if not entirely realistic – manner.

At some point I hope to revisit the physics code here. I’ve always had a wish to create something like Karl Sims “blocky creatures”, but lacked the specific technical knowledge. Know that I have a technique for simulating complex constraints in an intuitive manner maybe I’ll manage it yet.

Kite Physics Demo

I’ve been working on a little kite physics demo app:

After chatting with Allistar at the £5app about how he did physics simulations I was pointed at “Gauss-Seidel” as an easy way to handle constraints. This led me to Advanced Character Physics by Thomas Jakobsen, which explained it all very nicely. That coupled with some info from NASA on forces on a kite helped me create this simple 2D “simulation”.

It’s not yet finished, but I thought I’d share some of my progress. I want to turn it into a slightly more rounded demo or perhaps even a simple game of some sort, with some scenery etc. I’m quite happy with how it’s turned out so far – even though I did waste a fair bit of time getting drop-shadows working…

It’s all written in Java, so it’ll be nice and easy to put online later. I think I’ll probably release the source too, as the physics and constraints code is fairly generalized. In fact through the use of generics and a few other tricks the code is setup to allow (potential) re-use for 3D physics too.

A 5K Java Guitar Tuner

So after writing a 5K Twitter Client, a 5K TODO app and a 5K Fullscreen Text Editor I thought that’d be enough example apps to get things started. However while adding a list of app ideas to the 5K App page I suddenly decide that one of the ideas really appealed. The idea was to write a guitar tuner, that would listen on the computers mic and show the user what pitch it thought the note played was. I’m not much of a guitar player, but when I do play it’s always nice to have a guitar that’s in tune. As I’m unable to tune a guitar by ear I rely on guitar tuners and I always seem to be out of the 9V batteries my electronic tuner needs. Given my laptop is usually nearby, being able to use it as a guitar tuner would be most useful.

Check out the video below or download 5KTuner for yourself (requires Java):

The app is more or less non-interactive. It simply starts up tries to work out what note is being played. It shows a simple slider that moves according to what note is being played and indicates how close to that note you are. In addition the raw frequency (in hz) is shown, as well a chart that shows the autocorrelation function of the input sound. A red line is drawn on this chart when a “valid” note is heard and indicates the wavelength of the overall frequency.

The vital statistics are:

  • Final (obfuscated) app size: 3538 bytes
  • Final (un-obfuscated) app size: 4649 bytes
  • Final Source-code size: 8532 bytes
  • Lines of code: 245

This was my first foray into audio programming and I’m grateful that in the end it wasn’t too tricky. Initially I’d been looking into using the Fast Fourier Transform to work out the frequencies, but the autocorrelation function was much easier. It’s essentially just two for loops and a bit of maths. You listen for a certain amount of audio and then compare the first half of the sample with itself, but shifted. By working out the amount of shift where the difference is smallest you can find the overall frequency of the sample.

It could probably be made more robust, but if you want to see how it works (or improve it) you can download the source code.

A 5K Twitter Client

So as part of preparations for the 5K App I’m writing a few example apps. The first one so far is a 5K Twitter Client, which makes it smaller than the Twitter logo itself (at 5.4K).

Check out the demo video to see it in action or download 5KTwit (requires Java):

The features are:

  • Update twitter status
  • View friends timeline (new tweets checked for every 3 minutes)
  • Easily change logged-in user
  • Count of characters remaining when typing status message

It doesn’t handle viewing direct messages, but I don’t tend to use them. Plus I wanted to make sure the features I had were done fairly well.

Anyway, I thought it would be a good idea to walk through making a 5K app, as there’s a fair bit of stuff just needs to be done to make it feasible. It’s the sort of stuff you don’t normally encounter daily when working on “real” software – unless you’ve been working on mobile or embedded apps. Nowadays most programmers don’t really need to worry about the size of the code they write, so how to make something that’s less that 5K in size isn’t immediately obvious.

The Twitter app (which I’ve lovingly christened “5KTwit”) is written in Java and runs as a standard client-side application. For some good pointers on how to make a Java app that’s really tiny, but packs a punch you should probably start with these Java 4K tips.

Now for a few numbers:

  • Final (obfuscated) app size: 5119 bytes
  • Final (un-obfuscated) app size: 6400 bytes
  • Final Source-code size: 10398 bytes
  • Lines of code: 310

As you can see the difference between the obfuscated and un-obfuscated versions is about 1K, so obviously obfuscation is pretty key. So it’s worth starting of with a good obfuscator. For those going “what’s an obfuscator?” it’s basically a tool to optimise, shrink and scramble your code. Originally they were intended to make code harder to decompile (hence “obfuscate”), but also have the added benefit of shrinking the compiled code to. I used Proguard and that’s probably your best bet too.

Proguard does a pretty good job of shrinking your code, but it’s worth reading up on how it works, so you can get an idea of what code changes you can make to get the most effect. For example Proguard will inline (and remove) small private functions for you (so they effectively have no overhead), but only if they are only called in one place. In general you probably want to use a source-control system/backup changes so you can rollback when a change doesn’t result in smaller obfuscated code.

Here’s the config file I used for Proguard (running on OS X):

-injars      dist/5KTwit.jar
-outjars     obfuscated/5KTwit.jar
-libraryjars <java.home>/../Classes/classes.jar
-optimizationpasses 2
-keep public class T  {
    public static void main(java.lang.String[]);

Proguard does a great job, but it won’t stop you writing code that’s bigger than it needs to be. In order to get the app under 5K I only used two classes (one for the main window and one for the username/password dialog) and one resource file. Each additional file has some overhead associated with it. Not only will each file tend to have some standard header info etc, but even if it was empty it would increase the size of the packaged jar file. So really cutting down on the number of files used makes a big difference. During testing I made a simple HelloWorld application and that was 700 bytes or so in size with a single class file and no real code. Most of that size would have been taken up with this sort of overhead.

As this app used swing for the GUI it also meant I had to be a bit creative about event handling. The norm is to have small event handling classes, but that would have incurred too much overhead. Instead I resorted to tricks like this:

    public void actionPerformed(ActionEvent e) {
        if ( e.getSource() == prefs ) {
        else {
            String status = this.status.getText();
            if ( status.length() <= MAX_CHAR ) {
                tweetsDoc = loadDocument("", status);

Where I checked the source of the event to see which button had been pressed, rather than having a separate event listener for each button.

I also had to deal with listening for window resize events, as there was some manual intervention required to make tweets wrap inside the scroll pane. So for that I circumvented the listener approach entirely and overrode processComponentEvent. In this code I had to try to estimate how big the panel containing the tweets would be, when I knew the width I wanted. So I resorted to a bit of nasty hackery and repeatedly set/unset the preferred size a few times so it would settle on the right height…

    protected void processComponentEvent(ComponentEvent e) {
        if ( e != null ) { super.processComponentEvent(e); }
        // force width of tweets to match width of window
        for ( int i = 0; i < 3; i++ ) {
            int height = tweets.getPreferredSize().height;
            tweets.setPreferredSize(new Dimension(scrollPane.getViewportBorderBounds().width,height));

Whereas in "real" code this would probably be done with a bit more finesse (and a few more classes).

Another tricky spot involved the background thread used to check for new tweets. This ran on another thread (rather than the main GUI thread), so as not to lock up the GUI when it runs (once every three minutes). However updating the GUI had to occur on the GUI thread. Normally this would simply be done by creating a few Runnable tasks, but that would have meant more classes. Instead I end up checking to see whether we're running on the GUI thread and change behaviour if that's the case:

    public void run() {
        if ( SwingUtilities.isEventDispatchThread() ) {
            // update UI as running on the right thread
        else {
            while( currentThread == Thread.currentThread() ) {
                String friendsTimelineURL = "";
                if ( lastTweetID != null ) {
                    friendsTimelineURL += "&since_id=" + lastTweetID;
                tweetsDoc = loadDocument(friendsTimelineURL, null);
                try {
                    // invoke and wait, to run loadTweets()
                    // on awt thread
                    Thread.sleep(1000*60*3); // 3 mins
                catch( Exception e ) {
                    // break loop

There are probably quite a few other places where I had to make this sort of "design" choice. It's feasible to do for this little code, but I wouldn't want to do this kind of thing in a big project. Though I guess if it was really needed you could write something that would take nice well written code and convert it to use these sorts of tricks...

Apart from that, most of the rest of the work came down to carefully weighing up which features I wanted and carefully tweaking and re-organising the code to make it smaller. I also found that the single image (for the preference button) was a lot smaller when saved as a gif rather than a png (90 bytes vs ~200 bytes).

Anyway, for 5K it's not a bad little client. I've actually been using it for the past couple of days (as I've been writing it). I doubt it would really survive under the hands of a more active user, but it does the job.

Java Psion Link – post-mortem

Quite some time ago I started a project to create a Java version of PsiWin. This project was Java Psion Link.

A little background

PsiWin was the bit of software that Psion provided to communicate/sync/convert files between a regular PC and their (now defunct) PDAs – such as the 5mx, Revo and netBook.  You connected your Psion to your PC with a serial connection (RS232) and could then treat the Psion like a disk on your PC.  You could navigate the Psion’s file system just like any disk and transfer files.  In addition you could use PsiWin to open and convert Psion’s native/custom files in normal Windows applications.

I myself owned a netBook and really enjoyed having it. It was a really small laptop that I could carry around with me easily. It even came travelling with me and had enough power to let me noodle around writing compilers and all sorts on the road. In retrospect it was a bit pricey, but it was still a wonderful machine. I’ve been eyeing up the EEE PC in the hope that it’ll make a good replacement for my netBook. Though I’m probably going to wait for the bigger screened version to come out, as then it’ll at least have the same screen size. Shame there won’t be a touch screen on it…

There is still quite a thriving Psion community out there – well over five years since the last Psion rolled off of the production line.  People loved their Psions and rightly so.  These were fantastic machines, that unlike other “PDAs” were fully functioning computers and weren’t totally reliant on having a PC to act as a mothership.  In fact saying “people loved their Psions” is probably the wrong tense – people still love their Psions and continue to use them.   Even now I’ll still have the occasional mail about using JPL and looking at the sourceforge site shows people are still downloading it.

Version 1.0

So the one main problem I had was that I had an iMac, running MacOS 9 and PsiWin would only work on a PC.  This was around 2000.  There was a Mac version called MacConnect, but it only handled file transfer and came on a 3.5″ disk.  My iMac didn’t have a 3.5″ disk drive and didn’t feel like having to buy MacConnect (when PsiWin was free with the Psion) _and_ have to buy a USB disk drive.  So for quite a while I persevered with using the Comms app on the Psion to transfer files directly over a USB serial port adapter, as well as transferring files via compact flash (CF) disks.

Then I stumbled on some reversed engineered documentation for the “Psion Link Protocol” (PLP).  Without that documentation I would never have started writing JPL.  Even with this documentation it was quite a lot of hard work getting everything going.  I did finally get my head around hexadecimal notation.  Not bad for someone who’d done AI and no regular CS at uni.

Version 1.0 of JPL more or less worked, but was a bit flaky.  It’d crash and bring down the VM and sometimes even the mac itself!  It also suffered from being a bit of a hack job – I wrote enough to get it working, but didn’t really go back and rewrite things and refactor.

Still I put it online and had a few people downloading it and then started getting mail about it.  There’s a lot to be said for having people actually using your software – even if it is a bit flaky and needs some work!

However at about that point I took a year to go travelling in Australia, so development on JPL ground to a halt.  I did have the netBook in tow though and had got a java compiler working on it.  So with that and a gsm modem vaguely kept my eye on things.

Version 2.0

I started coding version 2 of JPL in a bar in Ko Pha Ngan on the netBook itself.  I couldn’t run the code of course, but I was able to get a lot of the structure down and compile the code.  In fact the code I wrote then still lived on, though greatly modified, into the version of JPL 2 I finally released.

I created myself an API for the Psion Link Protocol to code the GUI application against.  I was able to create input and output streams to write to individual files on the psion, so I could treat it like it’s own file system.  It took quite a bit of effort to make that happen, but it greatly simplified writing the overall application. I was effectively writing my own library for accessing the psion and also writing an application to use that library.

Of course I never quite achieved the level of separation I’d have liked.  In retrospect I wish I’d actually treated JPL as two projects.  I could have then released the library for other developers to use and then coded the GUI like I was a user of the library.  Hopefully this would have meant the core library would be quite small and focussed.

Another thing I wish I had done was to have actually made use of unit-testing in JPL.  At the time I had no real experience of unit-testing, but since then have come to realise how useful automated tests can be.  It would of required a fair bit of thought in some places though.  Programming in Java would have required me to carefully consider how to mock-up a serial port and so on – no monkey patching to get you out of jail in Java!

At the time though Java was a pretty good choice for me.  The language is receiving quite a lot of flak nowadays, but I’d spent two years previously chained to a C++ compiler.  Java by comparison was markedly more productive.  Plus it meant that I could get JPL running on the Mac, Windows and Linux.  The much vaunted “write once, run anywhere” paid off in my case.  Which is not to say I could just ignore platform differences, but it meant that the app was essentially functional on the three major platforms with little extra work.

As my main development platform was a mac I spent extra time exploiting some of the extra features of the mac’s java runtime (MRJ).  This meant that JPL was able to better act like a regular mac application.  By using java’s reflection api I only had to create one version of the code.  JPL would detect whether certain classes were available and if so expose extra features to the user.


The real-world

JPL was for the most part a hobby project.  I did get donated a Revo and a 5mx for testing and a little bit of funding at one point.  This helped get at least one more release of JPL out, but in the end the real-world got in the way.  In particular I started my MSc.  Though I was able to spend some time working on JPL during this period I couldn’t really spend too long on it.  Taking out a career development loan to fund your further education does kind of sort out your priorities like that!

I also found that I was using my netBook less and less, so JPL itself was not as useful to me.  So like many open source projects, once I lost interest the incentive disappeared and work ground to a halt.  Which is not to say anything would have been different if I’d been running JPL as a commercial project.  I’m not sure there would have been enough users to have supported the cost of extra development.

Still it was an interesting project to have worked on.  It represented my first real “large” project outside of work and academia.  Since then I’ve always felt a need to have something I’m working on in my spare time.  Something to hone my skills with.  JPL was very useful for keeping my knowledge of Java up-to-date.  Now that I’m mostly coding in Python at home, having little side-projects is a great way to get some extra experience.  The trouble with most day-jobs of course being that you actually have clients and deadlines – so exploratory coding often goes out the window.

There’s nothing quite like trying to create something useful on your own time.  Writing software from beginning to end by yourself can give you insights that you might otherwise never get.  I’d thoroughly recommend it.

Class of the day: ConcurrentHashMap

Well today at work involved me using ConcurrentHashMap and in particular putIfAbsent to severely reduce the need for old-school synchronized blocks.

Just a shame that you can’t pass in arbitrary expressions/blocks that will only be evaluated if the value isn’t present when you call putIfAbsent. Might become feasible if Java gets closures. There’s definitely some power in the java.util.concurrent package though.

Still it’s been a while since I’ve had that kind of satisfaction writing Java code.