About

This is the M Cubed Software weblog. To find out more about us head to our about page.


Search


Feed

 Subscribe (Atom)


Archives

The Return of the Dock Folder

Posted on 29/11/2007 at 01:51 AM in

Any power user, in Tiger had folders in their dock to let them quickly drill down the file system without needing to resort to finder, or even just to open a blank finder window at a certain folder. I had several for all my important folders + my Hard Disk. Then Apple had a brain fart and replaced them with the vastly inferior stacks. Luckily my new personal hero Rainer Brockerhoff (also of RBSplitView fame) has given us poor power users our dock folders back. And for the low, low price of €7 at that. Check it out: http://www.brockerhoff.net/quay/

(0) Comments







12 Years in the Making

Posted on 26/11/2007 at 12:54 AM in

Today is the 2nd birthday of M Cubed Software, at least as a shareware house. In fact the history of M Cubed is a long one that goes all the way back to 1995 when I was just 8 years old. I started off with a small point and click game that I made using two now defunct products, Apple Works (at the time it was still Claris Works) and Apple Media Tool. But to truly understand where M Cubed is now I have to go back a bit further.

Laying the foundations

In 1995 we got our second home Mac, a Performa 5200. Our first home Mac was some variety of LC that I was using when I was just 3 years old in 1990. All I remember of it is watching my dad playing Populous on it (at least I think it was Populous). At some point between then and 1995 it vanished out of the house, but being so young I didn’t care too much. But with the Performa I started to care a lot. One sunny afternoon a delivery truck pulled up outside my house bringing a big white cardboard cube with a large rainbow coloured Apple on the side of it. I spent much of the rest of the day sat looking at the box waiting for my Dad to come home from work.

The computer itself wasn’t that spectacular, 75Mhz PPC processor, 1GB HD, CD drive, TV tuner and System 7.5. It was the bundled software that made it such an important part in my road to being an indie dev. As I have previously mentioned, I used Claris Works quite a bit, especially the drawing parts, but it was two other piece of software, one famous and one less so that changed my life. Every since I first put the Myst disk in the machine and played around I wanted to make my own version. I didn’t have a hope of completing it, but I just loved being able to walk around this virtual world. I wanted to make games of my own. The second application was called ConcertWare. It was a music notation application and I believe the first one on the Mac to take advantage of MIDI. This helped spur my interest in writing music.

So eventually I managed to get hold of a copy Apple Media Tool, I can’t remember how, but I learned how to use it and how to piece stuff together to make a presentation. I combined this with graphics I made in Claris Works and a small story my brother had made up to write my first game: Death Zone (I was 8). If you could click a mouse then you could complete this game, but even so this was quite an accomplishment for an 8 year old. I followed this up with a small game called Conquer which was an incredibly simple game almost like Risk and heavily inspired by the progress screen from Command & Conquer.

Both of these games I released under a made up company: M P Games. Despite how naff the logo actually looks now, I still think that it’s one of the greatest bits of art I’ve done. It was an incredibly smart logo for an 8 year old with absolutely no formal education in art besides the usual finger paint and potato stencil stuff most young children do. I continued working under this name until 2003, eventually releasing a small flash based game of snap I made following a tutorial. Then I had a discussion with a friend during a rather boring maths class one afternoon…

M Cubed Games

I had a conversation with one of my friends that eventually got onto the subject of me making games. My friend was also interested but had no idea how to make them, but he had plenty of ideas, including the name M Cubed. The history behind the name is that he thought up a name Matthew Midgley Multimedia (given that his name was Matthew Midgley). We decided to have it informally stand for Matthew Martin Multimedia and then we started work.

Now it was around this point that I had two more important events happen (important things seem to happen in twos for some reason). First one was I stumbled across a tech site called XvsXP, which tried to compare OS X with Windows XP. On here I met quite a few people, some of whom joined me in creating Deep Thought (which recently celebrated it’s birthday too), one of whom nudged me towards computer science as a degree and one who helped me get started developing with Cocoa. The second big event was that I discovered the Coldstone Game Engine from Ambrosia.

Coldstone helped a lot as it bridged the gap between my little point and click games and full blow applications. It also threw me firmly into the online world, as it was my fellow Coldstone users that eventually got me into using applications such as iChat and IRC. I only ever made one game with Coldstone, which unfortunately no longer works. Panther broke Coldstone and as Ambrosia only published it and the actual developer didn’t feel like updating it has slowly died the death. This game was called Ghosts of Time and was quite a cool game. The basic plot was an evil ghost in the local empty mansion had started infecting your village, so you go to check it out. After fighting through a zombie filled graveyard you get into the mansion, only to have the ghost transport you through time to fight in World War 2 and a futuristic space port. The only real remnants of the game can be found here: http://www.macgamefiles.com/detail.php?item=18149.

iWriter and M Cubed Software

Coldstone also got me in touch with someone who was working for a Mac site called MacTeens. Not long after joining I saw a call on the forums for a Mac developer to port a Windows application to the Mac. So of course having no clue about Mac development I said yes. In fact my exact words were something like, “I’m currently learning PHP at the moment, but when I finish this I’ll be moving on to Cocoa development, so I can help you then”. Several months later I had iStory X 0.1 Over the course of the next year I released updates until I got to iStory 0.7. It was at that point I started talking with Nate, the developer of the Windows version, about essentially re-writing both versions as shareware apps with far more features.

Up until this point the Mac and Windows versions had been largely independent entities. Different version numbers, different UIs. Up until iStory X 0.6 they couldn’t even read each other’s file formats. The shareware version was to be different, it was to give us feature parity between both versions, a single file format that worked with both platforms and it would most importantly make us some money. On the 25th of November 2005 iWriter 1.0 was released under M Cubed Software. 10 years after I first released anything vaguely resembling software I had my first sale.

Of course the next thing on the list was to write an update, version 1.1. But a few months later we were contacted by someone about a potential deal that could change our lives completely. Unfortunately I can’t go into much detail about the deal but it was huge for two people just getting started, so naturally we signed up. So over the next few months we set to work on iWriter 1.1, with input from our new partners and development was going fairly well.

Then it got to February and things took a turn for the worse. Being in my last year of school at the time I had pressures of A levels. I’d just finished my exams in January and had to work towards my final exams in the summer, as well as finishing off coursework. I just didn’t have the time to work on that and on iWriter and now I had “deadlines” for my development whereas before I could work to a timetable that was entirely my own. I started getting burnt out but luckily I was given a new offer. Due to the plans out partners had for iWriter they wanted to buy the rights and source off us. I saw this as a way out and decided to take the money and step away while Nate carried on working for them.

So now I was free to concentrate on my A levels and I was much happier. Just to clarify though that at no point were are partners to blame for what happened, in fact they couldn’t have been better and it was a good experience. The only downside to working with them was that, while I’m open to sharing many things, this application was my baby and they were suggesting a lot of things that, while all very good ideas, didn’t fit in with my initial vision. It was my first ever Cocoa application, or desktop application for that matter, and I’d put over 18 months of work into it and then preparing it for release. I just preferred the freedom of being my own boss, setting my own deadlines and having full control over what goes in my application… wait a minute? I don’t have an application any more!

Starting from scratch

I had money, I had freedom, I had time but I had nothing to sell or developer. I was essentially back to square one again, but luckily I had ideas. The first was of a sort of iTunes “alternative”, that would help you link songs in your iTunes library with various other files on your HD and the second was a backup application that was designed for those who don’t need something complex or comprehensive, but just something that gets your files onto somewhere other than your computer and back again if needs be. As the backup app was planned by Nate and I to be our second application I decided to start with it. Long story short: Leopard was announced, Time Machine blew my mind, I gave up on the backup app. So I was back to square one yet again.

I write quite a lot of songs, some good, most bad, but all in need of organising. Finder is ok for managing files, but sucks for anything more specific. I wanted to store songs, which were actually collections of files. So I started work on an app to manage the music I was writing. Seeing as this was essentially my iTunes “alternative” app but with a better purpose I kept the name: Minim (for those who aren’t musically inclined, a minim is the british/classical name for a half note, or a note that takes 2 beats).

While I was writing this I was referring a lot to my code from my back up app. To refresh my memory of Core Data I decided to write a quick application to store my snippets. Later that day I had an app that stored my snippets and gave me basic searching and syntax colouring. A month later I would give this an icon and release it as Code Collector 1.0b1.

Eventually I finished Minim 1.0 and got round to releasing it, almost 2 months after I’d hoped to have it finished. 3 days after our first birthday I put it online for sale. I followed it with a few bug fixes but then February came round again. Yet again I’d just finished exams and had coursework to work on. Luckily I didn’t have any particular deadlines and so could work on Minim 1.1 in my free time. Unfortunately this lack of activity was meaning that Minim wasn’t generating a huge number of sales, it was being neglected and it’s purpose wasn’t very obvious. If I wanted to make it as an indie dev I needed another application to sell.

The side project becomes the star

Code Collector was released simply because having it sat on my computer felt like a waste, even if it was something any competent Cocoa developer could make in under a day. Even so, it was being downloaded by a lot of people and was outpacing Minim. My indie senses were tingling (that might have been a spider in my wallet), I detected a market! If people are willing to use something so simple and to be frank, crap, then surely they would pay for something that was good. As soon as summer came I started playing around and hacking together what would become Code Collector Pro. It was an amazing project that did much more than I’d ever done before and yet took next to no time to code. Soon enough I had a beta and then a 1.0.

Funnily enough, just as I typed that a sale came in. And that’s what they have been doing ever since release. At release I was getting several sales a day! With Minim and iWriter I was used to maybe one every day after an update for the first week, maybe 1 or 2 a week later on but several sales a day was a new milestone for me and it didn’t stop after the first week, in fact it took a whole month for sales to truly slow down and start getting sluggish.

Now and beyond

So here we are, on the 25th of November 2007. 2 years to the day since I released iWriter 1.0. Earlier this week we released Minim 1.2 and within the next few weeks we’re hoping to get Code Collector Pro 1.1 out. But while M Cubed Software is celebrating it’s 2nd birthday today it’s really taken 12 years to get to this point. 12 years of hard work, of planning, of success and of failure. But most of all it’s been 12 years of having a dream and believing in it. The dream is becoming an indie dev and while I’m not there yet I believe I can be soon. Will it take another 2 years or another 12, I don’t know, but I know that I’ll get there at some point as long as I believing.

(5) Comments







Minim 1.2 now out!

Posted on 21/11/2007 at 05:23 PM in

Minim 1.2 is finally out and ready for your consumption. It features completely re-designed file management, a search bar to improve your searching options plus integration with Wonderwarp Software’s SimpleChord and GarageBand. We’ve also got a screencast up showing the new features, with more screencasts to follow. Download, enjoy and be happy!

(0) Comments







Syntax Colouring Blues… and Reds… and Greens…

Posted on 14/11/2007 at 04:44 AM in

With development on Minim 1.2 winding down recently, I’ve been working on the next update to Code Collector Pro, version 1.1. It went into beta this week and we’re hoping to get it ready for release not long after Minim 1.2. One of the big improvements in 1.1 is with the syntax colouring, which I haven’t been happy with since the release of 1.0. It was slow and not very accurate, with one test snippet of 500 lines taking up to 8.5 seconds to colour in 1.0. Soon after I released version 1.0.1 which fixed a few bugs and almost halved the time to render this large snippet to around 4.5 seconds, but that still was too slow to be acceptable, so I’ve spent the past few days re-writing much of the syntax colouring engine.

Step 1: Figure out what I was smoking

Sometimes I code late into the night. I almost always regret these coding sessions and they result in code that, while it works, works in a not very obvious way. When I coded parts of the syntax colouring engine I must’ve been coding very late because parts of it made no sense looking back at it (even with lots of comments). For example, instead of doing a simple regex to find strings, I was using the regex to find the first item of a string, then using NSScanner to find the end of the string and then colouring that in. I was doing something similar for comments. Before I changed any code I decided to do some work and find out how fast the system was at the moment. I have a small test set of snippets that are a mixture of code snippets of mine and some of a friend. Here are the colour times for the snippets:

Ideal Color0.016
Zend1.366
Askpass0.483
SystemConfig0.152
250 Obj-C0.683
500 Obj-C4.533

Some of these aren’t too bad, but there are 2 that take over 1 second to render. So I set to work re-coding strings and comments, removing a lot of messy code and replacing it with significantly less, and cleaner code and managing to shave 1.5 seconds off the large Obj-C snippet.

In the testing process I also found that a few items in Textmate bundles were for some reason taking up a large amount of the rendering time (almost a second). These included relatively minor bits of syntax, that were often defined in other parts of the bundle. A quick comment out of a small bit of code and I gained another 0.8 seconds off the colouring time of the 500 line snippet. But that still left 2.2 seconds to render the large snippet. A huge improvement but still an eternity.

Step 2: Blame someone else code

At this point I started looking the regex engine I was using, AGRegex. I was pretty sure that there was something slowing down the colouring in the framework as I couldn’t see how my code alone could be responsible for 2.2 seconds. So this was a good time to try out one of the new toys that comes with Leopard, Instruments. A little playing around later and I had a pretty good idea that my assumption was (mostly) right. Most of the processing time seemed to be occurring with some conversions to UTF8 strings within AGRegex.

Looking through the code most of the the conversions were on different strings so I couldn’t change much. Luckily I did find one line that was an issue. The same string was being converted to a UTF8 string twice in one line. Well we can’t have that, can we? A small change and a recompile later and I had managed to shave another 0.7 seconds of the colouring time. I had been right to blame AGRegex, but I still had 1.5 seconds to excuse away. Then something hit me…

Ideal Color0.012 (1.33x faster)
Zend0.384 (3.56x)
Askpass0.175 (2.76x)
SystemConfig0.064 (2.38x)
250 Obj-C0.258 (2.65x)
500 Obj-C1.529 (2.96x)

Step 3: Curse the facts of life

... my hand on my forehead. It had taken this long to realise that the main problem with my code wasn’t as much in it’s efficiency as in it’s scalability. Why did the 250 line snippet take 0.26 seconds when a snippet twice the size took 6 times as long? Because when you are performing several regexes on code, the time it takes doesn’t increase linearly but exponentially. I had finally figured out the core problem with my system, and the fix was easy.

Not long later I had my engine eating in chunks of up to 5000 characters, rather than what was given to it before. Great, now my code can be fast even for large snippets. Let’s test it and compare it to what we had when we started

Ideal Color0.025 (1.56x slower)
Zend0.318 (4.29x faster)
Askpass0.112 (4.31x faster)
SystemConfig0.289 (1.90x slower)
250 Obj-C0.315 (2.16x faster)
500 Obj-C0.547 (8.29x faster)

Ok, that’s not good… Some snippets weren’t as fast as before we broke up our code and some are even slower than when we started messing around. On the plus side we’ve sped up our large snippet by over 8 times. Well it shouldn’t be too hard to fix, should it. Just use the old method for smaller snippets, thereby removing all of the extra processing needed for larger snippets. Let’s try again:

Ideal Color0.012 (1.33x faster)
Zend0.308 (4.44x)
Askpass0.107 (4.51x)
SystemConfig0.059 (2.58x)
250 Obj-C0.284 (2.40x)
500 Obj-C0.524 (8.65x)

And those are the current speeds for Code Collector Pro 1.1b1. Obvious some snippets will see a bigger benefit than others (mostly those that are large with lots of strings and comments). And on top of all this increase in speed comes increased accuracy. And this is just one of the cool things we’ve done for Code Collector Pro 1.1. Keep an eye on this blog over the next few weeks as we reveal more.

(0) Comments







Page 1 of 1 pages