A Quick Introduction to KGLT

Those of you that follow me on Twitter, or have the pleasure to listen to my waffling in person, will know that I'm working on a game engine - although I'm still not convinced that's the right terminology. Let's call it a "game framework".

There's a well known saying in the game development world, it goes like this: "Write games, not engines". And, it's actually really good advice, there are plenty of game engines out there, many of them open source and free to use commercially. On top of that, writing a game engine is hard, really hard. It probably is the most difficult user-space application that you can write, and only the insane or brilliant even attempt it.

I must be insane.

Now that I've painted a clear picture of why writing a game engine is an extraordinarily bad idea, let me explain why that's pretty much exactly what I'm doing.

Every so often I grab an old PC game from my shelf, shove it in the DVD drive and prod around the folder tree. If I find something that looks like it could be a new texture format, or model format, I can't resist firing up a Hex editor and trying to decipher it. I've had some moderate success too. I successfully reverse engineered the Ignition texture format for example. And it was during one of these reverse engineering stints that I realized I needed a game engine.

The reason was that, reverse engineering something like a 3D model format is a bit of trial and error, for example "Is that set of floating point data the vertex positions or the vertex normals?" might be the kind of thing you can't decipher just by looking at it in hexidecimal. This is why I needed a game engine, I needed a way to construct a mesh from what I thought was mesh data, and I needed to be able to iterate quickly if a certain block of data wasn't what I thought it was.

After trying a few game engines, I couldn't find anything that did exactly what I wanted. I found loads that did far more than I wanted, but I just needed something simple. And then KGLT was born.

I started by creating an OpenGL window with SDL, then I needed a way to create meshes, then a way to manage those meshes, then a way to skin those meshes, then I needed to render them faster... before I knew it I had been coding this thing for a year and it had grown beyond what I set out to do, hell, I never did get around to reverse engineering that format!

So, now KGLT exists. It's on my GitHub and it provides a really simple API for building up a 2D or 3D scene. It's written in C++ (although you don't need to worry about memory management or any of that nonsense, it's all taken care of). The whole thing is based around a few core concepts:

• When you create a Window, it owns a Scene.
• Each Scene can have multiple SubScenes, although a Scene starts out with one.
• You can add each SubScene to the Pipeline for rendering by specifying a viewport, camera, target and priority.
• To render things, you create Entities from Meshes. A Mesh can be shared across Entities.

KGLT is different to other game engines, it doesn't try to be ultra-flexible, or ultra-powerful, or all encompassing. It just provides a common framework for building on top of, a bit like Django in the web world.

KGLT is still in heavy development, but it would be good to get feedback/other contributors. So if you are into game development and you fancy playing around with it, give it a go! Let me know how you get on!

So, You want to Write your own Linux Display Server?

UPDATE: It's been confirmed that Ubuntu will be switching to a new display server called Mir. Canonical have posted some FUD about Wayland on the documentation site, and it turns out the Mir devs didn't even understand Wayland enough to make a decision.

Yesterday, OMG! Ubuntu! published a news article stating that Canonical are working on their own display server. If you don't understand the technical details of a display server, what it's job is, and how applications talk to it, then you may think this is a good thing. You may think, “Linux is about choice” or “perhaps this will be better than the alternatives”. But you'd be wrong, horribly wrong.

Introducing PasteShare

If you are a programmer, and you collaborate with a team of developers, you probably make regular use of a "paste bin" site. Paste bins are websites where you can enter some code into a text area and share the link with others. Sort of like a public notice board for code.

Sometimes the code that is pasted is useful to others; an algorithm or boilerplate code that might help someone in future. The problem with current paste bin sites is that code is still copyrighted. If someone stumbles across your paste in future, they won't be able to trace you to ask permission to use it, and they don't implicitly give you permission just because it's available to the general public.

PasteShare is different. On PasteShare whenever someone pastes some code, they explicitly release that code into the public domain with the Unlicense license. If you find some code on PasteShare, you are able to use it in whatever way you see fit - there's no need for permission.

I'll continue to improve PasteShare over time, and in particular I want to make finding useful code easier, so expect plenty of improvements on that front. If you think of anything that would be useful to you, feel free to tweet me!

Now, go share your code!

Goodbye Ubuntu

I considered calling this blog post "I'm moving to Debian" but if I did, people would probably assume that I'm doing so in a trantrum, and just posting to rant.

But I'm not, I'm not angry, maybe just disappointed. I've had the love of Ubuntu beaten out of me over the years...

Ignition Revisited

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

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

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.