OSX Diff Tools

I’ve been happily using SourceGear’s DiffMerge as a diff tool for years. It’s a great cross-platform tool with an ugly UI. Every now and then I check out the competition to see if there’s anything better, but I haven’t found anything that includes a similar feature set at a comparable price point. It’s hard to beat free.

Today all of that changed. DiffMerge 4 is nagware and costs $39. This isn’t necessarily a bad thing - it’s only fair that SourceGear be compensated for their work - but it means that the app loses its main advantage over the competition and gives me an excuse to shop around for a replacement.

There aren’t that many diff tools available for the Mac. Many of them can be culled immediately from the set of contenders for making basic mistakes.

Mistake #1 is using cross-platform, un-Maclike UIs. Violators are DiffMerge, Meld, P4Merge and KDiff3. Meld is the worst offender as it requires the installation of XQuartz, so I couldn’t even try that one out.

Mistake #2 is not supporting 3-way merges, which makes the tools useless with Mercurial and Git. Apple’s FileMerge is the only tool I looked at that doesn’t support this essential functionality.

Mistake #3 is a lack of new releases. If I’m going to have to invest money and time in a new diff tool I want something that is still under active development. Changes hasn’t seen any significant updates since 2009, despite being taken over by a new company. DiffFork hasn’t been updated since 2011.

Mistake #4 is stupid pricing. Most of the tools are priced at $39 or cheaper. Araxis Merge is three times that price for the cut-down version and six times for the full version.

Mistake #5, which I’m editing in at a later date, is Java. I don’t like Java for reasons far too numerous to go into here. Out goes DeltaWalker

By default, I’m left with just one choice: Kaleidoscope. I’ve mentioned it before and complained that it couldn’t “compete on price, features and speed” with DiffMerge. At $69 it’s more expensive than DiffMerge, but the difference is now between $39 and $69, rather than “free” and “not free”. Kaleidoscope offers a vastly superior UI, and having tried out many of the other options, I realise that it’s actually one of the faster diff tools out there.

It has a number of features that I immediately appreciated:

  • It can jump directly to each change in a file.
  • It shows the list of changed files in a pane of the diff window, rather than a separate window.
  • It shows new files in addition to changed files.
  • Each change is highlighted in a different colour.
  • It has a dark theme.
  • Double-clicking on a folder or file opens it in a new tab.

I’m a little annoyed that I missed out on version 2’s introductory discount price, but I downloaded it from the AppStore anyway.

So long, DiffMerge.


More Stuff I Use

It’s almost exactly a year since I produced a list of stuff I use, so it’s time for an update. This list excludes Windows programs because I now only have only one use for it: an enormously bloated TFS client.

Bean no longer makes the list not because of problems with the program, but because I just don’t need a word processor. The same is true for FileZilla: I don’t need it.

VirtualBox got cut because VMWare Fusion 4’s support for Linux improved to the point where I preferred to use that instead. VMWare feels faster and has a a better-designed UI than VirtualBox. It does a reasonable job of virtualising OSX, which allows me to run my own source control/build server, though I’ve found that running out of virtualised RAM in an OSX guest results in that guest instacrashing. If only TeamCity was written in something more efficient than Java…

I keep trying to find a more Mac-like replacement for DiffMerge but there isn’t one that can compete on price, features and speed. I was hoping that version 2 of Kaleidoscope would do the job, but I don’t like the way it displays changes or its slow scrolling, which is particularly lethargic on a retina Mac. It’s a shame, because the same guys produced the spectacular SVN client Versions.

Every now and again I try out Git to see what all the fuss is about, but I still detest its back-asswards UI and invariably end up happily back with Mercurial.

The fish 2.0 shell is a new entry to the list. Since becoming a full-time OSX developer I’ve discovered that my former distain for the command line was mainly a result of the Windows CLI (both DOS and PowerShell) being desperately awful. Give me a decent shell, be it bash, zsh or fish, and I’ll happily use it. I tried out zsh and oh-my-zsh, which were a vast improvement over bash, but fish wins out solely due to one feature: auto-suggestions.

I’ve now got a second monitor that I use exclusively for displaying an iTerm 2 window split into four separate panes. Vim is in there because sometimes it’s easier to edit in the CLI than it is to fire up Sublime. I’ve added a bunch of configuration options to my .vimrc file, such as line numbers and syntax highlighting, that make it a far better editor than my previous choice, nano. Homebrew is another command line addition that simplifies updating Mercurial, Git, Python and the rest.

Xcode, Safari and Mail should have been on the list last time. All are the default choices for OSX developers. The more I use Xcode the more I find that I prefer it to Visual Studio, which is high praise if, like me, you think that Visual Studio is one of the only worthwhile products that Microsoft has produced. I just wish Apple would invest more time in improving its stability, though recent releases have improved that aspect. Safari isn’t the most popular browser around, but its UI is easily the most Mac-like and syncs bookmarks with my iOS devices. Mail wins out over other email clients by being fast, simple and free, and by working well enough that I’ve never really considered looking for anything else. I was briefly tempted to use Sparrow, but the team got aqui-hired by Google who promptly killed the project.

JSON Accelerator doesn’t do much, but does it well and it’s free. It can call RESTful web services, post JSON data, and receive JSON data in response. It’ll even verify the structure of JSON objects.

SQLite Data Browser is an open-source GUI for working with SQLite databases, which underpin Core Data. It’s simultaneously excellent (free, open source, comprehensive) and terrible (abandoned, Qt UI, unstable). It’s close enough to what I need to dissuade me from paying for a better program.

Texture Packer is a handy tool for producing sprite sheets in the format required by Cocos2d. There are a few of tools that can do this, but Texture Packer is my favourite. The author even hands out free licence keys if you run a blog (disclaimer: I got one of these free keys a couple of years ago).

SoundStudio is a sound waveform editor that reminds me of programs I used on the Amiga. This is a good thing.

Pixen is a pixel art editor that I used extensively when ripping the graphics for EarthShakerDS. The Spectrum emulator I was using could record video to animated GIF files, which Pixen can import into its animation editor. I would use it more frequently, but it is very slow and not very stable. It has a habit of crashing after you’ve made extensive and fiddly changes to a picture and are about to save the changes, which is infuriating. It is, however, the only pixel art editor with animation support that I’ve found on the Mac, which makes the choices Pixen or DPaint 4.5 in an Amiga emulator.

SourceTree is occasionally useful if I’m trying to do something complicated with a Git repository and don’t want to use Git itself.

I settled on CrashPlan as a cloud-based backup system after copious amounts of research. It’s still doing an excellent job.


Super Foul Egg 20120702

Here’s the first release of the newly rebranded Super Foul Egg for OSX:

This version includes the original title music/screen, plus a basic menu for choosing the game mode (practice, easy/medium/hard AI, two player). This build probably requires Lion, but I haven’t got any older OSX installs to test on.

It also includes an improved AI that I wrote months ago but didn’t get around to blogging about. The old AI tried to figure out where best to place an egg pair based on the number of connections that a given placement would make. It tried every column for both horizontal orientations, and each outcome was penalised for increasing the overall height of the playfield. The new AI creates copies of the game grid and runs simulations of all possible moves that it can make. It takes into account sequential chains, chain lengths, garbage egg removals and overall grid height. Once all of the simulations has run it chooses the move that produces the highest score.

The new AI doesn’t consider the pair of next eggs that are due to fall, but as I don’t recall ever beating it on its hardest setting (with the standard 4 egg colours) that isn’t really a concern. The main motivation for rewriting it was to improve its performance with 5 and 6 egg colours (which aren’t exposed in the menu system yet). If I remember correctly, the new version beats the old one most of the time.


Stuff I Use

Inspired by Scott Hanselman’s enormous list of tools that he uses, used, or heard of once, here’s three comparatively tiny lists of tools I use every day. The first list is comprised of cross-platform software that I use on both OSX and Windows. The second is OSX-only software and the third is Windows-only software.

I don’t use Linux enough to have a set of tools I recommend. As I’m the only person on the planet to think that Unity is actually a small step in the right direction, even if it does need optimising, my opinion doesn’t count.


  • Sublime Text 2 - Without a doubt, the best text editor I’ve used on any platform.
  • VLC - The most versatile media playback program around.
  • DiffMerge - 3-way diff tool.
  • Mercurial - Distributed version control.
  • FileZilla - FTP client.
  • Dropbox - File syncing in the cloud.

DiffMerge and FileZilla make the list over other more advanced programs by virtue of being free and cross-platform. Mercurial triumphs over Git thanks to its first-rate Windows support and its spectacular command line UI. I recommend TortoiseHg for Windows as it is often handy to see at a glance if anything in a repository has changed without firing up PowerShell.


  • iTerm2 - Replacement for the standard Terminal.app featuring tabs.
  • Hex Fiend - Because everyone needs a hex editor.
  • PlainCalc - Calculator with a console interface.
  • Adium - Fantastic IM client.
  • KeePassX - Encrypted password storage.
  • Acorn - Simple image editor.
  • VMWare Fusion - OS virtualisation, great for Windows.
  • VirtualBox - OS virtualisation, great for Linux.
  • The Unarchiver - Decompressor for zip, 7zip, etc.
  • Bean - Simple word processor.
  • XBMC - Media player.

VMWare and VirtualBox both make the list because they have different strengths. VirtualBox is open source, free and cross-platform, but it makes no effort to integrate into the host operating system. VMWare Fusion’s full screen mode means I can three-finger-swipe to switch from OSX to Windows, which is almost magical.



Graphics Editing in OSX Lion


I need to edit the top-left pixel of a bitmap in Acorn.

Solution 1

Just edit the pixel, duh. Wait, what’s this? The mouse pointer turns into a resize arrow when I get anywhere near the top-left pixel. In fact, I can’t edit any pixels around the edge of a window thanks to the new window resize behaviour (which I never use and didn’t want).

Solution 2

Make the window full-screen. OK, I’ll fill my 24” monitor with an enormous single picture just so I can edit one pixel. Here we go, let’s edit that pixel! Oh wait, that’s not going to work. The menu bar drops down whenever the mouse pointer is at the top of the screen.

Didn’t Macs used to be the choice for graphics pros?


Really Bad Eggs OSX Demo

Here’s a preview release of the Mac version of Really Bad Eggs:

For those of you without a Mac, here’s a screenshot:

I’ve been debating what to do with the game when it’s finished. I can either:

  • Open-source it on BitBucket;
  • Release it via the Mac App Store;
  • Release it as freeware on this blog.

If I want to release it on the Mac App Store (which would be neat) I’ll need to sign up for the Mac Developer Program. That’ll cost me $99 that there’s little chance of recuperating. There are a couple of Puyo Puyo games on the store already for bargain prices. I haven’t tried them so I’ve no idea if they’re any good, but Really Bad Eggs would probably need to be free to get any downloads at all. I won’t put advertising in the game, so there’s no chance of making any money from it.

I’ll also need to replace the graphics and sounds. I haven’t been able to track down the original developers so can’t get their permission to use their assets. I’m sure they’re great people and would have no objection to me using them, but I’d rather not get the game pulled due to a copyright dispute. Fortunately I know a couple of great artists who have expressed an interest in helping to replace the graphics, so that’s not too much of a hassle.

Releasing it as freeware is much cheaper (it’s free). If I can get the game listed on something like MacUpdate it should get plenty of exposure.

The last option is to open-source it. As a huge fan of open source software I’d love to do this, but I’m loathe to supply a finished game that someone else can release via the App Store themselves.

Anyway, the game in its present state is playable but has no presentation screens. The CPU is set to its hardest level, and restarting a game requires the player to restart the application. It has a few improvements over the DS version:

  • The larger screen let me include the blocks at the bottom of the two grids;
  • The garbage egg landing animation is more effective;
  • Eggs drop off the bottom of the losing grid when a game ends;
  • It includes the original background graphic from the Amiga game rather than the truncated DS version;
  • The incoming garbage indicator is in the original Amiga position at the edge of the screen, rather than on a separate screen where it can’t easily be seen.

Have a play and let me know what you think. Controls are included in the readme.


OSX Lion

After the disaster that was Leopard’s release, I decided to wait before getting Lion.

Then I got Lion anyway.

Quirks so far:

  • Xcode 4.1 downloads from the App Store as an installer, which is totally unexpected. Of course, not knowing this a number of people appear to be running their old copy and then complaining when it’s still, well, their old copy. They don’t realise that there’s an “Install Xcode” binary in their Applications folder.

  • Xcode won’t install unless you quit both iTunes and the iTunes helper app (which you can only achieve via the Terminal or the Activity Monitor in Applications/Utilities).

  • When installed for the first time, Xcode 4.1 wouldn’t work. It complained about the iPhone IDE plugin not loading. Reinstalled it and it worked fine.

  • The inverted scrolling system is vile.

  • It’s very grey. Perhaps the designers spent a bit too long in Aberdeen.

  • Downloaded the ~4GB Lion installer on my iMac. Decided to upgrade my MacBook too. Unfortunately, the installer appears to have been deleted by the upgrade process. Thank goodness I enjoy downloading massive files so much! I get to download the update twice!

It’s pretty obvious that Apple’s main focus is their line of laptops. OK, their main focus is iOS, as that’s where they make their money. They do need the Mac as a development platform, though, and within that set of products, laptops are their main focus. A lot of the new features make no sense on my iMac. For example, the new gestures are quite probably wonderful when used on a MacBook Air with a built-in touchpad. With the iMac, my options are to buy a BlueTooth touchpad (which I won’t do, as my mouse is far more accurate and touchpads are unusable as graphics editing devices) or a Magic Mouse (after trying one in an Apple store, I think it would give me crippling, irrevocable carpel-tunnel within minutes). The gestures are, therefore, useless.

Similarly, the full-screen mode is probably great on an 11” or 13” screen. On a 24” screen, most applications look ridiculous.


SDL Mixer Weirdness

The SDL mixer won’t play samples at 32KHz correctly. It plays them at half speed. My guess is that it can only handle sounds that are 44050Hz, 22025Hz, etc, and anything else it plays at one of those frequencies. I spotted this whilst making the OSX port of Earth Shaker but couldn’t find any reference to it online, so I thought I’d make a note for myself here.


EarthShakerDS and EarthShakerOSX Releases

EarthShakerDS has had about half a dozen releases since the last blog post as I tried to get as much done as possible before the GBATemp Homebrew Bounty deadline. This version has a lot of changes, most of which you won’t notice:

One of the big changes is the inclusion of the “poke” functionality. This allows you to poke an adjacent block using the A, B, X and Y buttons without moving into that block. It’s essential for getting anywhere at all on level 9. Unfortunately, poking has nothing to do with pushing values into RAM via a call to the BASIC POKE function to enable cheats. Authenticity has to stop somewhere.

The other big change is the addition of a level editor. This has been a much bigger job than I’d hoped as I’ve had to write a simple GUI system - stylus-driven buttons, event handlers, etc - to build the interface. Why do that, you ask, when I’ve got a perfectly good GUI system already written? Well, it seems that the M3i Zero at least can’t cope with homebrew ROMs bigger than 3MB. EarthShakerDS includes a few large WAV files that bulk the ROM out significantly. If I include Woopsi I’d make the game unplayable on at least one popular flash cart. When your target audience is people who a) had a Spectrum, b) played EarthShaker on it, c) own a DS, d) own a flash cart, e) are nostalgic enough to want to play EarthShaker still and f) want to play a remake instead of a perfect emulation offered by any of the Spectrum emulators for a DS, you don’t want to exclude members of that tiny audience unless you absolutely have to.

At present the level editor only allows a single level to be edited, saved, reloaded and tested. Supporting multiple levels requires me to create a keyboard and file lister, and haven’t I done all of this before? Gnnk. Level data is saved to “/data/EarthShakerDS”. The folder is created automatically if it doesn’t exist.

I followed the patterns established in Woopsi when coding EarthShakerDS to ensure that it was as portable as possible. This approach allowed me to get an SDL-based build running on OSX very easily:

The OSX build requires OSX 10.6 as I’ve built it with LLVM, Clang, LLDB and Xcode 4, but it should be trivial to get it working on 10.4 simply by switching back to GCC etc. It should also be very simple to get it working under Linux, but as I don’t have a Linux install at present I’m not in a position to make one. There’s one OSX-specific API call used in the LevelIO class to determine the location of the user’s data folder that would need to be altered, but otherwise it’s all platform-independent with a few POSIX I/O calls.

Here’s a screengrab from the OSX build: