Converting DTS audio to AAC Posted on 13 July 2009 | Tagged , , , | Comments (5)

I recently invested in this wonderful little device called the WD TV. This fantastic piece of awesome sits in between an external hard drive and a tv, and will pretty much play any video file you chuck at it - with one exception. It doesn't support DTS decoding - it supports DTS pass through, but neither the TV nor the stereo at my flat support DTS decoding either. So I wrote a little python script that re-encodes DTS audio to AAC in MKV files. I've only tested this on Ubuntu, and you need python 3, mkvtools and ffmpeg for it to do its magic. Said script, named "shinyify" is found below. Takes a single argument, being the name of the MKV file.

http://www.andyofniall.net/assets/Uploads/shinyify

2D graphics with OpenGL Posted on 28 July 2008 | Tagged , | Comments (7)

Just a quick tech note here - I've been playing round with OpenGL a little bit recently, and managed to figure out how to do some basic 2D graphics with it. Chucking my code here in case it helps anyone - this is just for basic drawing image to the screen.

First things first, you need to create your window and OpenGL context. I use SDL to do most of the hard work for me.

// Initialise SDL & DevIL
SDL_Init(SDL_INIT_VIDEO);
ilInit();
// Enable double buffering
SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER, 1);
// Initialise video surface
SDL_SetVideoMode(xRes, yRes, bpp, SDL_OPENGL);
// Set up OpenGL for 2d rendering
gluOrtho2D(0.0, xRes, yRes, 0.0);
// Enable textures
glEnable(GL_TEXTURE_2D);
// Enable blending
glEnable(GL_BLEND);
glBlendFunc(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA);

We use SDL to set up OpenGL for us, being careful to enable double buffering. The gluOrtho2D sets up a 2D coordinate system for us. Here I've made (0,0) the top left of the screen. Then I enabled textures (which we use to draw images) and alpha blending.

Before we can draw an image, we need to load it into a texture. I used the DevIL library to do this, as it is written specifically to work well with OpenGL. It provides some utility functions to do things quicker than I did it here, but I found the textures lost of a lot quality if I used them, so I stuck to the basics.

// Generate DevIL image and make it current context
ILuint image;
ilGenImages(1, &image);
ilBindImage(image);
// Load the image
if(!ilLoadImage(const_cast<char*>(filename.c_str()))) {
   throw runtime_error("Unable to load image " + filename);
}
width = ilGetInteger(IL_IMAGE_WIDTH);
height = ilGetInteger(IL_IMAGE_HEIGHT);
// Copy to OpenGL texture
if(!ilConvertImage(IL_RGBA, IL_UNSIGNED_BYTE)) {
   throw runtime_error("Unable to convert image " + filename + " to display friendly format.");
}
glGenTextures(1, &texture);
glBindTexture(GL_TEXTURE_2D, texture);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR); // Use nice (linear) scaling
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR); // Use nice (linear) scaling
glTexImage2D(GL_TEXTURE_2D, 0, ilGetInteger(IL_IMAGE_BPP), width, height, 0, ilGetInteger(IL_IMAGE_FORMAT), GL_UNSIGNED_BYTE, ilGetData());
// Free DevIL image since we have it in a texture now
ilDeleteImages(1, &image);

Pretty straight forward - use DevIL to load the image, and then convert the image to a display friendly format and copy it into a texture. The final step is to actually draw the image on the screen. We do this by drawing a four sided polygon and binding the texture to it.

// Bind texture to current context
glBindTexture(GL_TEXTURE_2D, texture);
// Set the alpha
glColor4f(1.0, 1.0, 1.0, alpha);
// Draw texture using a quad
glBegin(GL_POLYGON);
// Top left
glTexCoord2f(0.0, 0.0);
glVertex2i(x, y);
// Top right
glTexCoord2f(1.0, 0.0);
glVertex2i(x + width, y);
// Bottom right
glTexCoord2f(1.0, 1.0);
glVertex2i(x + width, y + height);
// Bottom left
glTexCoord2f(0.0, 1.0);
glVertex2i(x, y + height);
// Finish quad drawing
glEnd();

Care must be taken here to make sure you draw your points clockwise, to make sure you get a front facing polygon. Texture coordinates are always from (0.0, 0.0) to (1.0, 1.0), regardless of the size of the image.

That's it! Tuck that away behind some abstraction so you don't have to deal with it, and you have nice hardware accelerated 2D drawing. I've been playing round with creating a 2D graphics library/engine with OpenGL, so I'll probably chuck that online in a little while. :)

Edit: Sorry about the lack of spacing in the code - SilverStripe appears to have a bug with line breaks in code blocks with bbcode. I'll fix this at some point - syntax highlighting might also be nice! :)

Version Control Systems Posted on 23 July 2008 | Tagged , | Comments (5)

For a long while I have been using subversion as my main version control system (VCS). This was due to a few factors - firstly it's probably the most popular VCS out there, and secondly since I use it at work I know it like the back of my hand. While it is most definitely a momentus improvement over CVS, it always seemed like a bigger hassle than it needed to be - firstly I start and stop and then pick up little personal coding projects all the time, and its quite an effort to set up a repository. Then there's the question of where to keep it - having it online is definitely useful, but sometimes I want to code without a net connection, particularly on one of my trips back to visit family and friends in Blenheim. That's a three hour ferry trip each way, and the time I am there is spent with only a dialup connection, which is more hassle than it's worth. The other thing that is irritating is occasionally people want to help code something (ok, that doesn't actually happen that often, but it does happen :P). So I have to give them access to subversion, which one is a pain, two it means I have to trust their code since it's committed before I get to do it, and three, maybe, just maybe, more people would send code my way if there wasn't that annoyance (okay, that's probably just wishful thinking). So with distributed version control systems (DVCS) being all the rage these days, I decided to give them a try.

The difference between a distributed VCS and a centralised VCS is really just a matter of different assumptions. A centralised VCS assumes that all developers working on a project at any given point of time will have access to the VCS server, and that all code is stored in a central repository on this server. It also assumes that branches are rare, and that while you might have a development, stable, and a few feature branches lying around, branches are the exception, not the rule. Anyone who has worked on a project with more than a handful of developers knows this is definitely not the case. On the other hand, a distributed system lends itself to a much more flexible system of development - each 'checkout' of a project is it's own branch, and in fact it's own repository. While this initially sounds like it might be a nightmare - that's a lot of branches, DVCS's have very good support for tracking merges and handling conflicts, so it ends up being more hassle free than a centralised system, which generally have very poor support for these things.

When deciding to give a DVCS a go, the first program that popped to mind was, of course, git. Git has generated a decent amount of hype behind it, as it was originally developed by Linus Torvalds, the guy who was the original programmer for the Linux kernel, and still plays a large role in its ongoing development. He wrote git to manage the source of the linux kernel, after a disagreement between the kernel guys and the BitKeeper guys meant the kernel developers' free license for the proprietary BitKeeper system was revoked. Git has also been picked up by few prominent open source projects other than the Linux kernel - notably X.org and Ruby on Rails. So I decided to give git a try for a while and see how I like it.

I spent quite a while reading the documentation on git - it's a complex piece of software. After reading the introductory and basic usage a few times over, I felt I had grasped some of the basics, and so started to use it. The first thing I noticed about git was it is blazing fast - after using subversion for so long, which while not being horribly slow, does feel a little bit sluggish at times. Using a lightning fast application like git reminds you what responsiveness really is - you press enter and the text scrolls faster than you can read it. It is also very easy to set up your own git repository - just run a command in your working directory and git does all the hard work. So while initially everything looked good, after a few weeks I found myself beginning to dislike git. The reason for this is simple - it's written by a kernel developer, for kernel developers, and it shows. While it is blazingly fast, it is also pretty darn unintuitive to use. Part of this I put down to Linus' development of "take CVS as an example of what not to do", which for users coming from a CVS/subversion background is very confusing. The rest of it I just put down to kernel developers being the target market, which don't really have a reputation for being people who concern themselves with such trivial things as user friendliness. Git also tries to force you to do things its way - which is very orientated to how the kernel developers work. Sure, being able to handle having hundreds of developers in some sort of crazy web of trust is useful to a lot of people, but there is very little support for making it easy for old Joe Bloggs (aka me) to handle his little projects, or for a small group of deveopers to work on a project together with little hassle. I'm sure these things are easily possible with git - but with the complexity of git I'll be darned if I can figure out how.

So feeling a little disillusioned, I started to hear about another DVCS more and more commonly through the tubes of the blogosphere - bazaar. While initially I didn't pay it much attention - in my mind the only reason git was popular was because of the backing of the kernel crew, and the buzz about bazaar all seemed to come from the Canonical/Ubuntu crew, as Canonical sponsor the development, I just brushed it aside as more irrelevant hype. After seeing a few more blog posts of what seemed to be some cool features (a avahi branch sharing plugin in particular), I decided to take a closer look.

The first thing that struck about bazaar was it has a completely different focus than git - git was designed to be fast, but bazaar was designed for usability. That's not that to say that git can't be usable (well, one day ;)), or that bazaar can't be fast, but it is a different mindset. Bazaar is coded in python, which from what I read is less of a concious design decision, but was originally being used for a prototype, when they discovered their prototype was quickly outgrowing the software it was designed to be a test bed for. Being developed in python, the language everybody loves to love, there are a large number of plugins written for it. I think an extensible plugin system is a brilliant idea - it beats the screen scraping and data peeping tools that have historically been used for VCS integration.

Bazaar is a breeze to use, particularly if you've come from a subversion background. All the basic commands are there, and act pretty much as they do in subversion. Bazaar is also very flexible - it lets you choose if you want a centralised repository or not - when you do a 'checkout', whenever you commit a change, the changeset will be pushed to the repository you checked it out from. If instead of doing a checkout, you use the 'branch' command, all your commits are made locally, and can easily be pushed to the repository you got them from (or another repository) whenever you need to. And to answer the speed question - bazaar feels more responsive than subversion, and is more than fast enough for everyday use. It's not the lightning that git is, but it's still a snappy piece of software.

Add to this the wide range of useful plugins, and the ease of setting up a web accessible repository (bazaar can use http, ftp and rsync in lieu of not having bazaar installed on the server), and you have a winning DVCS in my mind. I use the bzr-gtk plugin, which gives some nice gui integration (accessed via commandline, eg to get a nicer gui diff, i use bzr gdiff instead of bzr diff), the avahi plugin to make sharing branches on local network easier, and the svn plugin to let me read from svn repositories (this is mostly just playing around!). All in all, I think I've found the VCS for me!

Oh noes it's Ohloh Posted on 16 August 2007 | Tagged , , , | Comments (7)

I came across an interesting site the other day - Ohloh. It's basically some sort of odd combination of open source software metrics and social networking. While I am generally find most social networking sites fairly annoying, this one intrigues me by introducing something else into the mix. Last.fm is another good example of this - I use it for plenty of music finding goodness.

When I stumbled across the site, I found that I was, in a way, already a part of it. Ohloh had been tracking my commits to SilverStripe (although only the commits made since the subversion repository was opened), and when I signed up I could claim that svn user as me. It also gives some interesting statistics about SilverStripe - for one it is very well commented; one of my tasks a while back was going through and adding phpDocumentor comments to the code, although the enormity of SilverStripe meant that I didn't particularly get that far, so I can't credit for many of those comments. Maybe later on I'll get a chance to do some more.

I also added Fields of Gold and Project Frozen Flame to Ohloh, and after waiting a day or so for the projects code to be crawled we now have statistics on both the projects.

A few other SilverStripers also signed up and we gave each other kudos - Ohloh's way of letting you show gratitude to another open source developer. Ohloh also calculates a 'kudo rank' based on the commits you have done and the kudos you have received. I logged on the next day to see not one, but all five of the 'highest kudo gainers' on the front page were SilverStripers (although Elijah is put down as CMSMadeSimple, he is one of our Google Summer of Codestudents, and is working in a private branch that Ohloh can't see). Woohoo!

Ohloh is a site I plan to keep an eye on, it's still in it's early days, but it shows promise.

Announcing Project Frozen Flame Posted on 3 August 2007 | Tagged , | Comments (0)

Over the past couple of days, I've been working on implementing an engine for the Super Nintendo text adventure Radical Dreamers. Why? Because it's a cool game, because it's fun to code, and because it would be cool to play it looking a little prettier.

Right now most of the important op codes are implemented, so the game is playable, if a little ugly. If you're keen, you can find details on subversion on the project page; you'll need python and pygame to get it to run. And to finish, the mandatory screenshot:

Farming for profit and pleasure Posted on 13 June 2007 | Tagged , , , | Comments (3)

Over the past few days, me and Mat have started working on a little project called Fields of Gold. It's a farming simulation (basically a Harvest Moon clone :P), which Mat assures me is a great genre of game. I'm not yet convinced but we'll see.. We've opened up the subversion repository to the public, but it's still very early days for the project. If you don't believe me, check the screenshot:

Yes, that red arrow is your character.. sorry, programmer art. However I do believe this game has potential! This is the first time I've used python before, and combined with the wonderful pygame library, I don't think I've ever seen code come together so fast. Yay python!

I have also thrown together a little subversion repository viewer for this site, along the lines of the trac viewer but much simpler. It's all coded in php and SilverStripe, so it just slots in nicely with the rest of the site. Hopefully as I have more time I'll be able to add a few more features to it.

Old uni projects for the win! Posted on 25 May 2007 | Tagged , | Comments (9)

My site is still feeling a bit bare, so I uploaded the adventure game me and some friends made last year for a university projects. It's called Hippie, and while it's not the most advanced piece of coding around, it is something, and we were fairly happy with it. Who knows, maybe one of these days I'll get round to improving it! Some screenshots for your, err, pleasure?