Well, BT have (finally) managed to sort themselves out and install a phone line into the new office, which was the only thing holding up us moving in. As such, I popped along yesterday to have a look again at it properly, and I’ve now got the keys! Very exciting, and I much enjoyed just sitting in the big leather chair and trying to think of all the things that I’d need to sort out to properly imagine working there. I think most notably the place needs some coffee! Can’t think straight without coffee. Here are some pictures so you can judge for yourself – it’s bare just now, but I’m sure I’ll manage to get some character in there soon enough.

Our lovely view (it’s 3 floors up)

Nice big leather chair for my desk. A bit ratty, but hey, furniture that’s free you can’t complain about.

Pete gets the littler desk (have to enforce my dominance over the proles somehow)

And room for “employee number 3” when they turn up.

So, once there’s an obligatory Lara Croft poster up, PCs with cables trailing all over the floor, and a whiteboard or two covered with cryptic programmer like notes, I’ll post some more pictures for you to compare. I’ve also got to update the website with the new address and directions to us, but I think I’ll wait until we’re all properly installed. Have to make the move go pretty smoothly though, as we’ve got lots of work on in the next month, and not too much time to do it. So I should get back to it!

You know, it’s days like this I’m glad I don’t have to go outside to work. Miserably cold, damp and grey. But for me it’s almost a good thing – no glare in my eyes making it hard to see the monitor, no stiflingly hot room once the PSP kit and both PCs have been on for a while.

Most of the performance optimisations have been done now – turns out the horrible slowness was almost entirely down to the big textures, which far exceeded the texture cache the PSP has. So trimming colour depth, dropping the resolution a little, and swizzling the textures have all combined to get us back to a healthy normal frame-rate again. Not the 60fps we get on the PC, but certainly playable. So it’s time to put the optimisation bat back down again, and wade into new features (animation and audio next).

On balance though, the PSP hasn’t really impressed me so far. I realise that hand-helds are supposed to be underpowered, but I just groan whenever I have to try and read something on the low-resolution screen. We haven’t ventured into using UMD for loading yet, but I suspect that would irritate me even more – the load times are already over 10 seconds, and that’s loading a tiny amount of assets. I’d be interested to get our hands on a Nintendo DS for comparison – it’s probably got similar issues, but I’ve got “grass is always greener” issues right now.

So as I’m waiting for a nearly full rebuild to complete, I thought I should write up a blog entry. Previously I’ve not been writing much because of the upheaval due to moving and generally been busy sorting out a whole bunch of things. This last few days however, I’ve not been writing much because I’ve had my head deep in coding work, which is much more enjoyable! Of course, from your end-user perspective, it doesn’t really matter why.

Anyway, this week has been particularly busy with coding, because we’ve finally got things visible and running properly on the PSP, almost as well as they were on the PC, which is immensely satisfying. Unfortunately, it has highlighted all of the things that we need to fix because the PC let us get a way with a lot, performance wise, and still ran well. But that in itself is good, because it means we get to wade in and tackle some nice solid problems like “the texture format is too fat”, or “we’re making too many state changes”; for which we can see solutions, apply them and instantly see results in the form of improved performance. It’s a standing rule that you shouldn’t optimise too early, because you’ll end up wasting effort. However, when optimisation is appropriate, it’s definitely a satisfying task. As problems go, those are the ones programmers like the best.

Although we should have moved into our new office by now (by last week in fact), BT have been dragging their heels sorting out getting a phone line installed, and while my new landlords have been very understanding about it all, it’s been quite frustrating. I would have liked to have been in and set up by now, so that it was no longer nagging at the back of my head that we have to move in the future. Still, I’m sure the wait will be worth it, and instead I code away here, surrounded by still packed boxes of kit, all still waiting to move to the new office before I unpack them.

Right, build’s done – back to palletisation.

There are few things worse as a programmer than to know that you shouldn’t do something, know all the reasons why you shouldn’t, but yet you do it anyway. You tell yourself that it’s more important to get things in quickly, that the code is only preliminary or temporary. You tell yourself that it’s better to get things in so you can see whether or not the whole approach will work, and that taking time on the details now would be premature optimisation.

Of course you know, deep down, that the code that is supposed to be temporary will stay, because it works. Any bad things you put in there will be left with a @todo comment next to them, and shuffled down the priority list. Which might seem like a good thing on the run-up to a deadline, but is so many times more irritating when it comes back to bite you later on.

In this particular case, the standing rule we have at the Company about programming for a fixed memory environment, even on PC, was the one I was ignoring. We were initially developing for PC, and memory handling there can be handed off to the operating system heap management and forgotten about. On every other platform though (especially PSP for which we are now porting things), you don’t have that luxury – every drop of memory has to come from the single small fixed arena, any allocations from outside of that will just fail.

So I had to spend a couple of days, going through all the allocations in the code and plumbing through proper fixed heaps so that it was clear where all the memory was coming from. Two days, and probably that in itself wiped out any gains we made in the original PC development by working fast and loose.

In summary then, no lying to yourself when it comes to weighing up pros and cons of doing something in a way that you know isn’t going to be good enough in the long term. Oh, and work to a fixed memory environment. Even on the PC. It will make your code tighter and faster, give you a clear idea of what your memory footprint is, and help reign in the inevitable problems when your memory usage runs away with you and you have to spend time tracking down who is wasting memory and where.

Virtual memory hides a lot of sins from you as a developer, but it is a crutch which you can all too easily become addicted too. It doesn’t take much to engineer systems to avoid memory fragmentation and waste, but re-engineering them once they are embedded is difficult and problematic.

Well, you’d think that being isolated from the many distractions the Internet has to offer would make me more productive, right? Not a chance. Source control access over dial-up is excruciating, and I very much live by the policy of many small commits rather than few big ones. So when Eclipse managed to get my broadband back to me on Tuesday (a whole week ahead of their worst-case installation date), I breathed a big sigh of relief. And downloaded about 3.5GB of stuff in the first 24 hours!

Anyway, I’ve learned my lesson, and the phone line for the new office is being installed in advance of us going in, and I won’t be shifting operations there until we have net access up and stable. Oh, and yes – new office! Admittedly it’s just a room, but it’s proper office space, with room for 3 or 4 of us, central Edinburgh, nice street. Pictures and more details will come closer to the time, but suffice to say I’m quite excited. This will give us the chance to hire additional people (not just those I can trust to work from home), and aside from anything else should satisfy Nintendo’s strict policy for developer status. Add to that the fact that Nintendo development kits are really quite cheap, and we’ll be seriously considering getting one or two to work on our own stuff in addition to any work for hire jobs we take on.