Kazade's Home on the Internet

Ignition Revisited

2011-12-10T20:00:00.001Z

At the beginning of the year I spent a bit of time reverse engineering a texture file from the abandonware game "Ignition". It was my first attempt at reverse engineering anything so I was pretty pleased when I deciphered the .PIC format, and so I blogged about it.

Since then that particular post has attracted a few comments from people interested to see if I'd learned any more about the game. I only noticed some of these comments recently and so it encouraged me to dust off the game once more and take another look.

The result is a GitHub repository, currently only including a newly rewritten texture converter, but I'm also working on decoding the MSH file which I believe contains model data. Feel free to check out the code, and contact me if you fancy helping out. It would be nice to be able to document all of the formats in the game!

Things that need fixing in Unity

2011-05-09T11:04:00.002+01:00

So, it's been a week or so since the release of 11.04, and I've been running Unity on my desktop and laptop for some time now, and, I'm fairly ambivalent about it. On the one hand, it's pretty and there are some really cool elements to it, but then these are spoiled by REALLY stupid design decisions, the UI is not in any way "simple", or "consistent" in fact, it's almost like it was designed to be complicated.

One of the special skills I find in the open source community is that, we are generally more adaptive than most people. We learn how to work around stuff pretty quickly. This is a real hindrance when we come to design and use interfaces, because we adapt past broken interfaces and forget what it's like to see this interfaces for the first time.

Now, let's take a step back. Let's look at Unity with a fresh pair of eyes and you will see actually, things aren't that great.

1. The Panel (General Design)

This is by far the most broken part of the experience on the desktop. The panel has been designed for netbooks, and it's designed for maximized windows only. The moment you start bringing in unmaximized windows the whole thing becomes inconsistent, confusing and frustrating.

The problem (as I've discussed before) is that maximized windows merge into the panel, but the panel shows details from the focused window. If you have an unmaximized window, these ARE NOT the same thing. So the menu/title and controls of the focused window appear in the titlebar of any background maximized window...

Except, that's not the only problem. Noticing this, the design team tried to design their way out of the problem they'd designed themselves into in the first place. Realizing that now the window controls in the panel make it look like you are closing the maximized window, rather than the focused window, they removed them. So now, there is another inconsistency window controls only appear in the panel for maximized windows, and then only if they are focused. There are two solutions:

1. Don't merge the titlebars or window controls. Make the panel only show the menu and title of the focused window.
2. Merge the titlebars of maximized windows, don't use a global menu.

Personally, I'd go with the latter, I'm not a fan of the global menu on the desktop, and I like the way the titlebar merges with the panel.

2. Overlay scrollbars

Don't get me wrong, I think these scrollbars look slick. The real issue is that the appear inside or outside the window depending on the available space. This makes it hard to predict exactly where you need to move your cursor to scroll. Excuses I've heard are "I use the scroll wheel" and "I use PgUp and PgDn" - these to not excuse the problem. Just make the scrollbars always appear inside the window so people know what to expect.

3. Dock Autohiding

This, by default, was the wrong decision. The dock is difficult to "get back" and is not touchpad friendly at all. And the weird hover behaviour on the Ubuntu button doesn't help.
One thing that I continually do is click the Ubuntu button expecting that it will show the dock, which it does alongside the dash, but then I can't click anything on it.

The other annoyance is when autohide is enabled, the window controls aren't at the left hand edge of the maximized window they are awkwardly offset because of the Ubuntu button.

Just turn off autohide by default, make everyone's life easier.

4. Maximized Windows Can't be Focused by Clicking Their Titlebar (Bug)

If you are working in a small window (e.g. Empathy) and you want to focus a maximized background window (e.g. Firefox), your instinct is to click the titlebar (e.g. the panel). But this doesn't work, so the only way to focus is to click *somewhere* in the background window, without triggering some action of that window. Nightmare.

5. Dragging the Titlebar of a Maximized Window Doesn't Always Work (Bug)

This is a bug, but I'm seeing it quite often. If you try to drag a window out of it's maximized state (e.g after aero-snapping) it works sometimes, but not always. Really frustrating.

6. The Title Hides Even Without AppMenu (Bug)

Remove indicator-appmenu, hover a window title in the panel. The title hides to show nothing.

7. Hiding the Menus Behind the Title Ruins Global Menus

I've never been a fan of global menus on the desktop, on a netbook, fine, but on a desktop I think the travel distance, extra context and window disconnection outweigh the benefit's of Fitt's Law. At least though, on a netbook it makes sense right? Unless of course you hide the menus behind a title so you can't see where you are targetting until your cursor is actually there, so the Fitt's Law argument goes out of the window. Also, relying on hover breaks touch. Bad decision.

Summary

Well, there's 7 problem's that need fixing, I could go on but I think these are the worst; they are at least the ones that affect me. You'll notice though that 5/7 are down to the panel design. Just don't use global menus, don't update unrelated parts of the UI based on the focused window and those issues disappear.

A critical look at Unity

2011-04-10T10:37:00.004+01:00

Ubuntu 11.04 comes out later this month, it's currently in beta. The main feature of 11.04 is the brand new desktop shell called Unity. I've been using Unity on and off for some time, but now we are near to release I decided to install it onto my desktop machine and use it full time.

Perhaps I should've posted this blog post earlier, but the truth is that although I've had Unity on my laptop for some time, I haven't given it a real proper test drive. Now I have, I'm not quite as excited about Unity as I was, and in fact, I'm a little worried.

The Good

There are plenty of great things about Unity, for one thing it is, in my opinion, the most glorious looking default desktop I've ever seen. Not just in free software either; it runs rings around both Apple and Microsoft in the looks department.

The launcher looks brilliant, it's bright, colourful, although perhaps slightly too large by default. There are a couple of minor quibbles. The indicator applets seem really squashed together and untidy, this is probably collateral damage from the window elements in the panel (I'll get on to that in a bit). With everything and the kitchen sink in the panel, there is obviously less room for indicators. The other thing is that the categories menu in the applications "lense" looks a bit "Windows 95" but I'm sure that'll be fixed in time.

I love the Applications lense. It makes finding and installing applications a complete doddle, really awesome. The only thing is I can't help thinking that it duplicates the Dash somewhat, and I wonder if both the "Applications" and "Files and Folders" lenses couldn't be combined into the Dash.

The Bad

Despite all that is good about Unity, there are things that ruin it. I always laugh when a user reacts to change with the cliche of "I'm leaving Ubuntu" but I really do have to go with the less extreme "I don't think I can use Unity". My issues can be summed up into two general areas:

1. Window switching
2. The panel

Window Switching

UPDATE: I've been reliably informed that the current window switching behaviour is not correct and is a bug. The finished Unity will display a spread of all the windows associated with an application if there is more than one window, which is pretty nice. So disregard this section!

Let's start with window switching. On the classic Ubuntu desktop, switching windows was a single click. It did involve scanning the window list which wasn't grouped and always had truncated entries. But it was simple, and clear. If you clicked a minimized window, it was restored, if you clicked it again, it was minimized. It doesn't get much simpler than that.

Those of us that discovered the DockbarX applet had IMO the perfect solution to the space issues of the traditional window switcher. DockbarX groups windows by application (like Unity) but hovering the icon would give you a list of windows for that application, with quite a large portion of the windows' titles. Switching windows was FAST.

Now, Unity. Unity's window switching is confusing. If a program isn't running, clicking the application icon will launch that application (fine). To open another window of that application you need to middle click or right click and use the popup menu, that seems fairly undiscoverable to me, but it's okay. Now, if you have two Firefox windows open and you left click the Firefox icon, what happens? The answer is, I'm not entirely sure.

Sometimes it displays a nice compiz powered window selector, but sometimes it looks like it unminimizes the most recent window*. It's seemingly random (I know that it isn't, but it definitely seems so). Why not just always display the window selector if there is more than one window? And while we are at it, if there is a single window open, why doesn't clicking the application icon minimize it?

This might seem like a minor issue, but it's frustrating. People don't like not knowing what a button is going to do when they click it. It scares them.

The Panel

This is the big one. This is the thing that annoys me more than anything else in Unity, because it annoys me on many levels. First there is the irritation that it doesn't work in the way I expect, then I realize I can't change the behaviour through any option, then I think about the problem and get annoyed that Unity's designers plowed through obvious ambiguity and special cases just to save a few pixels of vertical space.... let me explain.

Firstly, let me state I've never been a massive fan of the global menu on desktops. I think it's great for low resolutions when you work mainly with maximized windows because in that situation there is never that detachment from the window context that there is with smaller windows. On netbooks I think it's a great fit, on the desktop where multitasking with unmaximized windows on high resolutions is the norm... not so much.

I've made my views on global menus clear all over the Interweb and Matthew Paul Thomas has put forward many good reasons why he believes they are a good idea, and I do buy some of those arguments, but only in the context of Apple's implementation of the global menu.

We don't have Apple's implementation of a global menu.

What we have is a menu hidden behind the title of the focused window, along with the window controls of the focused window, in a titlebar that may or may not belong to the top maximized window that may be unfocused. This makes no sense.

Hiding a global menu behind a title bar completely destroys the point of the global menu in the first place. The main thing about a global menu is it is easy to hit... how is it easy to hit a menu item if you can't see it until your cursor is already there? It's also almost completely undiscoverable, when a new user boots from a Live CD, what are they supposed to do? Wave their mouse cursor around until they find it? What about touch screens?

What we have is a global menu without any of the advantages of a global menu, but all the disadvantages (e.g. outside of the associated window and dependent on its context, large travel distances on high resolutions, incompatible with "sloppy focus").

Let's forget the global menu for a minute, I mean after all you can always "sudo apt-get remove indicator-appmenu" to get back the old behaviour. Let's instead focus on the far more problematic issue. The window controls (again).

On the Unity desktop, if you maximize a window, the panel becomes its titlebar. This is slick because it prevents wasted vertical space, and the indicators fit nicely in the blank area of the titlebar. If you maximize another window (let's say Firefox) above that one, then the panel becomes the titlebar for that window. This works fine.

Now, open up another smaller window, say the Empathy contact list. Who now owns the panel? Logically Firefox should, as it looks like it forms part of that window. Except now the panel contains the title (and menu) of Empathy, inside the titlebar of Firefox.

This basically has the effect of hiding the Firefox titlebar, the window controls for Firefox are no longer there, there is no way to close Firefox without focusing it first. Except of course you can still drag the titlebar of Firefox, so really we now have this situation where both Firefox and Empathy own the panel. It's confusing and ambiguous and the annoying thing is it really doesn't need to be.

There are three solutions, any of them would make the panel far more usable:

1. Don't merge the titlebar with the panel, retain a visible global menu (OSX style)
2. Merge the titlebar, make the panel only contain the controls and title of the top maximized window (e.g don't change with focus), abandon global menus entirely
3. Merge the titlebar into the panel complete with the hidden menu, but only for the top maximized window (don't change with focus). Keep the menu inside unmaximized windows.

Either of those options would provide a consistent experience without any special cases or confusing situations. In each option you always know which window currently "owns" the panel.

Summary

While using Unity have seen a far higher number of bugs than I'd like to see this late in the development of 11.04, but I've ignored them for now, I have every faith that they will be fixed. They always are.

I do worry about the above design decisions in terms of usability. Yeah, we'll probably get used to them, but then again if I lost a limb I'd get used to that too, it still wouldn't make it ideal. :)

* Edit: Apparently it doesn't unminimize one window, it unminimizes all of them... who would ever want that to happen?

Investigating X-Wing (OPT and XWI file formats)

2011-04-04T21:30:00.000+01:00

The other day I was reminiscing about the old PC games I used to play back in the 90s when I remembered the Lucasarts classic X-Wing. I remembered that in the late 90s I used to make levels for it using an editor. A bit of searching found me two different editors that I remember fiddling with, one was the DOS based "X-Wing Mission Builder" and another was the Windows based X-Ed.

I found downloads for both (the X-Ed website still exists!) and both ran fine on my Ubuntu PC (XMB using DosBox, X-Ed through Wine). Little did I know that these downloads were going to start a chain reaction that would drive me to spend hours of my weekend staring at a hex editor. :)

When I was playing with X-Ed, I noticed that the map format itself seemed quite simple. You build maps by placing "flight groups", each flight group has a ship type (e.g. X-Wing), a start position, a ship count, and a number of waves. There are other flags for orders, team etc. but basically building a level for the game involved placing these flight groups and setting objectives (e.g. destroy an entire flight group). So, (I thought), if building a level is this simple, then surely the level format is simple. If I could understand the level format, perhaps I could load levels into a graphics engine like Ogre. How hard could it be?

It took some searching, but I eventually found that someone had already described the format in detail. I noticed though that some values were missing, by comparing X-Ed's UI to the level spec I could see which options weren't in the specification I just had to figure out which checkbox in the UI, affected which unknown element in the spec. So, armed with GHex, I made changes to test map while watching what it did to the file. When I was done I'd deciphered the 8 unknown values from the spec. I emailed the website owner and he's updated the page.

Fuelled by this success, I knocked together a little C++ app to load the map into Ogre and place the Ogre head mesh everywhere a ship would be. It worked, my next goal was to replace those Ogre heads with free 3D models of spaceships (e.g. not Star Wars related), perhaps I could turn this into an actual game! [1]

Only, staring at the large, overlapping Ogre heads, something occurred to me. What scale are the ships in the original X-Wing? If I could load them then I could find out... in fact, if I could load them then I might be able to code a modern, replacement engine for X-Wing!

This is where my curiosity probably went a step too far. I thought if the XWI level file format was so easy to find and load, then perhaps the OPT model format was also simple. Oh, how wrong I was.

Long story, short: I found a specification for the OPT format used in the later games in the series, it was good but some parts were a little ambiguous, or could have been explained in detail. I spent hours and hours staring at the hex code of the X-Wing model, I managed to understand the structure, load in the vertices, dump out the textures, everything was going fine until...

Assertion `indexes[0] + file_->get_index_offset() < vertex_count' failed.

For some reason, I'm finding indexes to vertices that are greater than the number of vertices in the mesh! This is the last stumbling block and I'm stumped.

So, if anyone is reading this, and they were part of the OPT hacking community back in the day please get in touch!

[1] Obviously not using the original maps or models, as they are copyright of Lucasarts etc. but using X-Ed to build maps.

C++ Timer Class

2011-04-01T09:27:00.001+01:00

Just thought I'd shove this somewhere public as it's probably useful for someone.

Earlier today I had a problem where boost::timer was always returning zero. The cause was boost::timer uses std::clock which only returns the elapsed CPU time. If you use sleep(), std::clock won't update!

So here's a little class that returns the elapsed time since the timer was instantiated (or restarted) which works with sleep().

 Copyright (C) 2011 by Luke Benstead  
   
 Permission is hereby granted, free of charge, to any person obtaining a copy  
 of this software and associated documentation files (the "Software"), to deal  
 in the Software without restriction, including without limitation the rights  
 to use, copy, modify, merge, publish, distribute, sublicense, and/or sell  
 copies of the Software, and to permit persons to whom the Software is  
 furnished to do so, subject to the following conditions:  
   
 The above copyright notice and this permission notice shall be included in  
 all copies or substantial portions of the Software.  
   
 THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR  
 IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,  
 FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE  
 AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER  
 LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,  
 OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN  
 THE SOFTWARE.  
   
 #ifndef TIMER_H_INCLUDED  
 #define TIMER_H_INCLUDED  
   
 #include <sys/time.h>  
   
 class Timer {  
 public:  
   Timer():  
     start_time_(now()) {  
   }  
   
   void restart() {  
     start_time_ = now();  
   }  
   
   double elapsed() const {  
     double t = now();  
   
     return double(t - start_time_);  
   }  
   
 private:  
   double now() const {  
     timeval t;  
     gettimeofday(&t, NULL);  
     return t.tv_sec + (t.tv_usec / 1000000.0);  
   }  
   
   double start_time_;  
 };  
   
 #endif // TIMER_H_INCLUDED

Yeah I know, it's basic and anyone could've written it, but still might save someone 5 minutes :)

Linux Mint Debian Edition - First Impressions

2011-02-16T09:25:00.003Z

This morning I got up early and replaced my Ubuntu 10.10 installation with a nice shiny install of Linux Mint Debian Edition (LMDE). LMDE is based on Debian testing, and is a rolling release. I've always wanted to try a rolling release, and one based on Debian ticks all the boxes. The important thing is that Debian and Ubuntu share the APT packaging system which thinking about it, is probably the main reason I use Ubuntu.

I've used regular Linux Mint a few times in the past and I've always been impressed, although I always end up back on Ubuntu, I'm not really sure why that is, probably that I can't wait to test out the newest stuff so I jump on Ubuntu as soon as a new release comes out. A rolling release of course solves that problem.

Installation

Installation was pretty smooth, everything worked out of the box from the live CD including wifi (although I did go out of the way to buy an Linux-friendly wifi card). The only minor issue was that my keyboard was set to some random layout (probs U.S.), it wasn't until I started the installation and set the correct keyboard layout that I could type punctuation without trial and error. But then that took effect immediately across the system. It's interesting, I don't remember that happening in an Ubuntu installation, maybe I just never noticed. Does Ubuntu detect the keyboard layout via your location (e.g. over wifi)?

The partitioning screen would be pretty confusing to a newbie, I didn't really like that all my disks were displayed at once, I'd much prefer some kind of separation like GParted uses. Another thing that was quite disconcerting was the lack of a "Format?" column in the table, instead relying on the filesystem type displayed under the "Format to..." heading, I wasn't completely sure it wasn't going to format my home partition and I had to double and triple check on the final installation screen to make sure I wasn't about to wipe my data. It would be nice to have some kind of definite "Yes, I'm formatting this partition" flag next to each partition entry.

Another minor niggle occurred when installation finished, I was told I could reboot into the system, but I wasn't given an option on that dialog to do so. That would've been nice.

First Run

Boot time was FAST. I got a bit worried when Grub popped up with a BSOD colour scheme, I thought something had gone wrong for a second, old habits die hard I guess. I did have one issue when I logged in though...

This is something that occurs in other (all?) distros, but it is an annoyance. If I select an existing home partition, that has an existing folder for the selected username it would be great if the installer could run chown -R user:user on that home folder. Otherwise if the user IDs don't match, the user is greeted to a bunch of confusing error messages and unable to write to their folder. Easy to fix if you know what you are doing, but really this is the installer's job.

Aside from that everything was great, LMDE feels really solid, I can't put my finger on it, but it *feels* more robust than Ubuntu. The Mint menu is amazing, easily the best program menu I've ever used. The Mint themes are beautiful, I'm not a huge fan of green though so I switched over to the dark and blue WildMint theme which is very nice. I did flick all the desktop fonts over to ttf-ubuntu just as a personal preference.

There were a few other minor niggles:
1. Synaptic is the package manager - a rebranded Ubuntu Software Centre would probably be nicer
2. I installed the indicator applet but it doesn't work, although I know this is down to Debian rather than LMDE, I'm sure it'll be fixed in time
3. No Plymouth, but that's in the release notes, and to be honest, I sort of prefer the scrolling text :)

I've got a queue of updates to install when I get home tonight, so perhaps some things are fixed. My next challenge is getting 3D acceleration on my ATI graphics card :)

EDIT: The BSOD grub colour scheme was changed after the updates to a much more subtle grey. Also, my ATI card is running pretty well with the open source drivers so I'll stick with that for a while.

Reverse Engineering the Abandonware Game "Ignition"

2011-01-18T15:01:00.003Z

Ignition has always been one of my favourite racing games. It had a quirky charm that was reminiscent of Micro Machines, but set in beautiful outdoor environments.

It's now one of the most prominent cases of Abandonware ever. First published by Virgin Interactive, which was acquired by Titus Software, which then became Avalon Interactive. Both Titus and Avalon no longer exist. So who owns the rights to the game (and more importantly who has the source code) is a mystery.

The other day I decided to take a look at the files that come with Ignition, I wondered if there was anything salvageable for an indie game developer. Perhaps I could knock together a level viewer or mod the game. The first thing I noticed is that Ignition uses a lot of different file formats.

There is one TGA image, but that's just of the Virgin Interactive logo, some of the sounds are WAV, but others are another mystery format. However, some of the extensions give away what they are. There are .PIC files and .MSH which I assume are images and mesh files respectively. There is also a .TEX, some other image file perhaps?

I fired up a hex editor and began work reverse engineering the .PIC file. The first thing I tried to do was to render the latter part of the data as RGB bytes. I assumed (wrongly) that it would be a 24 bit image. All I got out of it was a garbled mess, except for a couple of rows near the top of the image which were all different colours. It then occurred to me; this is a palette based image and those two rows of colour are the palette.

Now that I knew what I was looking for, things got easier. I looked at the beginning of the header and found a couple of familiar numbers; 640 and 480. Those bytes were obviously the dimensions of the image. With that in mind I could read backwards from the end of the file for 640 * 480 bytes and assume that that would be where the end of the header (and probably the palette data) was.

Finally, with a bit more experimentation, I found the start and end of the palette and some other numbers the use of which still eludes me.

To sum up, here is the header structure of the PIC image file that Ignition uses:

typedef struct PICHeader {

    INT file_size;

    SHORT magic; //Always 38144 (or 0, 149 in separate bytes)

    SHORT width;

    SHORT height;

    SHORT unknown1;

    SHORT unknown2;        

    BYTE unknown3[50];

    SHORT palette_size; //I thought this was palette size - but it's not, it's always 776

    BYTE unknown4[6]; //Always zeros, probably reserved

    BYTE palette[256*3];

    SHORT unknown5; //In one file this was the number of bytes after and including this one, but not in others (??)

    BYTE unknown6[4]; //Seen (0, 0, 1, 0), (4, 0, 1, 0) - probably orientation (e.g flipped image)

} PICHeader;

Every byte beyond the header is an index into the palette for the pixel colour. I now have a simple little program that converts from PIC to TGA. If anyone has any clue what any of the other numbers means then let me know.

Now onto the other... probably more complicated... formats.

PPA For My Game Developer Kit

2011-01-11T09:21:00.000Z

So, I've spent the last few months focusing on developing cross-platform games. I've started small with Ubuntu Bug Blast, and gradually I'm going to build to more and more complex games. The idea is that I will identify bottlenecks in development, and create small modular libraries to cover the repetitive parts of developing a game in OpenGL.

DirectX has a lot of common functionality, like text output, or math functions, which OpenGL lacks. Of course, libraries for these functions exist for OpenGL, but they always seem to do too much, or be complicated to use in some way. My libraries will focus on doing one thing, and covering the most common use cases.

If you head on over to the game libraries page, you'll see that so far I have created two libraries; Kazmath and Kaztext.

Kazmath has been around for some time and was co-written with my good friend (and math guru) Carsten Haubold. Kaztext however is very recent, it provides a simple way to load TrueType fonts into OpenGL, and bind and use them like OpenGL objects.

To make using this libraries on Ubuntu easy, I've created a PPA. You can find it here.

The packages include headers and statically compiled libraries (the libraries are BSD licensed). You should be able to just include the headers (e.g. #include <kaztext/kaztext.h> ) and link to the library and then use the libraries straight away.

All of the libraries of the GDK will follow the following rules:

They will always be written with a portable C API
They will be as simple as possible
They will not depend on each other
They will be open source under the same modified BSD license
They will all be hosted on Launchpad

I will be creating a Windows installer for the libraries so that it's easy to get the GDK there too. Upcoming libraries include Kaztimer (game timers and stop watches), Kazui (simple OGL based UI API), Kazpng (PNG image loading to OpenGL textures) and more!

5 GUI Apps that Ubuntu is Missing

2010-10-21T14:45:00.003+01:00

Ubuntu has come a long way in the past few years. I've been using it as my only desktop OS since Hoary, and it's come along in leaps and bounds. There are however a number of things that just seem to be "missing".

This list is a set of GUI apps that I have discovered to be missing, either on my own desktop (1, 2, 3, and 5) or while installing Ubuntu for friends (4).

#1. A Mouse Button Configuration UI

This seems like such a glaring omission that I'm baffled it's still the case. I have a mouse with extra buttons beyond the standard 3 + scrollwheel. At least 3 of these extra buttons do nothing.

However, if you go to to the Mouse preferences in the UI there is no way to map those buttons to any behaviour, in fact a Google search brings you to this wiki page: https://help.ubuntu.com/community/ManyButtonsMouseHowto

Every single part of the document describes running terminal commands, installing extra programs or editing hidden configuration files. This is a big FAIL. Just give us a UI that says, "Map button 5 to 'Back'" and I'll be happy.

#2. A Joystick/Joypad Calibration Utility

This is pretty much the same as above, but for the often forgotten about extra input device. Unlike the Mouse, we don't even have an entry under preferences for this. How can Ubuntu become a decent gaming platform when we can't even test or configure a Joypad?

#3. A Simple Painting App

Ubuntu has plenty of "photo" applications, we now have Shotwell or whatever. But occasionally you just want to scribble something on top of a screenshot, or entertain a visiting nephew. Windows has had MS Paint since, what 3.1?

There are plenty of MS Paint clones out there, pick one, shove it under accessories and let people scribble to their hearts content from the LiveCD.

#4. An iPod/iPhone Firmware Updater

This one is debatable, but simply put, Rhythmbox can manage the music but it can't reset or update the firmware (like iTunes can). You want to convert people to Ubuntu? iTunes is the big gaping hole, and although Rhythmbox + Ubuntu One does plug some of that gap, there isn't enough support for managing the other features of their iPods.

Gtkpod is OK, it does allow you to reset an iPod but again you can't update the firmware from it. Of course, the catch-22 is a firmware update could render any iPod integration unusable, but we could surely come up with a UI that only flags "safe" updates.

#5. An Easy to Use Task Scheduler

This one actually sprang up because I kept forgetting to sign into Empathy at work. Empathy doesn't start up by default so I went to find the "Start on login" checkbox only to find it doesn't exist.

There is a "Startup Applications" section under preferences, but unless your application has thought to put an entry there, getting it to work isn't exactly user friendly.

What we need is a UI that says "Start X, Y minutes after Z" where X is an application, Y is a number, and Z is Login, Network Connected, USB key inserted etc. and also cron-style "Start X at Y on Z".

Mellowing the Ubuntu Indicator Applets

2010-10-13T14:05:00.004+01:00

Update: As of Ubuntu 11.04 Canonical has switched to using light blue icons for notifications. So, I can officially say "I told you so" :)

One thing that has bugged me since Canonical launched their Indicator Applet work was their chosen colour system. I'll explain...

Certain colours can imply certain meanings. For example Green normally means "Go ahead" or "Everything is OK". Red can mean "Stop" or "Danger" or "Something's gone horribly wrong". Blue is normally associated with just "Information", especially when it comes to road signs. A quick Google Image search for "information sign" shows a definite Blue trend.

Yet, the application indicators, and specifically the message indicator, love using Green and Red. Green is used for "New Messages" but Red is used for "Your Volume is Muted" or "You Need to Restart Your Computer".

I don't know about you, but those colours don't seem to match what is basically "information" to me. In fact, both colours convey an unnecessary sense of urgency.

So, to make things a bit more mellow, I've created Blue versions of the above icons. I find them much nicer. To install just copy the "apps" and "status" folders over the ones in /usr/share/icons/ubuntu-mono-dark/ . If you decide you don't want them any more just reinstall the ubuntu-mono icon theme.

Step Back to the 90s with this Mega Drive Emulator for Ubuntu

2010-10-08T11:58:00.001+01:00

This post is a cross-post from Ubuntu Gamer

I don't know about you guys and girls, but sometimes I like reminiscing about my childhood by playing some good old Mega Drive (Genesis for those across the pond) games. You can't beat a good round of Sonic.

When it comes to Mega Drive emulators that run on Ubuntu, Gens/GS rocks. Gens/GS is a fork of the well known Gens emulator, and over the last several months the author has been cleaning up the source code and adding new features and bug fixes to create an awesome (open source!) emulator.

Some of the features include:

Multiple resolution support
Lots of rendering modes
Sega CD support
SDL or OpenGL rendering backends
Save/Load States
...and loads more!

Unfortunately, Gens/GS isn't packaged in the Ubuntu repositories, but luckily the author provides pre-built packages for all the releases and they are available on the homepage.

The package only comes in the i386 flavour, so if you are running the AMD64 version of Ubuntu you may need to use dpkg and some --force-architecture magic:

sudo dpkg --force-architecture -i Gens_2.16.7_i386.deb

You'll get a Gens/GS entry under the Games menu where you can fire up your classic ROMS.

Note, the legality of running old ROMs is a grey area and depends on the laws in your country, so check them out first.

Using Multiple Wine Prefixes

2010-10-05T09:58:00.001+01:00

This post is a cross-post from Ubuntu Gamer

Wine rocks. It is probably one of the most underestimated pieces of software in the open source ecosystem. If the idea of running pre-compiled programs from Windows on a totally different operating system with a different kernel, and different programming libraries doesn't make you cross-eyed with the complexity, then you aren't thinking about it hard enough.

Just to give some idea of the Herculean achievement that Wine is; the current number of lines of code that make up Wine stands at well over 2.5 million and the project was started in 1993.

The Wine developers don't just have a mountain to climb. To extend the metaphor, they have to climb the mountain, blindfolded, in a straight jacket while tied to a goat... drunk. Their work really is that hard.

Yet despite all that effort, Wine still isn't 100% perfect. Sometimes a Wine DLL will be missing some code, other times the code may not match what Windows does and occasionally a program assumes the existence of files that may not even necessarily exist on a native Windows installation (e.g. .NET).

In these situations it's possible to use native original Windows DLLs in place of the Wine manufactured ones, or to install non-default runtime files like .NET or Java using their Windows installers.

To make this process easy there is a script called “winetricks” included in the Wine package from the Wine PPA or is available for download from here. Running winetricks from the terminal will give you a bunch of possible options to change and runtimes to install. Things like configuring font-smoothing, or installing .NET 1.1, 2.0 or 3.0.

The interesting thing is that these changes usually only affect the default Wine “prefix”.

What is a Prefix?

You all probably know that Windows installations have a certain folder structure. Specifically you'll normally have a C:\Windows directory, and a C:\Program Files directory. When you run Wine for the first time it creates these folders in a hidden directory in your home folder called “.wine”

This is a Wine prefix, it is essentially a fake Windows installation. It contains the folder tree, system files, a registry and Wine specific options (e.g. the Windows version). When you install an application, the files will be installed in the correct places within this tree and may add and remove registry entries. The default prefix is ~/.wine but you can create new ones anywhere you like.

So, Multiple Prefixes?

As I previously mentioned, sometimes you need to install some extra stuff into a Wine prefix to get an application working. If you are installing many applications and games your prefix can bloat up. Perhaps you may install something to get your second application working that breaks the first one. Perhaps you have an application that requires Wine to simulate Windows 98 and another application that only runs on XP and above.

To avoid this situation you can create a fake Windows installation for each individual application you install. You can tailor this installation for the application you are installing without the risk of breaking any other installed Windows programs.

The WINEPREFIX variable

Wine keeps track of the prefix to use with the WINEPREFIX environment variable. When the WINEPREFIX variable is set, all Wine commands such as winetricks or winecfg and any Windows application will use the specified prefix. Wine will also create the prefix if it doesn't exist.

As an example I'll demonstrate installing Interstate 76 bought from GOG.com into its own prefix. What's interesting about this specific game (and specifically the GOG version) is it requires a native Visual C++ runtime, .NET and the Windows version to be set to Windows 98, otherwise it crashes.

It's worth noting that you are required to have a Windows license to install Microsoft redistributables. Eventually Wine and Mono will progress enough to make this unnecessary though, just not yet :)

Example: Interstate 76

So, we want to create a new Wine prefix, which we do by setting the WINEPREFIX variable. So in a terminal we run:

export WINEPREFIX=~/.wine-interstate76

From this point forward all Wine commands run within the terminal session will work on our new prefix in a hidden .wine-interstate76 folder.

So now we can run the installer:

wine ~/Downloads/setup_interstate76_arsenal.exe

Running this command will do two things. Firstly it will create the prefix (you'll see a nice Wine message box telling you that it is updating the prefix). Secondly, it will run the installation program. Once we've been through the installer it will ask if you want to launch the game. This errors out with the Windows error message:

“An application has made an attempt to load the C runtime library incorrectly”.

If you ever see this specific error while trying to start a program under Wine, the workaround is usually to install the native VC++ runtime using winetricks. You'll notice the terminal printed the following:

err:module:attach_process_dlls "MSVCR90.dll" failed to initialize, aborting

So, we fire up winetricks and scroll down the list and lo and behold right next to “vcrun2008” is “msvcr90” listed as one of the components that it installs. Enable the checkbox next to vcrun2008, also next to dotnet20 and win98 which are required for this game.

Clicking OK will start off the VC++ runtime and .NET 2.0 installations and you'll need to do the traditional Next, Next, Next, Finish dance. But once done, you can run Interstate 76 from the Applications menu and it will work fine, from its own independent prefix.

A Note on Double Clicking

Double clicking a Windows application will always use the default ~/.wine prefix. So choosing another prefix requires using the terminal. Fortunately though, you only need to run the initial setup program (and wine tools) from the terminal because Wine creates entries in the Applications menu with the WINEPREFIX set. Basically, once your game is running fine you won't need to go to the terminal to run it, it'll just work.

Amnesia: The Dark Descent

2010-09-20T14:36:00.000+01:00

Just a quick blog post to plug what looks like an amazing game: Amnesia: The Dark Descent

Take a look at the video!

I haven't bought Amnesia yet (mainly due to having not completed the awesome predecessor, Penumbra yet) but by the sound of it it's a great game, and available for Linux DRM-free! Check it out!

Rooted your Orange Dext and the Browser isn't Working?

2010-09-20T09:51:00.000+01:00

An odd problem started the other day after I rooted my (Orange UK!) Dext, it wasn't immediate - I'm not sure what I did... anyway, the issue was that the default Android Browser wouldn't load any pages over 3G, neither would SkyFire, but Opera Mini would.

After some prodding and Googling I figured out how to fix it, here's how:

1. Navigate to Settings -> Wireless & networks -> Mobile networks -> Access point names
2. Select "orangeinternet"
3. Set the "Name" to "orangeinternet" (you must enter a name, and apparently there isn't one)
4. Select "Proxy" and clear the box (mine said "null")
5. Select "Port" and clear the box (mine again said "null")
6. Select "Server" and clear the box (again, "null")
7. Make sure the "User" is "user" (I didn't need to change this)
8. That's it, probably best to reboot the phone

That fixed it for me, hope someone finds it useful.

OilRush to be DRM free on Linux!

2010-09-10T15:22:00.000+01:00

OilRush is an upcoming game based on the Unigine engine. It looks amazing, check out the trailer:

If you read my previous StarCraft 2 rant, you'll know that I hate DRM and refuse to buy games that are DRM encumbered. So after some prodding by me over on the Phoronix forums one of the OilRush developers announced the following:

If there will be no major objections from the distributor, we plan to release at least Linux version without DRM.

This is brilliant news. Good going Unigine Corp.!

Putting Android 2.1 (adlxmod) on a UK Orange Dext

2010-09-05T10:03:00.001+01:00

Motorola suck. They really REALLY suck and I'm not buying anything manufactured by them in future and I'd recommend others don't either. Last year, when Android phones were really beginning to hit the market, I spent quite a while choosing the right one for me. I really wanted a keyboard and the price had to be right, so at the time the only option was the Dext on Orange. It was running Android 1.5 but I *knew* that Android phones get upgraded, right? Wrong.

Motorola have promised an update to the U.S. release of the Dext (called the Cliq) for some time, but the upgrade path in Europe, S. America and elsewhere was labelled "Evaluation in progress". This was the case for months and months. The upgrade website wasn't updated but a lead figure at Motorola had announced that all Dext phones would be upgraded to 2.1. This announcement led to many more people rushing out to buy a Dext. Unfortunately it was a lie.

On August 23rd, after 6-8 months of waiting for an update. The update status website change from "Under evaulation" to "Europe will not be getting the update". Unsurprisingly, Dext owners are really angry, not just because they were lied to, not only because they were strung along for 8 months, but because the U.S. Cliq is getting the update but Motorola can't be arsed to push it out over here! The software exists, we just can't get it. So, you have a UK Dext and want Android 2.1 - then you need to take matters into your own hands...

Installing a custom ROM on a vanilla Dext involves 3 major steps:

1. Rooting the phone (gaining super-user access)
2. Flashing a recovery image to the phone (enabling a custom recovery mode)
3. Flashing a ROM to the phone (installing the new operating system)

This tutorial worked on an up-to-date UK Orange Dext with a 5025 radio. I don't guarantee it will work for you on that phone or any other, but it worked for me.

Obviously, this will void your warranty, I don't accept any responsibility for breakage and I have no clue how it all works, this is just what worked for me. If you have a problem post over at modmymobile.com. If it goes irreversibly wrong then it's no-one else's fault but your own for trying it in the first place.

That said, this method of rooting and installing ROM is fairly straightforward and not as risky as other methods. It worked for me.

Before you start, first do the following:

1. Boot into Windows
2. Download the Android SDK from here
3. Extract it to c:\android_sdk or something
4. Download and install the Motorola USB drivers from here
5. Reboot Windows
6. Plug your phone in to Windows, choose "USB drive" when prompted. Copy all your files and data (backup) to your computer, and delete any large media files/documents from the phone. (Makes the nandroid backup quicker). Then unmount the phone and plug it back in again.
6. When your Dext says "USB Drive" or "Charge only" then choose "Charge only"
7. Download this
8. Extract it to C:\Moto_MSM_Root

Now head over to the rooting tutorial on modmymobile.com

Follow the steps after "Process"

Things to look out for:
1. Read the whole tutorial before doing anything
2. Make sure that you wait until "Forked xxxx childs" appears before pressing a key at that stage of the tutorial
3. Make sure after that step you definitely have a '#'

If you complete the tutorial successfully, then your phone is rooted; which means you have super-user access to the phone.

The next step is to flash a custom recovery image. The recovery image is booted when you hold down the camera button while you power on the phone. You need a custom recovery image to flash the Android 2.1 rom.

I used this one

Follow the steps there. Make sure you remove the /system/recovery.img file. To do this you may need to remount the system folder so it's not read-only. Follow the instructions here to do that, then remove the recovery.img file. After I'd removed it I re-flashed the recovery just in case, but that's probably unnecessary.

Now, disconnect the phone. Turn it off. Then hold the camera button and turn it on. Don't release the camera button until you reach a black screen with green text. When you do, press the volume down button and wait a few seconds. You should get a nice menu with several options, this is recovery mode. One of the options will be to run a Nandroid backup. Do this! It may take several minutes to run, if it starts taking longer (mine did) then something on your phone is confusing the backup.

If this happens, remove the battery and turn the phone on again with the camera button held. Then, when you get to the menu, choose "Wipe" and then choose the first option, then second and then third, one after the other. Before doing this make sure you've backed up everything you need to to your PC. Then, run the backup again. It should work now that you've reset the phone.

Once the backup completes (whether you had to Wipe or not) turn on the phone, and plug it into Windows. If you had to Wipe the phone then you'll see motoblur setup. Ignore it, don't do anything on the phone except choose "USB Drive" from the notification area. Copy the newly created "nandroid" folder from the phone to your PC.

Download the adlx ROM zip files from here you'll need both the 2.0-signed zip and the 2.0.2 patch zip. Download both to the top directory on your phone. Check your phone battery, make sure it's pretty full. Now safely remove, disconnect and reboot your phone into the recovery mode again.

Now, Wipe your phone by choosing the top 3 options under Wipe one at a time. Then go back to the menu, choose "Flash zip from SD". Choose the 2.0-signed zip file and flash that. Reboot the phone and hold down the camera button immediately (don't let it start up). Then once in recovery mode again, choose "Flash zip from SD" once more and this time choose the 2.0.2 patch zip. Once that is complete you can reboot your phone into Android 2.1.

Note: The first time you boot your phone after Wiping and loading the ROM will take some time. If you see the "Blur" speech bubble flashing repeatedly just be patient. Don't turn the phone off at this stage otherwise it can break stuff (that's what I did and I had to re-wipe to fix it). When the phone starts up you'll get the Motoblur account setup screen. Follow through the steps and then you should be all done!

Starcraft 2's DRM fail

2010-07-29T12:30:00.000+01:00

I've been out of the loop of mainstream PC games for a while, tending to buy Wii games or DRM-free indie PC games such as Osmos or the Humble Indie Bundle. But every now and then a game pops up on the news that I really really want. Last time this game was Spore, and then I found out about the DRM and I didn't buy it. Now this time it's Starcraft 2.

I remember playing the first Starcraft and loved it. I loved the look of Starcraft 2, but again another big game company fucks up by crippling it with DRM in the fruitless aim to reduce piracy.

Let me spell it out for you: DRM DOES NOTHING TO STOP "PIRACY" AND EVERYTHING TO PISS OFF YOUR CUSTOMERS!

I hear Starcraft 2 has already been cracked, so what was that, 1 day after release? Good going Blizzard, you've pissed off your customers for nothing. So, I will NOT be buying Starcraft 2 and judging from the comments on Amazon, I'm not the only one.

Seriously Blizzard. Get a clue.

Hurdles when Porting Games to Linux

2010-06-18T14:36:00.000+01:00

A recent Shot of Jaq episode described the many problems that indie game developers face when porting their games to Linux, let's break down the problems into categories:

1. Which libraries do I use?
2. How do I package the game?

So here we go.

Which libraries do I use?

This is the one that people make the most fuss about. When developing a game on Windows, you know full well that if you want to create a 3D enabled window, you have Win32 + Direct3D + DirectSound (or whatever it is now) right there. And it works. It works because the whole Windows game world develops using those APIs and they are well tested. When coming over to develop for Linux, many devs don't know where to look for the equivalents, and when they ask around they get different answers from everyone, because people recommend what they like, not what is the most sensible option. Let me answer the question right now:

1. For graphics, use OpenGL 2.1 (or 1.5 if you don't need GLSL)
2. For sound, use OpenAL
3. For windowing and input, use SDL

Now, before I get ransacked by people with opinions, I'll explain why :)

Graphics

This is the easiest one to decide. OpenGL is the only choice for hardware accelerated graphics on Linux. If you can do without shaders and target 1.5 you can get the lower end hardware, if you need shaders then go for 2.1 rather than 3.x or 4.x because Mesa doesn't support them (yet) and the open source ATI and Intel drivers both support it. You can of course check the version at runtime if you want 3.x or 4.x features, but don't rely on it.

Sound

This is the one that causes the most noise (no pun intended), ALSA? Pulse? OSS? etc. No you want OpenAL. OpenAL gives you a consistent 3D sound API that wraps the underlying complexity of various sound systems. It's not perfect, but it's definitely your best choice. Hemisphere games came to the same conclusion when porting Osmos. Just go with it and test as much as possible. openal-soft has a number of backends too, so if you don't have Pulseaudio, or whatever, it will still work. The openal-soft developers are really responsive. I had a load of help trying to diagnose a problem with openal + pulse (which was a bug fixed some time ago now).

Windowing and Input

I can tell this will stir up a hornets nest of people saying that straight X is better, and indeed straight X is what the Osmos developers went with. But SDL has been used for a load of games (World of Goo, Penumbra, Quake 4 etc.) it's pretty damn good. Again, it wraps the complexity of the underlying X and handles any quirks for you. Also the SDL developers are responsive to both feature requests and bug reports, and have a really busy mailing list. If you have any trouble, you have somewhere to go and get it fixed. If you don't think SDL is flexible enough, then go with X, but let me assure you - you'll be writing a lot more code, and that code is your problem.

There, done. By offloading the work to these libraries you get a number of advantages:

1. Bugs you find and report (and perhaps even fix) help everyone
2. They deal with the hard work for you, reducing the amount you need to code
3. They are widely available
4. All three of them have nice, consistent APIs

Packaging the Game

Packaging is a pain in the arse if you want to target as much of the Linux-based ecosystem as possible. Generally though, packaging in .deb, .rpm and .tar.gz in both 64 bit and 32 bit versions seems the way to go. Games in The Humble Indie Bundle were packaged in various different ways, but World of Goo had a .deb package that worked the best compared to the fiddling I had to do to get the others to run.

It's probably best to go with the distributions package manager to handle dependencies, especially for the big 3 libraries (GL, AL, SDL) and also FreeType and libvorbis. That's the approach Hemisphere games took and they seem pretty happy with the result.

Other Libraries

Obviously it's not just graphics, sound, input and windowing you need to worry about, here are some suggestions for other libraries:

1. Fonts - Freetype2
2. Image loading - Take a look at SOIL
3. OpenGL extension handling - GLee is popular, but not included in the Ubuntu repos, GLew does the same job and is in the repos.
4. Physics - Box2D for 2D, ODE for 3D

Clearing FileFields in Django's admin

2010-06-11T11:49:00.000+01:00

This post is as much a reminder for me as it will be helpful to others. Yesterday I added a couple of FileFields to a Django model, the point of them is to allow overriding of some site images. So the idea is that you can upload images or swf files to these fields, they'll replace the ones on the site, until you are bored of them then you can delete them and the original images will be restored.

After adding the FileFields to the model, they nicely appeared in the Django admin site. I uploaded an image, the override worked perfectly, now to restore the original image...

And that's where you hit a problem. There is no way in the Django admin to clear a FileField, you can replace it, but you can't clear it to NULL. Happily there is a workaround[1]. You first need to create a custom ModelForm for your model which includes an extra checkbox like so:

class MyCustomForm(ModelForm):
    clear_the_image = forms.BooleanField("Clear the image", required=False)

    class Meta:
        model = MyModel

    def save(self, commit=True):
        model_instance = super(MyCustomForm, self).save(commit=False)
        if self.cleaned_data.get('clear_the_image'):
            model_instance.the_file_field = None

        if commit:
        model_instance.save()

        return model_instance

Then in your MyModelAdmin class:

class MyModelAdmin(ModelAdmin):
    form = MyCustomForm

That's it. When you save the form, it will see if you asked to clear the image, if so it will set it to None and then save. Job done.

[1] Adapted from this: http://www.developerit.com/2010/04/17/django-admin-add-a-remove-file-field-for-image-or-filefields

The Humble Indie Bundle on Ubuntu AMD64

2010-05-14T10:56:00.000+01:00

Just a quick post, because basically I couldn't find this information elsewhere and I'm hoping someone finds it useful. Like thousands of other people I bought the Humble Indie Bundle while it was on sale and it is amazing. However, for ages I had no luck installing Lugaru. I kept getting messages like this:

kazade@argon ~ $ chmod +x lugaru-full-linux-x86-1.0c.bin
chmod: cannot access `lugaru-full-linux-x86-1.0c.bin': No such file or directory
kazade@argon ~ $ chmod +x /home/kazade/Downloads/lugaru-full-linux-x86-1.0c.bin
kazade@argon ~ $ ./lugaru-full-linux-x86-1.0c.bin
bash: ./lugaru-full-linux-x86-1.0c.bin: No such file or directory

If you have this problem, the solution is to install the ia32-libs package. Then the installer will run, simple eh?

The Ambiguity of Hiding Windows

2010-05-03T14:01:00.001+01:00

So, Ubuntu 10.04 LTS has been released and it is pretty damn awesome. Again I don't think it was entirely ready, I think more time could have been spent fixing video driver bugs because there are a lot of people complaining about hitting a "black screen" (see my brainstorm idea: http://brainstorm.ubuntu.com/idea/24727/ ).

Anyway, one of the features of Lucid is the new indicator applet, designed to replace the notification area with a consistent interface. I love the indicator applet, except for one thing, this:

The indicator applet replaces the menu functionality for the icon brilliantly but it goes a little too far in replicating the functionality of the notification area. This is a long standing bug bear of mine. Many apps on Windows, and then consequently other desktops, allow minimizing an application to an icon. Why?

To clear the window off of the desktop? That's what minimize is for. "But.. but.. then it clutters my taskbar!" I hear you cry, and that my friends is the point, the minimize to icon functionality is a workaround, a plaster over the fundamentally broken taskbar. The main problem with the current window switcher is the size of the elements. Even with a widescreen monitor you can fill it up pretty quick because window titles take up a lot of space. Application grouping helps to some extent but each element still takes up more room than the icon would do alone.

But that's not the only reason for the existence of "minimize to tray". When you are looking for a window in a list of windows, the less there are the easier it is. That's why you don't want Rhythmbox, or your IM contact list cluttering up the bottom. So the flaws with the window switcher are:

1. Each element takes up too much space
2. There are too many elements

You can also add:

3. You can't read the entire titles on the windows

We can easily solve these problems. Windows 7 had the right idea by replacing the window items with icons. We have a decent alternative on Ubuntu too, it's called DockbarX.

Don't believe me, try this. Add the DockbarX PPA and replace the window switcher applet with DockbarX. Now, make your Rhythmbox visible via the indicator applet and minimize it. Now go ahead and work with your computer. What do you notice? It takes up hardly any room AT ALL, in fact you won't even notice it's there because every time you go down to that Dockbar you'll be going there for an application window and finding the application is dead easy when its icon is right there and there is only one of them. Hover over the application icon and bingo, up pops the list of windows for that application with FULL TITLES.

Rhythmbox won't get in the way because you won't be drawn to it you are looking for a bright orange Firefox window for example. And you can open a shedload of windows and still have plenty of space in the taskbar. If you wanna skip a track, or see what's playing then you can do, using the indicator applet.

So, if there is one thing I would do if I was in charge of 10.10 it would be this: replace the window-switcher applet with DockbarX and remove any minimize to tray functionality from the indicator applets. It removes the ambiguity of "where did I minimize that window to" and it makes life much MUCH easier and consistent.

Where I'd put the buttons

2010-03-08T16:54:00.002Z

Recently during the Ubuntu 10.04 (Lucid Lynx) testing cycle, Canonical introduced new branding and themes. The themes are really nice, still a little rough around the edges, but come launch date they will be slick. However, sneaked into this re-branding was a change that was initially thought to be a mistake.

The window controls moved.

The window controls (Minimize/Maxmize/Close) moved from the right hand side of the window, to the left hand side of the window. Not only that, but minimize and maximize swapped places; just to confuse everyone that little bit more.
Now, the problems with this have been discussed many times over the last week so I'm going to be a bit more constructive on the matter. I'm going to explain what they should have done in my opinion (!).

Now, let's get a few things straight. Firstly, if a button is at the corner of the window it is easier to hit. Secondly, if a button is destructive, it should not be next to a common action (in case of a miss-hit). Thirdly, I'm going to ignore right clicking, and double clicking on the title bar, these things are visually non-discoverable you need to find them by accident, and just cause you know about them doesn't mean everyone does. Got it? Good.

The Close Button

This is the one. This is the real cause of the complaints from users. There are two things special about this button.

It's destructive. The only really destructive of the three.
It's the most used. Of all the buttons it's the only one that must be there.

(Note, obviously, most used is dependent on user habits which is why we need usability testing - which I haven't done. But according to my logic it must be used at least once, which is more than the other two.)

Why is it the only one that must be there? Well, because you can use the taskbar to minimize or switch applications or you can resize the window to fullscreen. You cannot (in a easily discoverable way) close all windows without that button being there (before anyone says it; not all windows have menus).

So, because it's destructive, it should be well away from other common actions on the window. Let's take a look at a window shall we:

So, where do we put the close button? Well, the left hand side has a bunch of common actions, so we should probably steer clear of that side (take note Canonical!). That leaves anywhere right of the Help menu... as an applications can have many menus and can be resized so they are smaller, it would make sense to put it as far away as possible – so yeah on the right.

Now, onto usage, because the close button is the only action that must be performed, it makes sense to have it in a corner, that way you can hit it more easily. So, let's put that one there:

So cool, that's that one done, now let's move onto the next one...

The Maximize Button

So, arguably this is the next most important button, the reason? Well, you minimize to get to windows behind the one you are using, which you can do with the taskbar. Maxmize can only be done by drag-resizing (a pain) or right clicking (non-discoverable). So, after close it's pretty important. So, where do we put it? Well, a corner would make sense, but what if we put it next to the close button anyway? Well, there you've broken one of my rules above, you've put a common action next to a destructive action. So, let's just put maximize on the other corner:

Now the final button (or is it?)

The Minimize Button

So, this one is easy. It's a non-essential, non-destructive button. So, following logic it can go anywhere that's not next to a destructive item. Well, that just leaves next to the maximize button, but it doesn't need a corner so let's put it the other side:

There, for balance you should probably choose a theme with a centered title. But still, this layout makes more sense. You reduce the risk of closing something accidentally, and the most used items are in the corners. As a side effect you also keep two related options (minimize and maximize) close together.

What About the Menu Button?

I'm a bit ambivalent about this one, I'm not really sure where it belongs. The other three buttons change the size of the window (or make it go away) and don't pop-up a menu. It doesn't really fit with the others, (also the functionality is available on right-click, albeit undiscoverable). If I was to choose a position, I'd put it next to minimize, but I think it's arguable whether it needs to be included at all.

Conclusion

I'm no usability expert, but if I was to redesign the location of the buttons, (which, I'm not sure they need redesigning and breaking that muscle memory) that's where I'd put them. Also it has the pleasant side-effect that the close button doesn't move from the “normal” arrangement. I'd be happy if Canonical changed to this way, at least there is some obvious logic behind it... obvious logic makes me happy.

OpenALSoft/Pulseaudio: it's not me, it's you.

2010-02-19T09:44:00.000Z

I learnt a valuable lesson this week. If you have rewritten your code 3 times, and your tests all pass and you understand every part of it and yet it still doesn't work ... it's probably something not to do with you.

Last weekend I decided it was time my game gained some sound. I'd just finished the game menu screen and figured that some music would make it seem a little more complete. In an attempt to follow the KISS principle I decided to keep it simple, I'd write a class that just plays an OGG file in 2D. No multiple sources, no bells and whistles, nothing fancy, just load an OGG and play it. A quick Google search turned up this gem of a tutorial, so I figured it was a 10 minute job. When the time came to do more, I'd look for a decent high-level library, or just steadily build on my simple base code but for now, I figured, following this tutorial would teach me a little OpenAL then I could move on.

And for a little while I was right. I wrote my class, loaded an OGG file and played it with OpenAL by loading it into a single buffer and binding the buffer to the source before calling alSourcePlay(). It worked!

...

For about 2 seconds. Then it crackled and went silent.

I assumed that the problem was the track I was playing was too long to be bound in a single buffer, and instead I figured I should break it into smaller buffers and feed it into the source to play. Possibly a bad assumption, I guess I should've tried playing a smaller sound to see if that was actually the case - but I was having fun, and queueing the buffers looked simple enough.

So I got to work, I decoded the OGG stream into a vector of vector<char>'s the idea being that as room became available in the queue I could grab the next chunk of data and queue it up ready for playing. Again, it only sort of worked. The track would buzz for 10 seconds, then play a second or 2, then go back to buzzing, then play some more. Sometimes it would play a whole 30-40 seconds perfectly, then the buzzing would start again. I fiddled with buffer sizes, buffer counts, filled my code with logging statements (the buffer queuing just seemed to stall while the buzzing took place). I tried to simplify it, removing lines of code, reorganizing until the code was slim and streamlined, I switched from vectors, to filling out static char* buffers. It made no difference.

I downloaded the source code of various apps, SuperTuxKart uses OpenAL and apparently the followed the same tutorial as me! In fact all the examples I could find had very similar code to the same tutorial, and my code looked pretty much the same.

This is the point I should have realized something else was at work here, in fact I did try upgrading ALSA but that changed nothing, so what did I do? I came up with a new design, one that had many benefits and might, just might have the side effect of solving the problem.

The problem with the previous attempts was I was loading and decoding the entire OGG file in one go. A decompressed, high quality OGG takes up a lot of memory, it's REALLY wasteful to decode the whole thing and keep it in memory. The other thing I had to be careful of was that multiple sources could play the same stream without an issue. I decided instead to load and store the compressed file data. Then create an OggDecoder class which each source gets an instance of that decompresses the data from memory on the fly. The benefits of this approach are huge, you don't hit the disk while playing, you keep memory usage down, and multiple sources can play from the same compressed data, and the code is pretty small too. So I finished, stood back and admired my work and pressed "compile and run". It worked! I was relieved. But just in case, I ran it a second time (it had *occasionally* worked before, it just wasn't consistent). You can guess what happened, the buzzing was back. Repeated runs left me with the same problem.

I was about to give up, about half way through this process I discovered cAudio which was basically where unintentional feature creep was pushing my code anyway (while trying to load an play a sound, I'd come up with a whole multiple song streaming solution with pluggable decoders!), so I figured I'd dump my code into the "deprecated" folder that I keep, and just use cAudio. Just as I was about to give up I found a forum post where someone had similar problems and they solved it by upgrading the OpenALSoft libraries. I gave it a try and lo and behold, it works!

I don't know why it works and didn't before, perhaps an OpenALSoft conflict with PA? Perhaps a bug in OpenALSoft? I dunno, and I don't care, if the problem occurs on another PC at least I know how to fix it.

The only regret is that I didn't realize it wasn't me earlier. I'd literally rewritten the code several times in different ways while comparing to code in other projects. Alarm bells should have rung earlier. Oh well.

Further Scene Editor Progress

2009-11-17T09:24:00.001Z

So as I've mentioned a few times previously, I'm working on a scene editor. The goal of which is to make it easy to produce content for the many game ideas I have :)

So far progress is slow but steady, I'm being a bit of a perfectionist so large chunks of the code have been written at least twice, sometimes three times and there are still things I'm not happy with.

I'm currently working on importing Wavefront *.obj models. I know I've got a partial obj loader somewhere, I just need to find it, and integrate it. These are the goals for the first release:

1. Load and save irrlicht scene files

2. Create, manipulate, delete cubes, spheres, meshes, lights and terrains

3. Create, edit, delete and apply materials

4. Cut, copy and paste meshes

5. Manipulate the scene tree (make parent-child relationships etc.)

At that point the editor can be used to create landscapes. The following release will add:

6. Custom entity positioning

7. Advanced object properties (invisible, transparent, etc.)

8. Skyboxes

9. Octree based culling

And then some time later:

10. Python integration

11. More file formats

Criticising the Koala

2009-11-06T09:53:00.001Z

So, unless you've been living under a rock for the last month or so, or you've been busy with Windows 7 launch parties, you will know that Canonical launched the latest version of Ubuntu, version 9.10 the Karmic Koala.

I spent launch day in #ubuntu-release-party along with over 1000 other people anxiously awaiting the release. I, of course, was already running 9.10, on my desktop, laptop and work desktop. I haven't had a single problem with any of them, post-beta anyway.

Still, I can't help but think that this particular release was a little rushed.

The updated boot splash is a massive improvement, and it saw a lot of work over the weeks up to the launch, but even here, there are a few niggly little issues... even now I still get an occasional worrying "Waiting to mount home" message underneath the minimalist white Ubuntu logo. The new X splash doesn't fade out properly all of the time, on my home desktop it never does. The background image showed visible banding on my highest resolution monitor, although this seems to have been rectified now. Also, I haven't seen a disk check in a little while, but the last time I saw it - it was scrolling past each percentage point. All these things show a lack of polish that I'm fairly sure an extra weeks development would have solved. Before anyone asks, yes I checked these bugs were reported.

I'm actually pretty impressed with the log on screen, of all of the artwork I'd say GDM and the white Ubuntu logo on shutdown were the parts where I actually thought to myself - yes this can compete with OSX. That said, I did feel there were better background choices on the Ubuntu wiki, and I do understand when users say it feels cold... because.. well it does, it's hardly sunshine and flowers is it?

Now, after log in is where everything falls apart. The introduction of the Humanity icon set was a step forward, but whoever decided that a bright orange background would look good with the new boot splash was frankly off their head. Why didn't they just use the same background as the GDM? Yes it's still dull and brown, but at least it would have been consistent.

The GTK theme changes were just a mess, the window borders have changed to a dark muddy brown, the previous Human colours at least would have matched the orange background slightly... the whole desktop theme seemed like a last minute rush because all the time had been spent on boot. Again, a week longer and we could have had that extra polish that Ubuntu deserves.

Still, this is just the beginning of the design work, hopefully 10.04 will get this stuff sorted once and for all.

Generally speaking, functionally Karmic is running well for me. My ATI based desktop still has slow minimising when Compiz is enabled, I really hope this is fixed soon as it makes the whole desktop feel sluggish. I've grown accustomed to the way that notifications are displayed, however I still believe that positioning them at the bottom of the screen would get in the way even less, and I stand by my feeling that the position should be configurable, because no matter where the notifications are, they will get in the way of some application that a user regularly uses.

Pulseaudio has really improved this release, I haven't had a single sound issue so far, however it does sadden me that Ubuntu still aren't paying attention to upstream (e.g. the removal of rtkit) although I've heard there is more communication going on now.

Empathy. If there was one thing I would say was a complete bloody mess in 9.10 it is the premature replacement of Pidgin with Empathy. I know that Empathy is the future, but that future is not here yet. Empathy is still buggy, it looks like a mid 90's throwback and it still lacks the many features that Pidgin offers. I don't understand why there was such a rush to replace Pidgin before Empathy was ready? Still it's easy to swap it out for Pidgin so I guess I can't complain too much.

The indicator applet is nice, although I do wonder why I can launch applications there when there is a perfectly good applications menu. I thought introducing more than one way to do something was bad from a usability POV? It makes the whole point of the applet ambiguous. Leave the launching of applications to the applications menu, and leave the indicator applet to well, indicating notifications.

The Software Centre is a massive improvement over Add/Remove, I do wonder whose idea it was to give it a blue background though. So now we have black, white, brown, orange and blue. Talk about consistency! I thought Mark employed a design team! I also still don't agree with the "Close" menu option though, it should definitely be "Quit" IMO and I don't buy the excuse I was given on the bug report. "The Ubuntu Software Store has no need to require users to know whether it is "running" or not"... what? Course they do... they opened the bloody thing.

So lots of little issues, I'll continue running 9.10 but I don't feel that this was Ubuntu's best release (9.04 was) but there have been a lot of changes (new GDM, GRUB 2, Xsplash etc.) that will hopefully mature over the next 6 months to form a solid base for 10.04, being an LTS, this is the release to watch.