Accessing Joysticks from JavaScript

Many years ago I wrote a simple browser plug-in to access game controllers from JavaScript. It was Windows only, worked in IE and Netscape 4, and it was used by quite a few JavaScript games at the time (with thousands downloads per day at its peak in 2001, mostly thanks to Scott Porter's JavaScript games). Years passed and it remained largely forgotten, with a few folks still finding it useful for robotics and other specialised cases, but no longer for games. Last year I found myself interested in the project again and decided to update the code, developing versions for Firefox on Windows and Safari on OS X, with the source to all now available under an LGPL license on Google Code (along with prebuilt installers).

Examples of using it from JavaScript, Flash and Java can be found in the project's examples folder; they're quite simple and documented, but in brief, to use it from JavaScript add joystick.js to your page:

<script type="text/javascript" src="joystick.js"></script>

Then create a new Joystick instance, which takes care of inserting the correct type of plug-in into the browser (ActiveX control for IE, NPAPI plug-in for everything else):

var joy = new Joystick();

That's about it! Using it in your game is a matter of reading the controller's axes and buttons wherever you would normally read the keys:

var joyX = joy.getX();
var joyY = joy.getY();

Using it from Flash is slightly more complicated due to having to access plug-ins via ExternalInterface, but the ActionScript Joystick class hides most of that away. Accessing it from a Java applet uses LiveConnect, but again the sample code takes care of this.

So, what are you waiting for? Bring on the games!

Opposite Lock Updated Downloads

Following on from last year's release of Opposite Lock under a GPL license, the full game is available to download from the project's site. The files are the 1.3.4 release from June 2007 (the last commercial release) and are optimised versions of what's available in the repository.

Use the cursor keys and space to play in the above applet (you can also select menus using the mouse). The applet is the J2ME code running using a thin MIDP2.0 wrapper written (originally) to test the game's AI.

J2ME Director Player

No code this time round, just a quick «look what I done!» This started life as a cut scene player for a (still unreleased) cutesy puzzle game, which was then recycled for the animations in Football Manager Quiz. It uses similar techniques to the mode 7 renderer (posted a while ago) in order to draw the real-time transforms. Animations are exported from Director, reduced to a compact binary form, then played back in pure Java on the phone. The video shows a (rather aged) K750 and a (slightly newer) K800 in action.

Opposite Lock GPLed

Something a little more substantial than a snippet for this latest instalment... an entire mobile Java game! Opposite Lock's source code is now available on Google Code under a GPL license. Check the sources out of SVN (the 'jsr' trunk is the only active one for now) and it should build as-is with Eclipse and EclipseME. Go on! What are you waiting for?!

Okay, where's the catch? Well, whilst the Java source is exactly the same as the published version, I've only included three of the 10 tracks (as per the free demo version). That's the only difference. When the game sales finally peter out I'll release the art assets under a Creative Commons license and commit the missing tracks to the repository.

So, now you have the source how do you create your own tracks? For that you'll need the editor and build tools, available from the project's download page. I'll be cleaning up and adding the source for these to the repository in good time.



I wrote this between 2004/5, originally released as Jet Set Racing (which will explain why the letters 'jsr' appear everywhere). Opposite Lock is a reworking of this earlier game engine with new graphics (and new code to handle the expanded tracks). The tools are all pure Java and run happily on Windows and Mac OS.

J2ME Mode 7 Floor Renderer

Following on from yesterday's fixed point maths routines, here's a little demo which builds on that. It's another oldie, again from around 2002/3, which I've used in a more advanced form on quite a few projects. It's a very simple texture mapper, visually in the style of the SNES's famed mode 7. Given a 2D map, it presents the image as a horizontal texture mapped surface. It's primitive stuff but can be used to quite nice effect, and with it being entirely software based it doesn't require any additional APIs on the phone.

Grab the source and take a look at Renderer.java. Most of the work is done in renderFloor(), which simply works out a pixel offset for each scanline and fills the buffer accordingly. I've taken out some of the optimisations so it's easier to read, but even still it's no slouch!

Java Fixed Point Maths

One of the first things I wrote when I started J2ME was a set of fixed point maths routines. I've seen quite a few others over the years, for Java and other languages, and they all seemed to follow the same pattern: sin and cos tables, plus a few methods for basic operations (multiply and divide, usually). The one I offer here, which in various guises and languages has served me well since forever, is a little more advanced (not much, but enough for most mobile games and applications).

The sin and cos (and by extension tan) routines are still table based, but instead of providing the table in-line with the code, it's generated using recursive synthesis at runtime. The advantage here is that the class can be quickly tailored for less or more fixed point precision, depending on the use (16.16 for general usage, 12.20 for audio work, etc.). There's also a fast atan, which was most useful for the physics and AI in Jet Set Racing (seen here, and Opposite Lock, seen here), plus a few other bits and bobs.

Most of the algorithms I devised myself, unless otherwise noted in the comments. The precision is pretty good (I have a test suite for it somewhere) but don't go taking my word for it, find out for yourself!

Streaming Audio on J2ME

For years I've been wanting to create a circular audio buffer for J2ME. Midi is okay but what I would really like is MOD playback, with maybe a few real-time sound effects thrown in, and generally a way of altering sound on-the-fly. I'd tried a mixer based on a blocking InputStream, which worked in Sun's WTK emulator but not on any actual phones (which load in the entire stream). I'd also tried a custom MMAPI DataSource, which didn't work either (same result as using an InputStream). I'd even tried the "switching between two Player instances" method, which although it (sorta) worked, wasn't low latency.

One idea I was hopeful about was running an RTSP (Real Time Streaming Protocol) server on the phone and playing the audio stream using MMAPI. This was interesting since the latency could realistically be as low as 1/25th of a second, perfect for generated sound and audio effects. I started by reading the protocol documentation (RFC 2326), along with RTP (RFC 3550) and SDP (RFC 4566), then by snooping the traffic between Quicktime and Darwin Streaming Server. The whole thing was hacked together in marathon coding session, then refined the following day. I'd like to end by saying "and it worked beautifully" but unfortunately whilst the server itself worked, playing the stream didn't work on any of the phones I tried. Grab the source code and have a play. Start the server running in WTK (or use the GCF implementation I posted earlier) and listen to the audio stream (which is just a rasping noise) in Quicktime, Realplayer, VLC, etc. Try the midlet version on a phone and you might get lucky... then again, you might not! I tried it in a few Sony Ericsson and Nokia phones, which I know can play back RTSP streams. The Nokia phones (6600, 6630) showed the most promise, since the loopback address appears to work, unlike the SE phones (K750, K800).

The server isn't the most elegant you'll ever see, and a better method would be to run the RTP part in a single thread, pumping out packets to all the connected clients. Then again, it was only designed for one client (the phone itself) and works well for this purpose. Like most of the code I'm planning on posting, I'm releasing it under a "do with it as you please, only give me credit for it" license. If you have any bugs, questions or suggestions, I'd like to hear them.