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!
Saturday, 10 December 2011
Monday, 9 May 2011
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.
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.
Sunday, 10 April 2011
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.
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.
Monday, 4 April 2011
Investigating X-Wing (OPT and XWI file formats)
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. :)
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. :)
Friday, 1 April 2011
C++ Timer Class
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().
Yeah I know, it's basic and anyone could've written it, but still might save someone 5 minutes :)
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 :)
Wednesday, 16 February 2011
Linux Mint Debian Edition - First Impressions
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.
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.
Tuesday, 18 January 2011
Reverse Engineering the Abandonware Game "Ignition"
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.
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.
Tuesday, 11 January 2011
PPA For My Game Developer Kit
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.
Subscribe to:
Posts (Atom)