First, let’s define a bunch of useful functions.  We’ll later use these functions to extract the relevant sections of our ID3 tags.  I’m going to assume you are using your interpreter directly, so lets copy & paste the following lines straight into your terminal:

function tag() { tail -c 128 "$1" | head -c 3; }
function title() { tail -c 125 "$1" | head -c 30 | rtrim; }
function artist() { tail -c 95 "$1" | head -c 30 | rtrim; }
function album() { tail -c 65 "$1" | head -c 30 | rtrim; }
function year() { tail -c 35 "$1" | head -c 4 | rtrim; }
function comment() { tail -c 31 "$1" | head -c 28 | rtrim; }
function track() { tail -c 3 "$1" | hexdump -ve '/1 "%02i "' \
                   | awk '{ if ($1 == 0 && $2 != 0) print $2" " }'; }
function genre() { tail -c 1 "$1" | hexdump -ve '/1 "%03i"'; }

function rtrim() { sed 's/\([^ ]*\) *$/\1/'; }
function filt() { tr -d '/*?'; }

Now lets say the current directory is full of MP3s that we would like to move to an appropriate folder and give a more appropriate filename (in my case, I had my corrupt old iPod from which I was attempting to extract all the music I could).  The structure I’m aiming for is:

ARTIST – ALBUM / TRACK_NUMBER ARTIST – SONG_NAME

Making use of our functions defined above, this for loop ought to do the trick:

for file in *.mp3; do [ "$(tag "$file")" == "TAG" ] && \
    (  artist="$(artist "$file" | filt)"; \
       album="$(album "$file" | filt)"; \
       title="$(title "$file" | filt)"; \
       track="$(track "$file" | filt)"; \
       dir="$artist - $album"; \
       newfile="$track$artist - $title.mp3"; \
       \
       mkdir -p "$dir"; \
       mv "$file" "$dir/$newfile"); \
    done

And indeed this “one liner” did a reasonable job on my MP3 collection, YMMV.

Of course this only works for ID3v1 tags and doesn’t support “extended” v1 tags.

I can’t imagine ID3v2 possibly being parsed in bash, but I’d like to be proved wrong

MHEG Player showing the Freesat Red Button homepage

Some very good news for all the MHEG developers out there, the BBC have this week open sourced the MHEG+ toolkit and it can be downloaded over at the MHEG+ SourceForge page.

The release comes with little in the way of tutorials and so it might all seem a little daunting at first. But having used (and worked on) the toolkit for a couple of years I think it is worth the initial effort and recommend you give it a try.

I intend to write a full getting started guide to help new users over on the MHEG+ SourceForge forum, but for now here are some code examples and an ultra-quick guide to getting the toolkit up & running…

Code Examples

There is a simple “Hello World” MHEG+ application downloadable from the MHEG+ subversion repository.

This blog also has two examples of MHEG+ code, see these posts #1, #2.

Ultra-quick MHEG+ getting started guide

The toolkit contains a compiler and an emulator. Currently both are available for download as a separate Java .jar files. You will need Java installed to use them.

To use the emulator/debugger, download the file named MhegPlus.MhegPlayer-1.0.1.jar and issue the command:

java -jar MhegPlus.MhegPlayer-1.0.1.jar

This will launch the Mheg Player GUI.

To use the compiler first download the file named MhegPlus.Compiler-1.0.1.jar. The compiler can invoked with the following command, but you will need to pass command-line options to get anything meaningful out of it:

java -jar MhegPlus.Compiler-1.0.1.jar

You can get help on the various compiler options by passing –help, e.g.:

java -jar MhegPlus.Compiler-1.0.1.jar --help
usage: mhegplus
-p,--output-app output application file? (optional)
-d,--output-dir output directory (optional)
-P,--output-app-sans-extension output application file as a or startup
(optional)
-l,--log-level log level
(FINE|INFO|WARNING|ERROR|SEVERE)
-a,--asn1 select ASN.1 output (default)
-f,--application application file
-h,--help print this help
-t,--text select text output
-v,--version report version number

Happy MHEG+ing!

It is a complete re-write of the engine used in my iPhone platform game and it achieves a much higher and more consistent frame rate. I’m currently very pleased to be getting a consistent 17-18 FPS running full screen on an iPhone 3G.

It is a scrolling tile-based engine, meaning it should suitable for most 2D games. I’d like to use it to create another platformer, or maybe a shoot ‘em up this time would be cool, but the engine could be used for other game types too.

I need your help! to turn it into a finished game. This is a call out to any artists who would like to get involved, please drop me an email with examples of your work. My address can be found on the about page.

I intend to release 2 versions of the game:-

• a demo version that runs in Mobile Safari but has no sound and few levels, and
• a full version that can be purchased from the app store.

Revenues made from the app store version would be shared with the artist, so there might even be a few dollars in it for you!

The game uses the HTML 5 Canvas element and a few iPhone-specific HTML/JS extensions. It should still run on most desktop and mobile web browsers however.

I’ve tested the game on an iPhone 3G and 3Gs. The 3Gs performs as well as a desktop PC which is some feat! The 3G on the other had is a little sluggish, but the game is still playable; if you’re using a 3G I recommend playing the game with your phone upright (portrait) for best performance, since in this mode the game aims to draw to a smaller area of the display.

It is also possible to play the game full screen, that is without the Safari address bar & toolbar, by adding the game to your home screen.

According to Liam Green-Hughes on Twitter, the game also runs fine on the Nokia N900, running Firefox.

See my earlier post for the history of the game, or to play the desktop version. As before I invite you to take a look at the source code of the game. Simply hit your browser’s “view source” button to read the code.

Click the Play link below (ideally on your iPhone!) and be sure to leave a comment with your thoughts.

Play!

Or go to this address on your iPhone: http://tinyurl.com/purplefloyd

Click to play

Nearly 15 years ago, when I was all of 15 years old, I wrote this little platform game which I have recently ported to HTML5/Javascript.

It’s a kind of Mario clone and at the time I named it “Fred Jones in Adventureland”… hmm, not a great name.

The themes of the game are intended to be tongue-in-cheek however. Hence the ridiculous title and deliberately unsubtle references to other games in the genre.

And it is somewhat incomplete; the player has unlimited lives and unfortunately there are only 5 levels. But as it stands it is playable and hopefully a little bit of fun. There are a couple of surprises along the way too.

Browser Compatibility

If you’re using Microsoft Internet Explorer 7 or 8 the game will run dreadfully slow. (Update: The game now supports the Google Chrome Frame plug-in. If you are using Internet Explorer I recommend you install it.)

Internet Explorer 6 and earlier, Firefox 1.x and I believe Opera 8 and previous will not run the game at all. This is because these older browsers do not support HTML5 (arguably, no version of Internet Explorer supports HTML5, however the game can run with the assistance of 3rd-party plug-ins and other workarounds). Please upgrade or switch to a different browser.

Controls

Left Arrow: move left
Right Arrow: move right
Spacebar: jump

iPhone Version

See HTML5 Platform Game for iPhone

Play!

Click the link above to play the game.

Technical Details

This is a port of the original game to HTML5/Javascript. This means it now runs in any modern web browser.

Unlike most web games the game does not use Flash. The HTML5 Canvas is used to draw the visual elements.

All the code for the game is all available to read if you hit “view source” in your browser and I invite you to take a look.

I was pleasantly surprised by the performance of Canvas drawing operations and javascript run-times in most modern browsers. However Internet Explorer users apparently will have to wait for version 10 before such features will grace the browser.

The game currently has no sound but this could be added using the HTML5 <audio> element.

Must have been a slow news day…

The post includes a video and screenshots of the games I’ve written during my “10% time” at the BBC.  This is time we are given — half a day each week — to work on our own projects and try to innovate.

The games are written in the MHEG programming language, a subject I often discuss on this blog.

Update: The post is now linked to from the front page of the BBC News Technology section.

Here’s the link.  The ‘Pong challenge’ section is the where it’s at…

Also see here for a video of the Pong game (the single player version), it’s the third game shown in the video.

The tools you are expected to use for this purpose are debsign and debsig-verify. Unfortunately I found the documentation for these to be pretty thin and ended up having to read the source of debsig-verify to work out what was expected of a signed package.

So hopefully to prevent others from having to trawl through source code, below are steps you could follow to sign your own .deb packages. My method is somewhat contra to the prescribed method from Debian, however it is the only way I’ve managed to get working.  Please suggest better methods if you know them.

The steps I performed were:

1. Create your GPG signing key, run
   $ gpg --gen-key
   and follow the steps.
2. Sign the .deb with your private key, without using debsign (please comment if you get debsign to work for you, I couldn’t…).
   1. Take an existing .deb and unpack it:
      $ ar x my_package_1_0_0.deb
   2. Concatenate its contents (the order is important), and output to a temp file:
      $ cat debian-binary control.tar.gz data.tar.gz > /tmp/combined-contents
   3. Create a GPG signature of the concatenated file, calling it _gpgorigin:
      $ gpg -abs -o _gpgorigin /tmp/combined-contents
   4. Finally, bundle the .deb up again, including the signature file:
      $ ar rc my_package_1_0_0.deb \
          _gpgorigin debian-binary control.tar.gz data.tar.gz
3. Export your signing public key and determine its key id.
   1. Export your public key:
      $ gpg --export -a > my-debsig.asc
   2. Extract the key id by taking the last 4 chunks of the fingerprint, CA58BC6A0695623E in this case. We always use it without the spaces:
      $ gpg --fingerprint
      /home/floyd/.gnupg/pubring.gpg
      ------------------------------
      pub 1024D/0695623E 2009-02-04
      Key fingerprint = 6577 AAB2 8850 9E0B 1059 C510 CA58 BC6A 0695 623E
      uid Purple (Floyd) <--your email address-->
      sub 2048g/EB122979 2009-02-04
4. Setup the machine(s) that will be downloading and verifying the package.
   1. Install the debsig-verify package:
      $ apt-get install debsig-verify
   2. Import the public key into the debsig keyring:
      $ mkdir /usr/share/debsig/keyrings/[key_id]
      $ gpg --no-default-keyring --keyring \
          /usr/share/debsig/keyrings/[key_id]/debsig.gpg --import my-debsig.asc
   3. Configure a policy for the key, policies are discussed in some detail in /usr/share/doc/debsig-verify. The policy file needs to be kept in /etc/debsig/policies/[key_id]/[policy_name].pol. Mine looks like this:
      <?xml version="1.0"?>
      <!DOCTYPE Policy SYSTEM "http://www.debian.org/debsig/1.0/policy.dtd">
      <Policy xmlns="http://www.debian.org/debsig/1.0/">

      <Origin Name="PurpleFloyd" id="CA58BC6A0695623E"
      Description="Another package from PurpleFloyd"/>

      <Selection>
      <Required Type="origin" File="debsig.gpg" id="CA58BC6A0695623E"/>
      </Selection>

      <Verification MinOptional="0">
      <Required Type="origin" File="debsig.gpg" id="CA58BC6A0695623E"/>
      </Verification>

      </Policy>

5. You should now be able to verify the package using debsig-verify, i.e.:
   $ debsig-verify my_package_1_0_0.deb
   debsig: Verified package from `PurpleFloyd' (Another package from PurpleFloyd)

Et voila! You have signed and verified a debian package.

Note: on most distros, dpkg/apt will not check the signature of a package when installing it, even if a signature is present. This checking can be enabled by removing the --no-debsig line from /etc/dpkg/dpkg.cfg.

A further aim of this part is to explain some more of the language features exclusive to MHEG+, including foreach loops, sequential blocks and ifs.

Adding our graphics to the scene

I have hand crafted the following 5 png graphics to use for this tutorial:

Using an MHEG+ foreach loop, we can add all these graphics to our scene in one fell swoop:

  foreach num (0..4) {
    {:Bitmap bmpPac<num> = [constPacObjectIdOffset + <num>]
     :OrigPosition          [(720 - 32) / 2] [(576 - 32) / 2]
     :OrigBoxSize           32 32
     :OrigContent           :ContentRef ('/tut/<num>.png')
     :InitiallyActive       false
    }
  } endfor

There a number of subtleties of this loop which are probably worth discussing:-

• foreach loops are preprocessor instructions, not run-time loops.  Because of this we can use foreach loops around object declarations, or in fact any code section at all.
• In this case, the contents of the foreach loop will be duplicated 5 times, this is controlled by the (0..4) range on the first line.  This range need not be numeric, text may also be used, for example: foreach key (red, green, yellow, blue) is allowed.
• The Bitmaps we declare will be named bmpPac0 through bmpPac4, <num> is substituted with each value in the range.
• The object identifiers for the Bitmaps will be 100 through 104, assuming constPacObjectIdOffset has the value 100.  We use the MHEG+ notation: objectname = objectid to declare both names and object identifiers for our Bitmaps.
• <num> is also substituted in the png filename

You may also have noticed that our 5 Bitmaps have :InitiallyActive set to false.  We will later call :Run and :Stop on our Bitmaps to control which frame of the animation is visible, so they do not need to be running at startup.  However we do still want to pre-load our Bitmaps when the scene loads in order to have them prepared in memory and ready to use, so we add the following to lnkStartup:

  // preload graphics
  foreach num (0..4) {
    bmpPac<num>.Preload()
  } endfor

Here we are using a foreach loop not for ingredient declaration but to duplicate a line of code in a link effect.  Again, <num> is substituted appropriately.

Drawing each frame

As in part #1 of this series, we will use the Link lnkGameTick to calculate and render each frame of our game.  The first thing we did in lnkGameTick is set the next timer event, this is to ensure our game runs at a fairly consistent pace.

We now extend lnkGameTick to call out to two sequentials.  The first sequential “calculates” the next game tick, the second renders it to the screen.  We therefore add the following to lnkGameTick:

  tgPac.CallActionSlot(calculateNextFrame)
  :LockScreen()
  tgPac.CallActionSlot(updateScreen)
  :UnlockScreen()

(Note: Games often separate the concerns of calculating a frame from rendering it.  In an environment other than MHEG this could allow us to choose whether to render the current frame (which is normally an expensive operation) to keep the game tick rate consistent.  MHEG however without precision timing does not allow us this freedom, but separating along these lines makes our code more maintainable.)

Note that we call :LockScreen and :UnlockScreen around the call to updateScreen.  This effectively tells the MHEG engine to render our new frame off-screen and display the changes only when we call unlock.  This is akin to Double Buffering and helps reduce screen flicker.

We still need to implement the sequentials calculateNextFrame and updateScreen, which I’ll describe in the next two sections.

Calculating what to display

For each game tick we need to determine what should be visible on the screen.  In the case of our animation of the ‘Pac’ character, this means determining which of our 5 Bitmap ingredients should be visible.

So the effect of the calculateNextFrame macro should be to modify an integer variable whose value will later be used to identify the Bitmap to display.  We’ll call this integer intNextPacObjectId.

Here is the necessary code:

  defSequential calculateNextFrame :Namespace tgPac {
  (
    // increment counter
    intCount.Add(1)
    intCount.Modulo(constNumFrames)

    // calculate object Id of Pac Bitmap to display this frame
    intNextPacObjectId.SetVariable(:IndirectRef intCount)
    :If (intNextPacObjectId >= constNumBitmaps) {
      intNextPacObjectId.SetVariable(constNumFrames)
      intNextPacObjectId.Subtract(:IndirectRef intCount)
    }
    intNextPacObjectId.Add(constPacObjectIdOffset)
  )
  } endSequential

Of note in this code section:-

• The sequential declaration states which namespace it belongs to.  When we call a sequential we use the notation: namespace dot CallActionSlot( sequential ), as we do in lnkGameTick.
  In MHEG+ we also must declare the tgPac token group and call :InsertSequentials, see the complete code listing below for example code.  An MHEG+ sequential is a façade to an MHEG ActionSlot.  Sequentials though can be declared anywhere in the source file and have cleaner syntax.
• Did you notice the :If?  MHEG+ gives us the syntatic sugar of being able to declare inline If blocks.  In classic MHEG our only way of implementing conditional code sections was to use the :TestVariable action and write separate :Links to perform actions based on the evaluation of the test.  In fact this is what MHEG+ does behind the scenes, but the abstraction is very handy.  We can also write :Else and :ElseIf blocks.

Updating the screen

Now that we have calculated the object Id of the Bitmap to display and stored this in an integer, we need to write a sequential to hide the current Bitmap that is displayed and show the new one.

Only by a call to a resident program can we translate an integer value into a reference to an actual object, the resident program to do this is called CastToObjectReference, or CTO.

Here is our implementation of this sequential:

  defSequential updateScreen :Namespace tgPac {
  (
    // stop the bitmap of previous frame
    :Stop(:IndirectRef objPac)
    prgCastToObjectRef.Call(boolTemp
        "/tut/tut2.mhg" :IndirectRef intNextPacObjectId
        :IndirectRef objPac)
    // run the bitmap of this frame
    :Run(:IndirectRef objPac)
  )
  } endSequential

• We call the prgCastToObjectRef resident program in order to retrieve a handle to an object given its object Id. We pass an integer (which will be in the range 100 to 104) and dynamically gain access to the object with this identifier. This is why we explicitly stated the our Bitmaps’ object Ids when we declared them.
• Note that we can’t use object dot action notation when dealing with object references (objPac is an object reference variable), this is a limitation of MHEG+.  This we must write :Run(:IndirectRef objPac) and not objPac.Run().

Putting it all together

Hopefully it should be fairly clear by now what the scene does.  At the middle of the screen we see the following animation:

Because we have used :LockScreens and tried to keep the work done whilst the screen is locked to a minimum, the animation will be fast and practically flicker free.

Looking at the complete listing (see Resources section below) it would be true to say that MHEG+ is not the cleanest of programming languages. However it is a lot more readable and maintainable than traditional MHEG.

The source listing really boils down to two key sequentials: calculateNextFrame and updateScreen.  We would be wise to move each of these sequentials into separate files and develop them somewhat independently of eachother and the rest of the scene.  MHEG+ allows us to use import declarations in order to better manage our source code.

Where to from here?

This is a good starting point for a game.  Of course there is still plenty to do, including:-

• Moving the sprite around the screen
• Rotating the sprite when it changes direction
• Adding a maze
• Adding other objects to the maze

There are also a number of  MHEG+ features we have yet to use including macros (both parameterised and not), state machines and imports.

In later posts I hope to explore these themes and also discuss the tools that make up the MHEG+ SDK including the MHEG Player (emulator), MHEG+ compiler and the Eclipse editor plug-in.

Resources

Complete source listing as a PDF: tut2.pdf.

Animation graphics (0.png through 4.png):

Other posts in this series:
Part #1 — Timing