Tell (automake) configure to use specific architecture on Mac OSX

Where we want to build 32 bit binary on OSX, and we know the codebase has a mix of C and C++ code.

ARCHFLAGS="-arch i386" CFLAGS="-arch i386" CPPFLAGS="-arch i386" LDFLAGS="-arch i386" ./configure

Xcode: iPhone or iPad application code sign error

This morning on a re-imaged OSX machine I attempted to compile an ipad application and I was rewarded with the error below.

codesign error: code signing identity 'iphone developer' does not match any code-signing certificate in your keychain. once added to the keychain, touch a file or clean the project to continue.

I was puzzled. I'd already made a developer certificate request to Apple, had it signed and installed it in my Keychain Access, I'd also downloaded and installed the Apple Worldwide Developer Relations Certification Authority certificate. I'd installed the required development profile that matched my ipad device Unique Identifier, my personal developer certificate and the application I am developing but still, every time I hit build it gave me a code sign error. I didn't get it.

At some point it a suspicion formed. In my Keychain Access I noticed my certificates where installed in the System keychain. I'm not even sure why they got installed there, I don't think I did it explicitly.

I moved my certificates to the login keychain which I assume belongs to the logged in user on OSX (i.e. myself). Attempting to re-compile the source code of my ipad project yield a positive result. Moving the certificates to the login keychain seemed to work! So I post my small solution here today in the hope that somebody else might benefit.

Oh Magic Mouse! How do I hate thee.

While Apple have, over the years, had many design wins, there have also been some unfortunate design failures. The design failure that happens to torment me on a daily basis is Apple's Magic Mouse. Admittedly this bluetooth mouse is quite responsive and accurate as a pointing device, but it's the mouse's more esoteric features which are pimped as a unique selling point that really irk me. Namely the "multi touch surface", especially when used for scrolling.

The multi touch surface is just far too sensitive and easily triggered when you're just using the mouse to move the pointer. As a coder I spend most of my day in text editors. I'm always accidentally scrolling the text window up and down; even worse - when using the command key and accidentally scrolling, the most common behaviour is to zoom. Not helpful. Give me an old fashioned scroll wheel any day. Likewise in a 3D modelling package I often find myself accidentally zooming.

It's back to the simple $20 mouse for me. On a similar note I have a theory about the efficacy of mice based on price. The sweet spot on mouse functionality is definitely around the $20 mark. Pay more and "features" get in the way. Pay less and accuracy, reliability and that comforting solid hand weight quality possessed by a good mouse are absent.

Schedule Mac OSX Update(s) for Offpeak Download using launchd

In order to schedule you Mac OSX software update to run in Offpeak time you can use the launchd system scheduler in order to to accomplish this. On most Unix systems (including cousins and derivates like Mac OSX) you would use cron. While cron is still available on Mac OSX, Apple have provided an Apple centric way of doing the same the work in the form of launchd.

Launchd has a command line control interface that goes by the name of launchctl, which will be using in conjuction with our xml editing skills to achieve this goal.

The software update tool normally accessible via the Apple Menu (Apple->Software Update to be exact) has a command line parallel "softwareupdate". We can use this command line version to run the update in the background at suitably early hour of the morning.

First of all lets construct a launchd configuration file to setup this job for us. In the common Mac OSX fashion this is achieved via the use of a property list file. Essentially an XML file with the information we want in it. A suitable .plist file for this work is listed below. Save this text into a file name like com.krugerheavyindustries.SoftwareUpdate.plist


<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN""http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.krugerheavyindustries.SoftwareUpdate</string>
    <key>ProgramArguments</key>
    <array>
        <string>/usr/sbin/softwareupdate</string>
        <string>--download</string>
        <string>--all</string>
    </array>
    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>2</integer>
        <key>Minute</key>
        <integer>00</integer>
    </dict>
    <key>StandardErrorPath</key>
    <string>/var/log/software-update.log</string>
    <key>StandardOutPath</key>
    <string>/var/log/software-update.log</string>
</dict>
</plist>


This particular property list configuration file schedules the software update to run at 2 am every morning.

Now because this task is a system related task we need it to be run by the superuser in order to have sufficient privileges for this to happen. As this is the case I'd be storing this configuration file in /Library/LaunchDaemon

Next we load the configuration file in order to schedule it. We can accomplish this with superuser privileges by the doing the following:

sudo launchctrl load /Library/LaunchDaemon/com.krugerheavyindustries.SoftwareUpdate.plist

We can view the task is loaded and ready to roll by issuing:

sudo launchctl list | grep SoftwareUpdate

You should see the task there, if not, you might have a problem.

The task will run every period you specified until you unload it (or reboot - we did not specify it should load itself).

You can unload the task using the command:

sudo launchctl unload /Library/LaunchDaemon/com.krugerheavyindustries.SoftwareUpdate.plist

On a typically configured Mac, it will be setup to go to sleep if left on for a period of time. Obviously this will affect the running of your scheduled task. In order to make sure you schedule task will run I would schedule your machine to wakeup 5 minutes before the scheduled task is due to run. In this case at 1:55 AM. This just gives subsystems like WiFi time to reconnect to the wireless router.

Sleep scheduling for wake up is done via Apple->System Preferences->Energy Saver->Schedule->Start or Wakeup

When you come back to your system in the morning you should find your software updates ready to install. Replacing the keyword "--download" with "--install" in the property list file above you can get your updates to install (not just download) overnight also.

Games Development: A poster child for learning maths at school?

I catch the train to work most mornings. I get so much screen time every day I often like to zone out on the way to work. Driving, avoiding pedestrians and other cars cuts into my zone out time. The train works for me. I don't have to concentrate. I can look out the window, watch people and occasionally eavesdrops on some conversations people are having on the train. Yes, I'm kind of a sticky beak.

The other morning I was largely alone in my section of the train. I was joined at the next stop by half-a-dozen teenage guys in school uniform on their way to school. In fairly typical teenage boy fashion they were talking loud, all pumped in the presence of their mates and talking about people they went to school with.

After several topic changes which I couldn't follow (I don't think I'm across even half of what is 'street' these days) they settled on a conversation about how much maths sucks.

Bigfoot zitty kid : "Maths is so lame. You never use that crap. Like algebra.. what are you going to ever use that for?"

Sporty kid : "Yeah my dad reckons he's never used maths since he learned it, it's stupid - why do they even teach stuff like calculus. When the hell would you ever use that?"

Nods of agreement all around.

I didn't find it particularly surprising. In fact, I'm pretty sure I had a conversation just like that around the age of 15.

What I did find ironic was the next topic of the conversation I was sneaky beaking on. They started talking about video games, and how cool it would be to make them. It struck me as ironic, because right there in front of them was a profession that actually used maths, and potentially quite heavily, to actually do things that are interesting to this demographic. It occurred to me right then - that Games Development is quite possibly the perfect poster child career for demonstrating to kids what value you might actually get from learning maths.

Modern games are using plenty of math. Every interaction on the screen is a cascade of vectors, linear algebra and geometry. You've often got some Newtonian Physics thrown in there for good measure too.

I wanted to interject, but I resisted. I didn't want to blow my cover as the zoned out guy in the corner, I wanted to hear about what games they enjoyed playing.

Chris K.

Eets: Hunger it's Emotional - Released for Macintosh OSX

Somewhat belatedly we're pleased to announce the release of Eets: Hunger it's Emotional for OSX! It was released on Steam last December, and you can check it out here

Whew. That was quite an effort for a small team like ours. It was a labour of love. While it's not the only thing we've worked on this past year, we've certainly taken our time when getting it done.

While it is a port (for us) and the game content had already been completed since the release of the PC version it was still not a jobn for the faint of heart.

Klei Entertainment when originally developing the game had not envisaged that the title would be destined for several other platforms. As such it was written largely in native windows APIs such as DirectX, Direct sound, windows threading and so on. There was little abtraction in the graphics, sound and IO layers.

So we added all of that. We abstracted the graphics layer and put into place an OpenGL driver for the OSX port, we went through a similar process for sound support making use of OpenAL. For threading we just used pthreads for the most part. Perhaps we should have abstracted but we didn't in that case. The shaders were written in DirectX style assembly language and to move them over to OpenGL they were ported into HLSL.

Everytime we finish a title we're reminded of what it takes to actually finish a game.

You feel like your done, when it's feature complete; the graphics and sound are working, the control system is squared away and yet - you're really just half way.
We admit we felt like we'd finished when we reached this feature complete stage; we knew better intellectually but emotionally we fell for it all over again.

At feature complete, you start the gruelling bug fixing stage. It's amazing how many bugs a few good testers can find. We had hundreds, many pretty small but it adds mountains of time to completion. After bug fixing, you then have to package and prep for distribution, this is also suprisingly time consuming. Sorting out distribution platforms quirks, further testing, prepping marking art, liasing with the publishers, partners, testers, reviewers and so on - and we had a lot of help.

Nothing really beats the feeling of finish a title though. At least from our point of view. There is something deeply satisfying about it. I guess that's why we're in this business.

We hope you enjoy Eets for OSX! We certainly enjoyed getting it out there.

Downloading files from the Apple Developer website using wget (for poor connections or scheduling)

Recently we had some issues downloading the latest iphone SDK. Firstly due to a crappy 3G broadband connection; we never seemed to be able to download the entire 3.5 Gigabyte file without a dropout. Unfortunately for us, Apple seem to have overlooked this possibility with their developer website and they do not offer the download using a more robust facility. Note to Apple. Ftp would be nice.

Secondly with several team members located in the same city but not on the same LAN we wanted to distribute the update to all members via our shared linux server. Unfortunately, this said server is getting a little long in the tooth now and being a 32 bit linux distribution it does not support files of the size that is the Xcode and IOS dmg. We were going to have to split the file into more managable chunks. What a pain.

The command line tool wget often yields answers to these kinds of problems so consequently it was our initial foray into finding a solution. Firstly it can provide an extra layer of robustness for downloading files, secondly it's very easy to schedule downloads via cron. For those of you wondering why this is a consideration - welcome to the reality of living in the internet 3rd world - Australia. With the typical internet plans in Australia, heavy internet users such as ourselves find it important to spread our download usage between peak periods (any time you're likely to be awake) and offpeak periods (any time you're likely to be sleeping) to maximise our bandwidth allocation.

Frustratingly, downloading the IOS SDK via wget is complicated by the need for any web client connecting to the Apple Developer website to have been authenticated. The Apple website is known to use cookies to authenticate web clients, and several recipes for extracting authetication credentials from browser cookies into a file and using then via the wget command line interface are well known - at least for Firefox.

The basic procedure for accessing content using wget from a site requiring authentication involves logging into the said site using a standard web browser, once authenticated via a login page one can set abou extracting the authentication cookie from the browser. The extracted cookie is then fed to wget which can use the cookie for permission to download the desired content.

Being on a Macintosh system we are by default provided with Safari. Not bothering to install Firefox on every system one uses, we figured it was easier just to stick with Safari. Luckily the same technique can be performed with Safari as with Firefox. The technique for Safari is not as well known as the Firefox technique, so we'll cover it here.

Safari stores its cookies on a per user basis within a user's home directory. Specifically cookies are stored in a simple XML file. Have a look in Library/Cookies/Cookies.plist. You can see all of Safari's cookies in there.

To get the required cookie into the Cookies.plist before we proceed, use Safari to login to the Apple Developer Website using your Apple ID credentials. Safari should now have the requisite cookie. Opening the Cookies.plist with a text editor to view the cookie; we're looking for the one called ADCDownloadAuth.

With wget expecting it's cookie information in the nescape cookie.txt file format we'd like a quick and simple way to convert from one format to the other. Luckily this is relatively easy to do on a Macintosh system. As the language Ruby is preinstalled on Tiger, Leopard and Snow Leopard systems we may as well leverage the language to do this job.

Install the plist Ruby library and run the short ruby script listing below to convert the file to Firefox's cookies.txt format.

$ sudo gem install plist
$ irb
>> require 'plist'
>> result = Plist::parse_xml("Library/Cookies/Cookies.plist")
>> File.open("cookies.txt", "w") {f result.each {r f.write("#{r["Domain"]}\tTRUE\t#{r["Path"]}\tFALSE\t#{r["Expires"].strftime("%s")}\t#{r["Name"]}\t#{r["Value"]}\n")}}

Now that we have our cookies.txt file we can download the file we would like. Note that the URL for the sdk was found by looking at Apple's Download website to see where the download link led.

Below is the wget command line used to download the Xcode and iPhone SDK. Note that the command line variables for wget tell it to pipe the downloaded file to split which breaks the file up to make our venerable Linux file and webserver happy (2GB file limit). We're splitting the download into 512mb chunks here.

To make sure the authetication works I needed to use the header flag and insert the cookie value at the command line. Looking at the cookie.txt file to again find the ADCDownloadAuth key and it's datavalue we place this data in exchange of the "XXX" marked command line below for this recipe to work.

wget -qO- -U firefox -ct 0 --timeout=60 --waitretry=60 --load-cookies cookies.txt -c http://adcdownload.apple.com/ios/ios_sdk_4.2__final/xcode_3.2.5_and_ios_sdk_4.2_final.dmg --header="Cookie: ADCDownloadAuth=XXX" | split --bytes=512m - xcode_3.2.5_and_ios_sdk_4.2_final.dmg

You should now see your download commence and with everything to plan you'll have your dmg ready to install. You can ftp to you Macintosh. Once aboard you can
cat part1 part2 part3 ... > combined.dmg

In order to restore the split components. Happy Developing with the latest SDK!