What would we do without Jeff?

In previous posts, we've alluded to Jeff's design skills. Turns out, he's even more talented than that.

Over on the Photostorm page, under Scene, you'll see he gets a credit for music as well.

He's not just a guy in a suit, you know!

Last-minute launch hiccups

Well, we've just done our biggest, most complicated launch yet, and we're bloody pleased that it nearly all went to plan.

However, there are, of course, a few outstanding problems that we'll address as soon as we can. F'rinstance...

1. We can't accept PayPal just at the moment. Credit cards work fine, but PayPal's not going through. We're sorting this out with them, and we expect to have it up and running in a few days.
2. We're having issues with taking American Express cards. Again, we're taking it up with them, and that should be fixed soon.
3. If you've got unpurchased items in your shopping basket from a previous trip, you'll need to clear those out manually, otherwise it'll try to sell you those as well as a subscription.
4. A few people are having problems logging in with Moviestorm 1.2, and we can't quite figure out why. If this happens to you, change your password and you should be able to log in.
5. There's no message of the day on Moviestorm 1.2. It works fine on the development service, but it doesn't work when we make it live. It seems to be something to do with Amazon s3, and if we were a little more awake, we'd probably be able to figure out what. That should be sorted tomorrow. If it was there, it would look like this, but bigger. And you could click on it and get yourself a sub.
   
   
6. There are some visual inconsistencies in the site. We've moved stuff to new servers, implemented new CSS, and changed the back end systems, and guess what? We missed a few bits. We'll find 'em and fix 'em as we go.

There's more, of course, and we'll get to it all in due course. And doubtless, you'll find a whole bunch of other things we missed and tell us about them in the website forum and the feedback forum.

Anyway, thanks for your patience. We're off to put our feet up and perhaps sip a small glass of sherry. Just the one. Between us. We reckon we earned it. Especially Yolise, who shouldered the burden of the Web site work.

Oh - and to our American friends - happy Thanksgiving!

Quiet before the storm

It's all been a bit quiet on the blog for a while. The office, on the other hand, has been a hive of activity, as we gear up for a big release Any Time Now. This will include Moviestorm 1.2 and major changes to the marketplace, so it's slightly more complicated than usual.

We also officially changed the company name from Short Fuze Limited to Moviestorm Limited this week, so we're in the process of going through the Web site and everything else with a fine tooth comb and updating everything to reflect the new name.

Normal blogging will be resumed shortly.

Our codebase is bigger than yours

Conor just committed subversion revision number 20,000 to the Moviestorm codebase. That's a lot of code.

Take thirty-seven... action!

Over in the forums, there have been some discussions about performance issues, particularly why things sometimes run slowly with relatively simple sets, no mods, few characters, etc. Julian posted this detailed reply, which we figured was worth reposting in its entirety.

As you may know, it's my job to keep tabs on Moviestorm performance. My tests this week have been on what we call "retakes" - this is the process by which we turn the commands that you give our objects into actual chains of animations, and it is quite a time-consuming process. For example, consider a walk - it consists of many different snippets of animations stitched together in as seamless a fashion as possible. When you move a target point, the walk gets recalculated. In fact during a retake everything is recalculated, and this may seem like overkill; if you only change something near the end, why do you have to process the entire scene? Well the answer is that determining which bits of the scene are (un)affected by which operations can be a more time-consuming process than recalculating the lot anyway! It can also be more error-prone, and more complex (hence bug-prone too). So for now, when we retake (and we retake a lot), we do the entire scene, from time = 0 to the end of the scene.

In order to mitigate the cost of the retake, we've put some effort into making sure we are reducing the amount of recalculation done. This is done "locally" to each activity (rather than globally as above). One of the areas this is harder to optimise is when the activity depends on some resource - which could be eg a texture or a data file lurking on your hard drive. In order to be robust, we have to put checks in to see if these resources have changed - so if you change an animation (directly or indirectly), that change propagates into your scene. Large (ie long) scenes result in lots of resources, and hence Moviestorm spends a lot of time in the retake gathering info about resources. At the moment, for reasons I won't bore you with the details of, this is more costly than we'd like. In essence there are multiple file systems in place, and they all have their costs. We intend to fix the inefficiencies as soon as we can; but they are actually quite insidious because we do a lot of file-related activity and so the changes need to be made in lots of places. But the good news is that we are on the case, and with v1.2 due out soon, we'll have time to take stock of these issues, hopefully to come in a subsequent release asap.