See also more recent irritations

March 6th, 2004

Today's irritation is parking at Cambridge railway station.

Cambridge railway station has a scheme to keep the car park available for rail travellers instead of people shopping in the city centre; getting a ticket to use the car park is quite expensive (much more expensive that other nearby car parks) but you get part of that money back when you buy your ticket.

The last time I did this was in November. It cost £6, of which £3 gets refunded. The trouble was the machine only takes coins up to £1, and I didn't have enough. It doesn't take £2 coins, or notes, or any kind of plastic card. I had to go into the station to get some change, back to the car park to buy the car park ticket, then back to the station to get my train tickets and car park refund. The car park was nearly full so I had to park quite a distance away from the station, so that all took quite a bit of time; I missed the train I intended to catch (which didn't matter much, because back then Cambridge had regular fast connections to London. The cancellation of the Cambridge Cruiser service might become the topic of its own rant if it irritates me sufficiently again).

Since I was meeting some people at the station today, I didn't want to miss my particular train and aimed to come prepared. I got five £1 coins from my housemate, and a small collection of my own change, ready to pay the machine. Then I picked up a metric handful of extra coins, thinking it might be nice to have enough change for some snacks or a drink on the journey, including some pound coins I noticed which had slid under a pile of paper and I had forgotten existed. It was just as well that I did (I count it as a reminder that God looks after me all the time, when He engineers subtle or trivial problems to work out obviously just right) because when I reached the station, all the coins in all of my pockets together reached exactly the right amount of money to pay the ticket machine, which has risen to £10.

You now get £7 back, so I'm not complaining about the car park being expensive as such, because the charge hasn't increased and £3 is quite good value. But £10 is a lot of change to carry around, would it really be so hard to make the machine accept notes? Other automated payment systems can do it (e.g. Tesco's self-service, although I really must get around to writing about that one day for different reasons).

The whole scheme has another drawback, which is that very few people can use the fast, shiny, automated ticket dispensing machines (which are actually rather good) because those can't give the parking refund. Everyone has to queue up for ages to get to the kiosks instead.

By the way, MacPlay is still irritating at the time of writing. The 60 Hz monitor issue is patched, but the game still cannot run properly under MacOS 10.3.

January 31th, 2004

Today's irritation is MacPlay.

I simply cannot believe that "No One Lives Forever 2" is still not properly compatible with the version of MacOS which was already current when it was released. At the time of writing, Panther (MacOS X 10.3) has been current for over three months, NOLF 2 was released towards the end of November 2003.

It only works with Quicktime 6.3 - not 6.4 or 6.5 - so if you've upgraded Quicktime on Jagwire, or installed Panther, you're out of luck until they get a patch finished. I can't believe it was ported by the Omni group, who have done near perfect jobs on everything else I've seen of theirs.

This, and a really, really stupid bug which means it can only play on monitors set to 60Hz. That doesn't seem to matter to my LCD, but it would really annoy me if I had a CRT with phosphor tuned for a higher frequency.

Annoyingly, if I ask for my money back it probably only hurts the retailer, whose fault it isn't. But I won't be buying any more MacPlay products unless I get a better impression of their support - I remember how long it took to get RealMyst working on dual-cpu boxes, and for how long the official fix was to disable one of the cpus! And there are no plans to add HID joystick support to Incoming (even though it's just about the only way to play that style of game).

April 19th, 2003

Today's irritation is the way an otherwise great game can be spoiled by bad design decisions, even minor ones. I'm going to discuss Super Monkey Ball Jr on the Gameboy Advance, not because it's the worst offender in any way, just because it's a game I've bought recently.

It could have been so great. It's all displayed in solid 3D and moves more smoothly than I would have thought possible on that speed of ARM7 chip, which has no floating-point math hardware. All the more irritating, then, that the small point of making the character easy to control seems to have been left off the developer's agenda.

The controls are camera-relative, so pushing up moves "into" the screen. The problem is that the camera doesn't point in any direction in particular. It points generally toward the last direction your monkey moved, but rotates quite slowly and lags behind by several seconds. Pushing left or right moves you forward and in that direction (Yes! That means that your character, walking on foot, has a non-zero turning circle. Congratulations for that, Sega, with an honorable mention to the developers of the GBA version, ironically named "Realism".)

Anyway, to turn 90 degrees to the left, you hold left on the direction pad until your monkey has walked far enough to face the correct direction. Then you have to let go, because if you keep pressing down you'll turn too far to the left. But lets hope you've got enough momentum to keep rolling for a while, because if you press up before the camera angle has caught up with you, you'll head off to the right again.

Think how difficult it is, in real life, to pick a direction and walk along it in a straight line (i.e. not at all). Why should it be any more so in a computer game?

Even to reverse direction (pressing down makes the monkey turns 180 degrees and start walking; no turning circle, just as you'd expect of any protagonist with feet) involves a second-guessing game between your control pad and the cameraman. And here we are, Gameboy Advance with two left and right shoulder buttons which are going totally unused - how hard would it have been to have those buttons rotate the camera view? That would be a perfect solution to what ought never to have become a problem. It's enough to make me think programmers don't play the games they write any more.

April 13th, 2003

Today's irritation is the Carbon event model in MacOS X Jaguar, which actually seems to put effort into making it difficult to obey the Human Interface guidelines with regard to window handling.

Specifically, I get a mousedown event when the user clicks my window. If that window is in the background at the time, my response should be to raise that window to the front and otherwise ignore the mouse click (that is to say, controls in a window should not respond to the click which brought the window to the front).

Jaguar makes life difficult in two ways. Firstly, calling SelectWindow() or ActivateWindow() or BringToFront() ot HiliteWindow() all seem to have no effect at all. Instead, the trick is to indicate to the event manager that you did not handle the event, which lets the standard handler do the window management for you.

Which would be fine, were it not for the fact that Jaguar then sends a second mouse down event, for the same click, with the window now at the front. So I have little choice but for my controls to respond to that click, which they're not supposed to.

"Ah-a," you say. "Can't you just wait for a mouseup event, corresponding to the mousedown which brought the window forward, and ignore any extra mousedowns until you get it?". Well, yes, and I do that now. But it's not reliable, and here's why:

The carbon event manager does not necessarily send matched pairs of mouse up and mouse down events.

If I let the standard handler interpret a click in the window's title bar, I recieve a mouse down event but no mouse up event. It's entirely possible that Apple could change the standard handler for the content region to match, such that I get the mousedown but no mouse up (because a consistent API semantic is good, right?). This means I'll wait for a mouse up event which isn't coming, and the user will need to click an extra time in the window before the controls respond.

In other words, my app will probably break with an OS upgrade at some undetermined point in the future. Thanks a bunch, Apple.

Am I wrong?

If you have any comments or questions about the articles here, send feedback