Kruger Heavy Industries, Dev Log (of sorts)

Unity3D iPhone Player and JIRA Connect Integration

2011-12-08T19:57:00.001-08:00

We've been using JIRA internally for our project management and bug tracking for a couple of years now and we've found it to be excellent. Recently Atlassian (the developers of JIRA) released a JIRA Connect library for the iPad/iPhone family.

If you are developing an iPad or iPhone application this library gives you application bug and error reporting, which integrates with JIRA for very little effort.

Using JIRA Connect with Unity3D iPhone together in order to provide a nice way of automatically delivering crash reports and user feedback to your Unity application. For Unity users targeting the iPad/iPhone this quick little boon works for us to. Here is how to do it.

At this point of this post I'm assuming you're familiar somewhat with JIRA and have a working JIRA instance, or are perhaps using the hosted JIRA solution offered by Atlassian (we much prefer to host our own - because we like control like that).

In your JIRA instance; enable the JIRA Connect plugin, the JIRA Connect user and get your API Key from the Administration panel.

Go and download the JIRA Connect source from here.

To get this integration working for Unity iPad/iPhone builds we're going to patch the Unity player source code that gets spat out
by Unity when you make a Unity iPad/iPhone build.

To have a starting position; make a Unity iPad/iPhone build now. Typically, if I have a project directory "ProjectName" I output my iPad/iPhone player build to "ProjectName_build". Generate this now.

Unpack the JIRA Connect source code you have downloaded.

At this point my directory looks like something like (I'm using OSX Lion)


leberkaese: chriskruger$ ls
atlassian-jiraconnect-ios-tip
ProjectName
ProjectName_build
leberkaese: chriskruger$

Open the Xcode project file in your ProjectName_build directory in Xcode. I am using Xcode 4 btw.

We are now going to make some changes to the project that Unity has spat out for us, in order to make use of JIRA Connect. We're basically following the instructions from here.

So the steps as I see them for Xcode 4.

Add the JMCClasses directory to your Unity-iPhone/Classes group. Right click on the Classes group and choose to Add Files to Unity-iPhone. Browse to the atlassian-jiraconnect-ios-tip/JIRAConnect and choose the JMCClasses directory. Select to "make groups for any added folders" and press Add

Select the Unity-iPhone project root in the project explorer, select the Unity-iPhone target and the Summary tab. Scroll down to the Linked Frameworks and Libraries. Add the following libraries for linking, CFNetwork, SystemConfiguration, MobileCoreServices, CoreGraphics, AVFoundation, CoreLocation, libsqlite

Choose the AppController.mm file in the Classes directory. We're going to edit this to integrate JIRA Connect.

Near the top of AppController.mm we'll add the import statement

Now move down further in the AppController.mm file and find the ApplicationDidFinishLaunching method. We're going to add the follow code in order to activate the library code when our application starts. Note that you'll need to alter this code from my example code in order for JIRA Connect to work with your JIRA instance. Specifically you'll need you JIRA instance's web address and it's API key. You might also want to change the configurations options to suit.

When done applicationDidFinishLaunching will look something like this.


- (void) applicationDidFinishLaunching:(UIApplication*)application
{
 printf_console("-> applicationDidFinishLaunching()\n");

    JMCOptions* options = [JMCOptions optionsWithUrl:@"https://project.jira.com/"
                                             project:@"PK"
                                              apiKey:@"XXXXXXX-XXXXX-XXXX-XXX-XXXXXXXXXX"
                                              photos:NO
                                               voice:NO
                                            location:NO
                                       crashreporting:YES
                                        customFields:nil];
    
    [[JMC instance] configureWithOptions:options];
                        
    
 if ([UIDevice currentDevice].generatesDeviceOrientationNotifications == NO)
  [[UIDevice currentDevice] beginGeneratingDeviceOrientationNotifications];

 [self startUnity:application];
}

We were particularly interested in the crash reporting, so for the most part that's all we setup.

So if you've done this. Check it all compiles and your Unity application still runs.

If it all works we're now in a good position to generate some patches that we'll use to automatically update our Unity build from each time we make a build in Unity.

Create another build outputting it to somewhere like ProjectName_build_vanilla.

Create a some patches using diff.


diff  -ru ProjectName_build_vanilla/Unity-iPhone.xcodeproj/project.pbxproj ProjectName_build/Unity-iPhone.xcodeproj/project.pbxproj > xcode.patch

diff -ru ProjectName_build_vanilla/Classes/AppController.mm ProjectName_build/Classes/AppController.mm > AppController.patch

Move these patches to ProjectName/Assets/Editor where they can easily be accessed during the Unity build process.

Now we're going to modify the Unity build post process to apply our patches every time we make a build. So, if it doesn't already exist we will create a file called ProjectName/Assets/Editor/PostprocessBuildPlayer. This file is the standard way Unity permits modifications to the build pipeline.

The contents of our PostprocessBuildPlayer file looks like.



#!/bin/bash

DIR=${0%/*}
INSTALLPATH=${1}
TARGET=${2}
OPT=${3}
COMPANY=${4}
PRODUCT=${5}
LOG=postprocess.txt

echo "Postprocess Start" > ${LOG}
echo "TARGET = ${TARGET}, PRODUCT = ${PRODUCT}" >> ${LOG}
echo "INSTALLPATH = ${INSTALLPATH}" >> ${LOG}

if [ $PRODUCT == "ProductName" ]
then

if [ "${TARGET}" == "iPhone" ]
then
 echo "Applying patches for AppController and Xcode" >> ${LOG}
 (cd ${INSTALLPATH}; patch -N -p1 < ${DIR}/AppController.patch)  
 (cd ${INSTALLPATH}; patch -N -p1 < ${DIR}/xcode.patch)
fi  

fi

It is just a quick and dirty bash script that applies our patches to the Unity iPad/iPhone player build every time we do a build. Once you've got this working you're now got JIRA Connect integrated into your Unity application.

If you have trouble getting the JIRA Connect library working, define "DEBUG" in the build and the JIRA Connect library will log more information (to the Xcode console) about that it is trying to do when the application starts. This will help you work out what is wrong.

Hope this works for you and please do lets us know if this guide needs updating/error correcting.

Unity 3D (Pro): View matrix (separately) for CG shaders

2011-10-20T20:05:00.000-07:00

As Unity's shader support is largely based on Open GL, there isn't, by default design, access to separate model and view matrices in shader code. Occasionally you might want access to this and to use it you'll need to pass this information in yourself.

Just a quick summary of what Unity does provide in Shader code.

UNITY_MATRIX_MVP - Current model * view * project matrix

UNITY_MATRIX_MV - Current mode * view matrix

UNITY_MATRIX_P - Current project matrix

_Object2World - Current model matrix

_World2Object - Inverse of current world matrix

Very occasionally I wish there was a UNITY_MATRIX_M and UNITY_MATRIX_V but there isn't - at least - not yet. (Same limitation in GLSL)

In C# we can get the view matrix from Camera.mainCamera.worldToCameraMatrix and for GameObjects the model matrix can be generated by using Matrix4x4.TRS( transform.position, transform.rotation, transform.localScale).

If we wanted to pass in our own modelView matrix we could do

Matrix4x4 modelViewMatrix = Camera.mainCamera.worldToCameraMatrix * Matrix4x4.TRS( transform.position, transform.rotation, transform.localScale);

Then at the appropriate point we can do

material.SetMatrix("modelView", modelViewMatrix);

To pass this model view matrix into our shader.

In our shader, presumably in the vertex shader we can then use this value like so

v2f vert(appdata_base v) 
     {
         v2f o;
         o.pos = mul( mul(UNITY_MATRIX_P, modelView), v.vertex );
         return o;
     }

The result of the above code is exactly the same as

o.pos = mul( UNITY_MATRIX_MVP, v.vertex );

So now knowing this you can manipulate and/or use the model and view matrices separately in your shaders if you so choose, by first passing them in from script code.

Moving iPhone Developer Credentials from one Mac to another

2011-10-11T17:45:00.000-07:00

Update: So apparently in Xcode 4 (at least) there is an official way to do this... outlined here

I recently reinstalled OSX on my Mac and upgraded to Lion. Of course I forgot to transfer my iPhone developer credentials before I did it. I had to go back to the provisioning portal and setup my new certificate and get a new developer profile. While it wasn't a huge time waste I should have transferred my certificates and profile to save myself some time.

This is what I should have done.

Open Xcode

Window->Organizer

DEVELOPMENT -> Provisioning Profiles

Choose your Provisioning profile, right click and "Reveal in Finder"

Save the resulting file

Open Keychain Access

Export your private and public certificates to files and save them

Transfer all the file to your new system

Drag and drop Provisioning Profile into Xcode's Organiser on your new system

Import the certificates file you exported into Keychain Access on your new system

NOTE: There is a very annoying bug in Keychain Access that means you need to re-import your certificates at the command line. Attempting to you import you certificates using the Keychain Access GUI yields "An error has occurred. Unable to import an item. The contents of this item cannot be retrieved". This is just a blatant bug in Keychain Access you can import the files into Keychain Access at the command line with the following commands.

security import priv_key.p12 -k ~/Library/Keychains/login.keychain
security import pub_key.pem -k ~/Library/Keychains/login.keychain

Xcode 3.2.6 and OSX Lion (10.7) - Make it install

2011-08-04T23:26:00.000-07:00

Today I enthusiastically installed OSX Lion on my development system. I was probably stupidly naive to think it would be a straightforward upgrade.

Attempting to install Xcode 3.2.6, the version I currently prefer, it seemed to silently fail. I wasn't sure why. I did notice running the installation wizard; that at the point of selecting Installation Components the Xcode Tool Set component (Usually compulsory) was greyed out and marked as skip.

After some research, It seems support for Xcode 3.2.6 on Lion is somewhat neglected as Xcode 4.x is the future. Long story short I needed to use 3.2.6. It can be motivated to install on Lion.

After mounting the developer tools dmg you can open a terminal and issue the following commands to successfully install Xcode 3.2.6 on OSX Lion (10.7)

export COMMAND_LINE_INSTALL=1
open "/Volumes/Xcode and iOS SDK/Xcode and iOS SDK.mpkg"

Unity3D Asset Server: Best Practice Workflow - Initial Checkout

2011-08-04T21:25:00.000-07:00

Using Unity in teams one is often stuck using Unity asset server. While it certainly lacks features one has grown accustomed to in many other source control systems the fact remains that it is the solution that most seamlessly works with Unity.

I think part of making the process of working with Unity Asset Server more enjoyable (apart form having experience with it) is to stick with some simple best practices.

Checking out a Unity project for the first time

Find out what the project is called. You can do this looking looking at the server via another project.

When opening Unity - choose to "Create new project". Give it the same name as the project is know by in asset server.

Open this new project and connect to the server (ALT-0 or CMD-0 depending on operating system)

Identify the project you are checking out and connect to it

Choose to Update

You'll be asked to make a decision about conflicting assets. Make sure you discard all existing files in the new project ("Discard My Changes"). This seems a little unintuitive but it makes sure you won't clutter your project or accidentally suck in unwanted files.

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

2011-07-21T23:40:00.001-07:00

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

2011-06-20T23:00:00.000-07:00

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.

2011-06-16T18:25:00.000-07:00

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

2011-06-14T05:35:00.000-07:00

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?

2011-01-27T05:20:00.000-08:00

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

2011-01-27T04:50:00.000-08:00

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)

2010-12-24T05:44:00.001-08:00

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!

Game replay techniques and the importance of floating point determinism

2010-08-31T04:59:00.000-07:00

Working our way towards release we're currently going through a heavy bugfixing phase on the Macintosh version of Eets. One particularly interesting bug was causing incorrect level replays and the official solution video (not really videos but ingame replays) to be incorrect. We had a floating point determinism problem

Level completion replays and solution videos in Eets work by replaying user input. It makes a lot of sense to do this as user input is, relatively speaking, low frequency. To achieve the same results by recording the state of the all the objects in the game would make replay files a *lot* larger. (Consequently - The same technique can be used in writing a network game. Often known as the lockstep technique)

To be able to playback recorded user input into the game engine and have it play out exactly the same, the engine must be completely deterministic. A couple of key components needs to be addressed or things go very wrong.

For starters, the engine's random number generators are in fact not random at all. They need to play out the same random appearing numbers after being seeded each time. Secondly the mathematics of gameplay and engine need to be completely deterministic. This is actually not as easy as it sounds.

Next up, the physics engine needs to be designed from the beginning with determinism in mind. In particular iterative solvers are likely culprits for breaking determinism. Finally, the floating point math in all of it, needs to be deterministic. The floating point math situation is pontially one of the most tricky parts. Calls out to function in the operating system and other libraries - you frequently have not control over and they vary from platform to platform.

Once would think floating point math would always yield the same results, but the results actually vary slightly between processor, operating system, compiler and instruction set. Typically it's rounding method differences that are at play in this diverging scenario. (Did you know? - banking software avoids floats or doubles because of the way they handle rounding).

When floating point math was first catered for in silicon; a number of different ways of doing things made it out into the wild. The bulk of the computing public is using x86 type chips these days. In the early days of x86 floating point math was done in software, and understandably it was pretty slow. At some point the x87 co-processors were introduced. They were physically separate processors, and had their own instruction sets. Now the same instruction set exists today within your average Intel and AMD processor. It still gets used in software today but there are even more possibilities thrown into the mix. First came MMX (the multimedia instruction set), then MMX2, SSE, SSE2, and finally SEE3. Not to mention 3DNow and a similarly targeted instructions set. All of these instructions sets and their corresponding silicon implement floating point math in various ways and to varying degrees.

The Institute of Electrical and Electronic Engineers ratified a standard way of doing floating point math. The standard is known as ieee754. Making sure that your floating point math happens in a standardised way goes a long way to reducing the potential for different results.

Since most games engines update through time iteratively a small error early in the piece can create vastly different results down the track.

Mathematical methods like cos, tan and the other trigonometric functions are also common causes for different results on systems. The reason being that they're so called transcendental functions. That is they generate results by evaluating geometric series. Unfortunately this allows for plenty of scope for error.

Some tips on how to locate and improve floating point math determinism problems.

Use modern ieee754 compliant processor instruction sets SSE and up. Many compilers can be told to automatically use them for floating point math, otherwise you can manually use them via compiler intrinsics or assembly code.

Make sure you know what level of floating point optimisations are being using by the compiler when compiling. For the Microsoft Compilers look for problematic switches like /fp:fast. For gcc look for -mfpmath=sse and -msse and/or -msee2(x86 specific).

Check results from Transcendental functions (tan, sin, cos and their ilk). If they're causing problems what in software versions outside of the system library that you have control over.

Howto to find out what gcc has as implicit defines

2010-08-18T20:07:00.000-07:00

When dealing with portability and preprocessor issues while coding in C it is often very helpful to find out what all the default GCC compiler defined macros are. It's not immediately obvious how to see this. This is how you do it.


gcc -dM -E - < /dev/null

Preview release of KHI 2D technology coming soon

2010-07-21T17:52:00.000-07:00

With the release of Eets for Macintosh coming soon, our attention is slowly moving on to our next project in development.

That as yet to be announced project is built upon a 2D engine that has been developed by ourselves.

While our main goal has been to support the development of our next title, we have tried to build it in a general, clean and reusable way. We've also always hoped to be able to release the engine technology for other people to use and we intend to continue to build and maintain it.

We're currently in the process of cleaning up an initial preview release of this technology. It's been tenatively named Simple Game Engine. It's an OpenGL based, accelerated, multi-platform 2D engine. Our initial goals we're to provide the following features to support the development of our game.

2D primitives

Accelerated via OpenGL

Loading of popular file types including, JPG, PNG, BMP, DDS and TGA

Multi-platform capability

Simple, easy to use API

Abstraction of native platform window and viewport handling

Usable from both C and C++ languages

Design with long term goal to support consoles

We're looking forward to sharing our initial preview release. WY6FHGGZUKB2

Separate debug symbols, just like Windows

2010-07-06T05:10:00.000-07:00

Currently we're working heavily on Linux. You might ask why, but for now you'll have to wait to find out.

Having become more familiar with heavy debugging under Linux we'd like to share with you a little tip about being able to ship binaries in a title that are still useful for debugging problems that are discovered out there in the wild.

This is achievable under Linux by shipping debug binaries that have the debugging symbols separated from the binaries.

Being able to do this under Windows is well known, in fact it's the default. Under Linux it's equally possible by using the less well know gcc debug-link functionality.

This functionality is particularly useful when a distributed application dumps core on a user. One can get the core file, use the separate debugging information and see exactly where the application crashed. All you need to do when you make a build is put aside the separate debug files.

Generally you don't want to distribute the debug symbols, for most people it's just a waste of space, and on the other hand it makes it easier for nefarious types to reverse engineer you code, or otherwise manipulate your software.

This is potentially handy to many others, game developers or otherwise who are working under Linux.

The How

Separating debug symbols from the main binary is achieved with using objcopy which is part of the bintools package found on many Linux systems.

We're particularly interested in the command line arguments --only-keep-debug/--add-gnu-debuglink

What do these command line flags do?

--add-gnu-debuglink adds a .gnu_debuglink section to the binary. In that section is stored the name of debug file to look for.

Below is a short shell transcript of how this is achieved:


$ gcc -g -shared -o libtest.so libtest.c
$ objcopy --only-keep-debug libtest.so libtest.dbg
$ objcopy --add-gnu-debuglink=libtest.dbg libtest.so
$ objdump -s -j .gnu_debuglink libtest.so
 
libtest.so:     file format elf32-i386
 
Contents of section .gnu_debuglink:
 0000 6c696274 6573742e 64656275 67000000  libtest.debug...
 0010 52a7fd0a                             R...

The first part is the name of the file, the second part is a check-sum of debug-info file for later reference.

Build ID

Did you know that binaries also get stamped with a unique id when they are built? The ld --build-id flag stamps in a hash near the end of the link.


$ readelf --wide --sections ./libtest.so  | grep build
  [ 1] .note.gnu.build-id NOTE            000000d4 0000d4 000024 00   A  0   0  4
$ objdump -s -j .note.gnu.build-id libtest.so 
 
libtest.so:     file format elf32-i386
 
Contents of section .note.gnu.build-id:
 00d4 04000000 14000000 03000000 474e5500  ............GNU.
 00e4 a07ab0e4 7cd54f60 0f5cf66b 5799b05c  .z..|.O`.\.kW..\
 00f4 2d43f456                             -C.V

Although the actual file may change (due to prelink or similar) the hash will not be updated and remain constant.

Finding the debug info files

The last piece of the puzzle is how gdb attempts to find the debug-info files when it is run. The main variable influencing this is the command debug-file-directory.

After starting gdb, one can ...


(gdb) show debug-file-directory 
The directory where separate debug symbols are searched for is "/usr/lib/debug".

The first thing gdb does, which you can verify via an strace, is
search for a file called [debug-file-directory]/.build-id/xx/yyyyyy.dbg; where xx is the first two hexadecimal digits of the hash, and yyy the rest of it:


$ objdump -s -j .note.gnu.build-id /bin/ls
 
/bin/ls:     file format elf32-i386
 
Contents of section .note.gnu.build-id:
 8048168 04000000 14000000 03000000 474e5500  ............GNU.
 8048178 c6fd8024 2a11673c 7c6a5af6 2c65b1b5  ...$*.g<|jZ.,e..
 8048188 d7e13fd4                             ..?.            
 
... [running gdb /bin/ls] ...
 
access("/usr/lib/debug/.build-id/c6/fd80242a11673c7c6a5af62c65b1b5d7e13fd4.debug", F_OK) = -1 ENOENT (No such file or directory)

Next it moves onto the debug-link info filename. First it looks for the filename in same directory as the object being debugged. After that it looks for the file in a sub-directory called .debug/ in the same directory.

Finally, it prepends the debug-file-directory to the path of the object being inspected and looks for the debug info there. This is why the /usr/lib/debug directory looks like the root of a file-system; if you're looking for the debug-info of /usr/lib/libfoo.so it will be looked for in /usr/lib/debug/usr/lib/libfoo.so.

Interestingly, the sysroot and solib-search-path don't appear to have anything to do with these lookups. So if you change the sysroot, you also need to change the debug-file-directory to match.

Remember to keep the debug files for every build that gets distributed and you can load up the binary, core file and debug file all together and see exactly what happened.

Find awake IP addresses on a subnet using a batch file

2010-06-23T05:48:00.001-07:00

I seem to frequently find myself trying to find machines by IP address on a subnet. Often I'm on a random Windows machine and I've got nothing but the basic install to do it. What do I do? Good 'o batch script. You can find machines awake on a subnet using a script like this. I might call it find_ip.bat


@echo off
SET t=0
:start
SET /a t=t+1
ping -n 1 -l 1 192.168.0.%t% > nul
if %errorlevel%==0 echo Host 192.168.0.%t% is UP!
IF %t%==254 Exit
Goto start

Just substitute your IP subnet for 192.168.0.x and away you go.

Unity 3D: A rough and ready computation of normals - useful for procedural meshes

2010-04-23T01:35:00.000-07:00

Here is a rough and ready method to compute a meshes' vertex normals knowing the vertices and the indicies of your mesh.


  List[] normalBuffer= new List[NumVerts];
  
  for(int vl = 0; vl < normalBuffer.Length; ++vl) {
     normalBuffer[vl] = new List();
  }
  
  for( int i = 0; i < NumIndices; i += 3 )
  {
    // get the three vertices that make the faces
    Vector3 p1 = m_original[m_mesh.triangles[i+0]];
    Vector3 p2 = m_original[m_mesh.triangles[i+1]];
    Vector3 p3 = m_original[m_mesh.triangles[i+2]];

    Vector3 v1 = p2 - p1;
    Vector3 v2 = p3 - p1;
    Vector3 normal = Vector3.Cross(v1, v2 );

    normal.Normalize();

    // Store the face's normal for each of the vertices that make up the face.
    normalBuffer[m_mesh.triangles[i+0]].Add(normal);
    normalBuffer[m_mesh.triangles[i+1]].Add(normal);
    normalBuffer[m_mesh.triangles[i+2]].Add(normal);
  }

  for( int i = 0; i < NumVerts; ++i )
  {
   for (int j = 0; j < normalBuffer[i].Count; ++j) {
    m_normals[i] += normalBuffer[i][j];
   }
    
   m_normals[i]  /= normalBuffer[i].Count;
  }

Unity 3D Immediate Mode: What's the trick with GL.modelview?

2010-04-14T00:22:00.000-07:00

Unity 3D's immediate mode is really useful for debugging or adding a bit of chrome to a scene. While it's not the most efficient way of getting something on the screen it's so quick and handy. For those not using Unity 3D Pro. The GL namespace and functionality isn't available to you.

Here's a little tip for setting the GL.modelview matrix so you can pump local space vertices into you GL.Vertex calls and have everything appear in the right spot.

For example if I want to draw a line using model local space I need to setup the modelview matrix so GL primitives appear in the place in our 3D world.

First of all we grab the scene camera using for example (using the C# API) :

GameObject camera = GameObject.Find("Main Camera");

Next we need to compose a matrix that will take into account the scene camera's position and the position of the model we're using. The final trick of composing this matrix is to convert from a Left handed co-ordinate system to a right handed co-ordinate system.

Unity 3D normally uses a Left Handed camera co-ordinate system, where Z is postive leading out of the front of the camera. The underlying rendering system (originally designed on the Macintosh andOpenGL) is a Right Handed System (where Z is negative out of the Camera). The GL.modelview is expected to be in Right Handed.

So to composite the correct modelview matrix we're going to first create a matrix to transform from a left handed to right handed system. We could do:


Matrix4x4 mat = Matrix4x4.identity;
mat[2,2] *= -1.0f;

Now we're ready to go, if we have the camera transform, the model tranforms and our conversion matrix. The result looks like this:

GL.modelview = mat * (camera.transform.worldToLocalMatrix  * transform.localToWorldMatrix);

Now you can issue GL.Vertex3 commands in model local space

Schedule Steam (and use your Offpeak bandwidth)

2010-04-05T17:51:00.000-07:00

Antipodeans get a raw deal when it comes to the Internet. It's expensive and slow, not to mention it's become a political hot potatoe with several poorly thought out schemes relating to the internet being pushed through in Canberra.

Politics aside for now, that's not the reason for this post.

With the core market for Valve's Steam service no doubt being the American market little attention was paid to download manager style features such as bandwidth throttling and scheduling. Valve's bandwidth heavy Cornocopia of Software can chew through the average Australian/NZ household's monthly bandwidth allocation in hours.

Most Australian bandwidth plans have a Peak and Offpeak timesplit. Peak obviously falls into all those times you're likely to use the Internet. Unless you're a serious nightowl, at month's end you've probably still got a considerable amount of your Offpeak bandwidth allocation remaining.

Steam doesn't offer built in download scheduling so here is a short recipe on how you can coax Stream to schedule a download for the Offpeak internet hours.

I'm using Windows XP in this example, I can only assume it's similar for Vista and Windows 7.

Firstly on the Login screen of Steam make sure you have the "remember password" option checked. You'll need to do this to allow Steam to automatically login and resume or initiate a download.

Login in to steam initially, and go to the "My Games" tab and right click to "Install game..." on an undownloaded title you'd like to download and install. Steam will present you with details about the install, click next proceed. It will the process the file cache, and then ask you if you wish to create a shortcut to the desktop, which you should check (this is needed for later). The download will begin.

Now that you've compleated the manual steps to setup the download, you can exit Stream. Once it's shutdown we can schedule the download for Offpeak hours.

Go to your Desktop and find the shortcut you chose to create from Steam in the previous step. Right click on the shortcut and choose properties. You'll be presented with the shortcut properties. On this screen there will be a textbox labelled "Target". Highlight all the text in this textbox and copy it to your pasteboard. In this example the text I copied is (It's Half Life 2: Deathmatch):

"c:\Program Files\Steam\steam.exe\" -applaunch 240

Next choose Start->Run from the Main OS Menu, and type "cmd" in into the textbox presented in order to open a command window.

We'll be using the command line command "schtasks" to schedule the Steam download.

In the example below I've scheduled Steam to begin downloading at 2:00 AM in the morning. This is a typical Offpeak time, but you're might be different so you might want to check.

Now we can construct the command line:

schtasks /Create /TR "\"C:\Program Files\Steam\steam.exe\" -applaunch 240" /ST 02:00:00 /SC ONCE /TN Steam

I've used the text I copied from the desktop shortcut as you can see. Pay special notice to the "\" characters I've inserted before the quotes. These are required to be able to input the whole command properly.

The schtasks application should ask you for your user password to properly schedule Steam. If your user account doesn't have a password, you should probably set one. Typically schtasks won't run properly if you don't have a user password on your user account.

You can see the scheduled task(s) by just running "schtasks". It's generally worth trying it first by running it in a minute or two's time to test it's all working properly. Just logout of Steam and reschedule to the appropriate time after you're satisfied.

Derivation of the perspective matrix, Part 2

2010-03-22T23:38:00.000-07:00

In part 2 of Derivation of a Perspective Matrix we look at the actual Matrix part.

In part 1 we leaned how we map points inside our viewing frustum to points on our screen. From here we'd like to see how this becomes a perspective matrix.

To move on I'd like to introduce the concept of the canonical view volume. The canonical view volume is the view volume (the visible area in front of the virtual camera) that is effectively scaled to fit nicely inside a volume where all x and y values are between [-1, 1], and the z values are between [0, 1]. By applying this scaling to points within the camera view volume it becomes trivial to test to see if points lie within the camera view.

The reason we do a mapping from view volume to canonical view volume rather than a straight map to a plane is that we'd ideally like to be able to keep the Z value to be able to test for depth of a point within a scene. We can easily compare a point in canonical view volume space to another point in canonical view volume space to determine if one is potentially part of geometry that obscures other geometry. In modern computer graphics the process happens in the graphics driver, or indeed the graphics hardware, but it does explain the reasoning for the representation.

The canonical view volume for a camera which demonstrates perspective looks like a pyramid with the top chopped off. You can see this shape easily in the original figure depicting the first part of the derivation. The only difference being that the canonical view volume is bounded in dimension in x and y by [-1, 1] and in z direction by [0, 1]. We've scaled all the values to meet this requirement. These space is called clipping space.

At the end of Part1 we derived the formula to map eye space X to screen space X and eye space Y to screen space Y. In clipping space we keep the Z value.

To go on we need to be familiar with the concept of the homogeneous co-ordinates. Homogeneous just means all of the same type/all-together/all the same. All the same of what? You might well ask. Lets start with the basics and refresh out memory about Euclidean space. Euclidean space is the maths we are familiar with when dealing with the basic math of points, vectors and lines. For computer graphics we normally deal with the 2 dimensional Cartesian plane, or the 3D dimensional “real coordinate space”. So Euclidean space co-ordinates are basically the mundane 2D and 3D co-ordinate systems we should all be familiar with by now. In 2D, we generally define the space using linearly independent axis denoted by x and y, and in 3D linearly independent axis x, y and z.

Homogeneous coordinates refer to points in what is know as projective space. The mathematics of projective space is such that points and lines in projective space have corresponding points in Euclidean space. So the two spaces, Euclidean and Projective are connected by a relationship. Thus points in Projective space and Euclidean space can be converted from one to the other easily, and each point in one space has it's equivalent in another space. The word homogeneous in this case is referring to that equivalence.

One particularly nice aspect of working in projective space is that if we are dealing with transformations using matrix mathematics we can create a 4 dimensional matrix that in practice is equivalent to a 3 dimensional euclidean space rotation matrix applied to a point, followed by a translation applied the same point.

The other nicety of projective space for those working in computer graphics is that it's ideally suited to working with projections! Exactly what we're working on deriving here.

Projective space has an additional coordinate. So a 2 dimensional euclidean point is represented by a 3 dimensional projective point and a 3 dimensional euclidean point is 4 dimensions in projective space. As we live in 3D dimensional meat space, the 4 dimensional part is impossible to visualize. It's probably better not to try. Suffice it to say the extra dimension is just providing an additional reference to identifying a point.

There are a infinite projective space points that map to points in paired euclidean space, but the most basic and obvious representation of a point in euclidean space in projective space is the point where the projective (the additional co-ordinate) coordinate is 1. A point (x, y) in 2D Euclid becomes (x, y, 1) in projective space, and a point (x, y, z) becomes the point (x, y, z, 1) in projective space. The projective coordinate is typically represented by the letter w. When w = 1, the Euclid space coordinate is plain to see.

As w is the projective coordinate the general rule for converting from homogeneous coordinates to euclidean coordinates is to use the projective coordinate to divide the other coordinates. (x, y, z, w) in projective space is (x/w, y/w, z/w) in euclidean space. Knowing this it is possible to see that a the projection space points (4, 2, 2, 1) and (8, 4, 4, 2) are the same point (4, 2, 2) in Euclidean space.

Lets put down out equations for a conversion to clipping space from 3D eye space. For x and y they're pretty much the same as formulas for screen space.

We don't really have something for z part yet. We do know that we want to remove the dependence on z for our equations on the right hand side to create linear equations we can place into a matrix, so we'll multiply the equations through by z to leave our simple linear equation on the right hand side. We arrive with

This might not look useful just yet, but bear with me. We've got these two formula mapping into some odd space thats a factor of z. Now we'd like to hang on to z co-ordinate. So we posit a point represented by

So we're trying to find a matrix which maps the point (x, y, z) to to (Xclip*z, Yclip*z, Zclip*z). With (Xclip*z, Yclip*z, Zclip*z), since each term is dependent on z we can divide everything by z and end up with (Xclip, Yclip, Zclip) which is exactly what we want to find. So what we need first the in this matrix which maps between the two spaces. We've got the Xclip*z and Yclip*z component and are currently looking for the Zclip * z component. We know the formula will not be in any way dependent on x or y as the z axis is orthogonal to the plane of projection. Thus the most complicated it will be is a scalar multiplication of z with the possibly of a constant. So we're looking at something like

where p and q are constants.

We have a chance of working out what these constants will be because we know that our camera frustum is bounded by the near plane, and the far plane. We'd also like our screen space Zclip result to be scaled between the 0 and 1. This is a nice way to do it, and it's how 3D API's like OpenGL and DirectX work. So we've got some basic facts to work with.

So we say that Zclip= 0 when z = D (near plane) and that Zclip = 1 when z = F (far plane).

We've got Zclip = 0 when z = D so the right hand side of the equation will be zero. We can solve for q.

So lets do the same thing for when z = F

We know what q is from the earlier step

Now we have a value for constant p and q that actually mean something, returning to our original equation and substituting yields

So we're left the equations

Now if we move this calculation into projective space using homogeneous coordinates we can say we're writing a transform to . Normally we're write Ws = 1 for the most simple equivalence in projective space. Ok so if Ws equals 1 then we can see that

Now we've got four equations we can put into a matrix yielding.

So this matrix maps from euclidean point represented as a homogeneous coordinate (x, y, z, 1) to yield (XclipZ, YclipZ, ZclipZ, Z) as homogeneous coordinate, dividing through by z to create a euclidean coordinate yields (Xclip, Yclip, Zclip, 1). Our desired screen space coordinate.

This current set of equations assumes a completely square view screen. If we take into account different possible aspect ratios we add the term for the aspect ratio. The aspect ratio defined as the view port width versus the hight. That is the width of the near plane (which we assume is our projection screen), versus the height of the near plane.

We introduce this term into the equation for the Xs coordinate, and follow through to yield the matrix

And here we have one common form of the projection matrix.

Your own Custom Carbon Application Event Loop

2010-02-10T18:32:00.000-08:00

When one develops a Carbon API application, you normally just setup all your application callbacks and logic in your code before you hit the RunApplicationEventLoop call that doesn't return until you Quit.

Certainly you can run different bits of code based on events and so on, and that works just fine for most cases.

There are certain cases where this may not work for you and you want finer grained controls of when different bits and pieces of your code runs. You may wish you could get into the RunApplicationEventLoop and do things how you would like. If this sounds like you, then there is a way to do this.

I needed this when porting a title to OSX, in order to give the same behaviour as the Windows build. Rather that work out how I could get it all to happen syncing between updates and renders I just implemented my own loop which gave me quick access to easy predictable control.

Apple haven't told us exactly what happens in RunApplicationEventLoop but there is a way write your own loop that certainly has worked for folks so far. See the code below.



static EventHandlerUPP gQuitEventHandlerUPP;   // -> QuitEventHandler

static OSStatus QuitEventHandler(EventHandlerCallRef inHandlerCallRef,
         EventRef inEvent, void *inUserData)
{
 OSStatus err;

 err = CallNextEventHandler(inHandlerCallRef, inEvent);
 if (err == noErr) {
  *((Boolean *) inUserData) = true;
 }

 return err;
}

static OSStatus EventLoopEventHandler(EventHandlerCallRef inHandlerCallRef,
           EventRef inEvent, void* inUserData)
{
 OSStatus        err;
 OSStatus        junk;
 EventHandlerRef installedHandler;
 EventTargetRef  theTarget;
 EventRef        theEvent;
 Boolean         quitNow;
 static const EventTypeSpec eventSpec = {kEventClassApplication, kEventAppQuit};

 quitNow = false;

 // Install our override on the kEventClassApplication, kEventAppQuit event.
 err = InstallEventHandler(GetApplicationEventTarget(), gQuitEventHandlerUPP,
        1, &eventSpec, &quitNow, &installedHandler);
 if (err == noErr) {

  // Run our event loop until quitNow is set.
  theTarget = GetEventDispatcherTarget();
  do {
   err = ReceiveNextEvent(0, NULL, kEventDurationNoWait,
          true, &theEvent);
   if (err == noErr) {
    SendEventToEventTarget(theEvent, theTarget);
    ReleaseEvent(theEvent);
   }

   /// Run application code
   RunOurApplicationCodeHere();

  } while ( ! quitNow );

  junk = RemoveEventHandler(installedHandler);
 }

 return err;
}


static void RunCustomApplicationEventLoop()
{
 static const EventTypeSpec eventSpec = {'KWIN', 'KWIN' };
 OSStatus        err;
 OSStatus        junk;
 EventTargetRef  appTarget;
 EventHandlerRef installedHandler;
 EventRef        dummyEvent;

 dummyEvent = nil;

 err = noErr;
 if (gEventLoopEventHandlerUPP == nil) {
  gEventLoopEventHandlerUPP = NewEventHandlerUPP(EventLoopEventHandler);
 }
 if (gQuitEventHandlerUPP == nil) {
  gQuitEventHandlerUPP = NewEventHandlerUPP(QuitEventHandler);
 }
 if (gEventLoopEventHandlerUPP == nil || gQuitEventHandlerUPP == nil) {
  err = memFullErr;
 }

 if (err == noErr) {
  err = InstallEventHandler(GetApplicationEventTarget(), gEventLoopEventHandlerUPP,
         1, &eventSpec, nil, &installedHandler);
  if (err == noErr) {
   err = MacCreateEvent(nil, 'KWIN', 'KWIN', GetCurrentEventTime(),
         kEventAttributeNone, &dummyEvent);
   if (err == noErr) {
    err = PostEventToQueue(GetMainEventQueue(), dummyEvent,
           kEventPriorityHigh);
   }
   if (err == noErr) {
    RunApplicationEventLoop();
   }

   junk = RemoveEventHandler(installedHandler);
  }
 }

 if (dummyEvent != nil) {
  ReleaseEvent(dummyEvent);
 }
}

What this code does is that it creates a custom event loop that gets entered by the normal RunApplicationEventLoop when the event for it gets fired (very early on). The custom loop runs the normal events pump as expected. A custom quit event handler is inserted to toggle the finalisation of the custom event loop. Simple!

Convert a Windows ico file to a Macintosh icns file

2010-01-23T21:07:00.000-08:00

I needed to convert a Windows platform standard ico format icon file to a Macintosh icns format icon file and didn't find any quick relevant details via Google.

Well, here is a little quick recipe for doing so without having to use any additional software, only what is already on your Macintosh. At least this worked just fine on my Leopard machine so it should at least be able to be done on Leopard and Snow Leopard.

From the command line do the following, substituting in your relevant information.


pookie:tmp admin$ sips -s format tiff icon.ico --out icon.tiff
pookie:tmp admin$ tiff2icns -noLarge icon.tiff icon.icns

Bresenham's circle, Open GL and blowing holes in textures

2010-01-15T19:56:00.000-08:00

Bresenham's circle algorithm is actually a variation on Bresenham's line drawing algorithm and as such it gets it's name, even though Bresenham didn't really invent the circle part.

Playing with destructable terrain I wanted to be able to blow circular holes in a texture. I succeeded by fetching a texture with Open GL and twiddling the bytes with the circle algorithm to do so.

The code below is in the spirit of what I did. Below is the main meat method on the algorthim, you might call it DrawFilledCircle() or some such.


..

/*

Input Parameters: 

Vector2 pos;     // The position of the explosion/circle center in texture pixel space.  
float       radius; // The radius of the explosion/circle in pixels 
unsigned char* buf; // The pixel array - pixels are in RGBA format
Texture*  texure; // a texture or texture info pointer
Colour      colour; // the colour RGBA that you want the circle to be
*/

int width = texture->GetWidth();
int height = texture->GetHeight();
 
int left = int(pos.x - radius);
int right = int(pos.x + radius);
int top = int(pos.y + radius);
int bottom = int(pos.y - radius);

// check to see the circle will even touch the texture  
if (!((left < width && right > 0) && (bottom < height && top > 0))) 
{
 return;
}

int max_x = std::min(right, width);
int max_y = std::min(top, height);
 
int r = (int)radius;
int x = 0;
int y = r;
 
float p = 1 - r;
 
while (x < y) 
{
 if (p < 0)
 {
         x += 1;
  p = p + 2 * x + 1;
 }
 else
 {
  x += 1;
  y -= 1;
  p = p + 2 * (x - y) + 1;
 }
 CircleLineFill(buf, width, -x + pos.x, y + pos.y, x*2, colour, max_x, max_y);
 CircleLineFill(buf, width, -x + pos.x, -y + pos.y, x*2, colour, max_x, max_y);
 CircleLineFill(buf, width, -y + pos.x, x + pos.y, y*2, colour, max_x, max_y);
 CircleLineFill(buf, width, -y + pos.x, -x + pos.y, y*2, colour, max_x, max_y);
}

The next method is CircleLineFill. This is a slight variation of the normal algorithm that draws just the outline of a circle, it doesn't fill the circle. This method fills the entire circle, leaving the edges of the intersection with a black edge.



void CircleLineFill((unsigned char* buf, int width, int x, int y, int length, Colour col, int max_x, int max_y))
{
 if ((y < 0 || y >= max_y) ||
  (x + length < 0) ||
  (x >= max_x ))
  return;
 
 int right = std::min(x + length - 1, max_x);
 int left = std::max(0, x + 1);
 
 Colour* pixel = NULL;
 if (x >= 0)
 {
  pixel = (Colour*)((char*)buf + (y * width * sizeof(Colour) + sizeof(Colour)*x));
  if (pixel->a != 0)
  {
   *pixel = Colour(0, 0, 0, 255);
  }
 }
 int dwords = right - left;
 if (dwords > 0)
 {
  pixel = (Colour*)((char*)buf + (y * width * sizeof(Colour) + sizeof(Colour)*(left)));
  memset(pixel, col.c, (dwords*sizeof(Colour)));
 }
 if (right > 0 && right < max_x)
 {
  pixel = (Colour*)((char*)buf + (y * width *  sizeof(Colour) + sizeof(Colour)*(right)));
  if (pixel->a != 0) 
  {
   *pixel = Colour(0, 0, 0, 255);
  }
 }
}

Byte Array to String in C# - Unity Debugging

2010-01-12T21:34:00.000-08:00

While using C# and Unity, I found myself reading data straight from the network during (BinaryReader) a debugging session.

I was trying to work out why data was sent correctly from the server, but was being interpreted so different on the Unity client. I could easily see what bytes (in hex format) were generated by the python server(with the very useful command line debugging ability), but on Unity I needed to think for a second to determine how to display bytes nicely in a hex format for my serialized object.

The easiest way turned out to be as below.


// example byte array read from a binary stream
BinaryReader stream = new BinaryReader(buffer);
byte[] byteArray = stream.ReadBytes(3);

// import UnityEngine for Debug.Log
Debug.Log(BitConverter.ToString(byteArray));

The output looks like as follows


01-AB-CD
UnityEngine.Debug:Log(Object)
...

Compute Length of a String in Unity 3D

2009-12-06T20:31:00.000-08:00

How to compute the length or size of a string in pixels wasn't immediately obvious to me in Unity 3D, which is why I thought I was quickly post how it can be done. Knowing the size of the string is often useful if you are developing your own complex controls of interfaces. It's also often commonly used for centering a string within a space.

In order to compute the size of a rendered string, you will need your string and the GUI style with which you intend to render your string, and then finally a GUI content convenience object in order to pass the string into the CalcSize method of the GUIStyle object. See below for UnityScript pseudocode.


/* declare the style and setup parameters with Unity 3D inspector */
var guiStyle : GUIStyle; 

...

/* here is my string */
var myString : String = "this is my string";

/* create a content convenience object with which to pass the string */
var myContent : GUIContent = new GUIContent();
myContent.text = myString;

/* CalcSize will return the dimensions (width and height) of the rendered string in pixels */ 
var stringSize : Vector2 = guiStyle.CalcSize(myContent);

You can then get the x and y components on the returned Vector2 for the size of the string in pixels, width and height. Remember, the font size, font type, spacing and all the rest of the GUIStyle parameters you configured in the Unity 3D inspector will alter the final pixel size values of the string.

Derivation of the Perspective Matrix, Part 1

2009-12-04T17:56:00.000-08:00

Preface

I have been wanting for some time to discuss in detail the Perspective Matrix. Not only do I find it an interesting topic but I have found numerous times during my career that it has helped to understand the Perspective Matrix and the math behind how it came into being. I'm not going to assume too much knowledge of the subject in this article so I'll start with the basics. Skip a bit if it's of no interest to you but I do hope that others will find this particular granularity of breakdown useful. I know it's been years since I've formally looked into the math behind this and I certainly befitted greatly from trying to explain how the perspective matrix works to others.

While this piece is intended to be read all together I decided to break it up into several easy to digest parts more suitable to appearing on a development log. It's entirely possible I've made mistakes or omissions and I invite readers to point them out. I, like everybody, is learning all the time.

Part 1

Since the gaming world went 3D the perspective matrix has come into it's element. Its the math which takes our 3D game world and displays it on our 2D televisions, monitors and screens. There are two common types of 3D projection, orthographic and perspective. Orthographic projection has it's place but for the most part it's perspective projection that does the heavy lifting in game titles.

Artists have been aware of the phenomena of perspective for thousands of years. In particular with regards to the apparent relative size differences of objects depending on their distance from the viewer. A good artist depicts perspective intuitively and artistically.

Over time mathematicians and natural scientists developed theories about perspective. The mathematics we use today seem to do a very good job of simulating perspective as we see it in the real world. Using linear algebra and the associated matrix math we can handily simulate a camera in our virtual 3D worlds.

While we are in the moment less interested in orthographic projection it does serve to understand a little about it and it's differences to perspective projection. An orthographic projection will map a 3D point on to a 2D surface by modeling how the light travels from a 3D point to the 2D surface. The ray of light will intersect the projection surface orthogonally to that surface, in other words with a right angle – a perfect 90 degrees to the 2D surface. You could think of this as a lot like shadows projected on to a wall (an ray of anti-light if you like); as if you were playing with shadow puppets. The 2D surface will need to be at least as big as the 3D object in order to receive the projected rays at 90 degrees (in the natural world – in mathematics we are able to scale things).

A camera, or an eye for that matter, is different, and a perspective projection will more accurately apply in this case. To understand why, one has to imagine what the light might be doing in order to reach the lens of the eye or camera. The viewing eye is quite small, so light that is viewed will be the light rays that will travel from the 3D point to the point where the eye is located. There is no condition on the light having to strike the 2D viewing surface orthogonally. In effect light will arrive at different angles on the 2D plane depending on its source distance and orientation. This is where the visual effect of perspective comes into existence. This is obviously simplified as an eye and a camera have a lens which changes the way the light travels, but we can ignore that for now.

In your typical game, world co-ordinates are 3D co-ordinates relative to an arbitrary world origin. Camera or eye co-ordinates are 3D co-ordinates which are relative to an origin that is specified as being the position of the eye or camera.

If we setup a little thought experiment and layout a diagram on paper or computer we can start to see where the mathematics will come from. Let us assume the geometry we're dealing with (points, lines and so on) has already been transformed from world co-ordinates to eye co-ordinates and that the projection plane is the same as the front clipping plane. It's not really relevant to this discussion so we'll ignore how that happens for now.

If you reference the figure below you will be able to see how we imagine this model of our camera to be. A Right Handed Co-ordinate system is in place. We are using a viewing frustum aligned with the Z axis (the Z axis is relative to the eye so we subscript it with the lowercase e), with a near/front clipping plane at Ze = D, and far clipping plane at Ze = F, and the view angle we have represented by the half height of the frustum h. Note that the half height can also be represented by the viewing angle divided by 2. In this diagram we label the viewing angle with the lowercase Greek letter theta.

Let us start by working through the transformation of a point in 3D space to a point in 2D space. For simplicity sake the 2D space we're talking about is our near clipping plane. If you like, what we project on here gets displayed onto our screen as a 2D image.

As stated earlier we have agreed our 2D plane on which we are projecting is located at the near clip plane. If we want to be able to position points on this plane we need to give it a co-ordinate system of it's own. By convention this is known as screen space. Screen space being 2D will only have 2D co-ordinates, for simplicity we make the origin the center of the screen. In the figure above we can imagine it being the point at which the eye Z axis intersects our viewing plane.

Using the mathematics of projection we can establish a projected 3D points position on the 2D plane by using the formula
To understand this equation lets look at a more simple equation. The equation is Xss = Xe * D / Ze. It looks very much like the original formula above. What we see here is simply an application of the principle of similar triangles. If the angles of one triangle are equal to the angles of another triangle, then the triangles are said to be equiangular. These equiangular triangles have the same shape but may have different sizes. So equiangular triangles are also known as similar triangles. This principle is relevant here, if you look at the figure. This principle states that the ratio of the length of the sides of two triangle remains the same for similar triangles.

This principle then allows us to see where Xss = Xe * D / Ze comes from. The two triangles we propose are similar are the triangle formed by the eye, a point on Xe and a point on Ze. The second triangle is the one formed by the eye, a point on Xs and the point D along the Ze axis. We can see they are similar triangles so thus the length ratio between the sides from the eye to D and Eye to Ze will be the same ratio between eye to Xe and screen origin to Xs. Knowing this ratio we simply multiply the ratio by the length of the side we do know about on the other triangle, yielding the length of the side we're interested in which happens to be Xss.

So now we understand where we get the first part of the projection, the part for the X axis at least. The same principle works exactly the same along the Y axis.

That part was straightforwards enough, but we know that we're still missing the h term from our simplified formula. Now lets look at where the half height of the screen comes in to the equation. The half height of the screen is another way of expressing the field of view of the camera. The field of view of the camera we signify in this example as the angle theta. It is easy to see that if we increase the value of h the screen area we have for projecting on to is much larger. Dividing Xe * D / Ze by h will yield Xs as a value in screen space.

Using basic trigonometry we can see that

So substituting this back into our equation we get

which becomes

and this for our Y axis component

So here have arrived at two simple equations for projection of a point on to the 2D plane we've decided is our screen. We can use our equations from this position in our journey to do more, which I'll cover in part 2.

An stlport tip, for solving linker errors (stlpmtx_std vs stlp_std)

2009-11-10T17:00:00.000-08:00

We've been making heavy use of stlport for our projects. Stlport is a great, freely available library that one can use on plaforms without a mature C++ stl library. A number of our team experienced problems when building an stlport application; specifically linker errors.

A common cause of link errors while making use of STLPort is variations in the compile flags between the stlport library itself (if it needed to be compiled - often it's headers only, depending on how you use it) and the applicaton.

With the output errors, check the namespace of the missing methods, it might tell you something about what's happening. The specific problem occuring for members of our team was yielding errors with a signature of form:


stlpmtx_std::methodname

Eventually we realized the application was compiled with stlport in a non thread safe form (i.e. _NOTHREADS defined), but my the systems' dynamic libraries (of stlport) were compiled as thread safe (generating the corresponding link table name prefix signature - stlp_std::methodname).

Hopefully this will help somebody who might be confused or stumped with the same issue.

Use a Xbox 360 Controller with Cortex Command on the Macintosh

2009-11-03T09:51:00.000-08:00

As you may know Kruger Heavy Industries brought Cortex Command to the Macintosh. It was a work of love, and continues to be as Cortex Command works it's way up to being content complete (and finally finished). We work on a build now and then and when Data Realms is finally satisfied the game is complete we'll have many more avenues available to us to promote and distribute the game. Many magazines and stores understandably won't stock or promote unfinished products.

In the mean time I wanted to mention one cool thing about the Macintosh version of Cortex Command that I don't think many people are aware of. It's possible to use a Xbox 360 controller with Cortex Command, and the experience is greatly benefited for it.

Cortex Command was from the outset designed with consoles in mind. From the circular menu systems allowing for easy option selection with a D-pad or joystick, to the targeting system that remains easy to work with a joystick it was always a design consideration. Data Realms hopes to bring this title to a console one day. As do we.

So for Cortex Commanders why not play the game as it was intended - with a console controller.

Microsoft have had available for the purchase the "Xbox 360 Controller for Windows" for some time now. It's basically identical to your typical wired Xbox 360 controller but comes with the Windows driver CD. If you don't have an Xbox 360, this is probably the easiest way to get a hold of a controller.

For a wired Xbox 360 Controller, it's just USB. Plug it into your Macintosh and it's ready to use.

For those with Xbox 360 Wireless controllers you can get a PC receiver for you Xbox 360 wireless controller. There is a brief description here. It just plugs into your USB port and they're relatively available. Note however, that it's probably cheaper just to buy a wired controller for windows. Depends on how much you value your wirelessness (I think I made that word up).

So once you have yourself a controller we can use it on the Macintosh thanks to Tattie Bogle who wrote the driver for Macinosh OSX. You can find out about it and fetch it from here. I believe it now supports both the Wired controller and the Wireless Controller.

Install the Xbox 360 controller driver and then you can insert you controller into the USB port of your Macintosh. If you go to the controller options via the Apple menu you can open up the controller calibration settings.

Once you've got all that installed and configured you can fire up Cortex Command, choose the Options submenu from the Main menu and you'll see the options menus as show below.

From here use the left and right arrow buttons to select the Gamepad as the control scheme you'd like to use for your player and choose "configure". You'll then be presented with a screen to allow you to select the kind of controller you'd like configure.

Choose the Dual Analog controller as this is what matches the Xbox 360 controller type. Once you've done that you can assign the different actions to the controller joysticks, buttons, triggers and menu buttons, as show below.

From there you can go back to the Main menu and fire up the game and play it with you controller. It's undoubtedly the best way! Enjoy!

OSX: Carbon Event Loop not firing - Application unresponsive

2009-10-22T20:17:00.000-07:00

In the development of Eets I've been using Apple's Carbon API. As some of my peers have correctly pointed out Carbon is slowly being deprecated, at least publically (outside of Apple). I'm pretty sure I've read somewhere that the Carbon API is still being heavy used to support the features underneath (for example in the Cocoa API). So this will likely be the last time I get to use it on any serious. I've already noticed that Googling for Carbon problems doesn't return a boatload of results. So I figure it's a pretty naive way of telling that Carbon it's really where the action is these days.

I'm a little saddened by this. I think it's a well designed and useful API and I've found it quite enjoyable to use but it's clear that slowly C and C++ fall out of favour (yes, yes not without good reasons - I guess I'm just getting old and nostalgic).

In case of the possibility there are some others out there still plugging away with Carbon or at least having a bit of a play, this post is for you!

I had a particularly annoying problem the other night, and it stumped me for longer tham I'd like to admit. It was only some old crusty websites and a mailing list archive that gave me any clues as to what the problem might be. So for the sake of "paying it forward" I just thought I'd mention this problem I had and hope it might help somebody just like me. It was a very unintuitive problem. Most likely because I don't completely understand the way Carbon works with it's disk based resources.

Eets, the title I'm working on, is basically a C++ and Carbon application. I am using CMake to generate the Xcode files. When the products are build, the .app directory and files are cobbled together mostly by hand (or by a script I wrote). I'd used interface builder to setup the basic window and toolbar settings. Somewhere along the line I'd obviously changed something outside of interface builder in the interface nib files.

In my C++ code I've setup the basic Event loops, Events and Event Handlers. My problem began after adding some features and a compile. The main window would open but the whole application would just freeze. The menu wouldn't appear and the application window wouldn't respond to mouse clicks or drags. The window would just sit there and lose focus to any other window in it's way.

I noticed this specifically happened once the code had started up and entered the RunApplicationEventLoop.

I kept thinking I'd setup the Event loop incorrectly or there was a bug in my code. I spent ages trying to work out what I could have done wrong. When I paused the application in the debugger the callstack looked like the one below.


#0 0x900074c8 in mach_msg_trap ()
#1 0x90007018 in mach_msg ()
#2 0x90191708 in __CFRunLoopRun ()
#3 0x90195e94 in CFRunLoopRunSpecific ()
#4 0x927d5f88 in GetWindowList ()
#5 0x927dc6f0 in GetMainEventQueue ()
#6 0x927fe1c8 in GetApplicationTextEncoding ()
#7 0x927fb698 in RunApplicationEventLoop ()
#8 0x0000a264 in main (argc=2141449080, argv=0x38810040)

I eventually worked out what the problem was. It turns out that
RunApplicationEventLoop was freezing, and it was basically not handling events properly. This occurs when the CFBundleExecutable value in Info.plist file of the application bundle doesn't match the application name (set by "PRODUCT_NAME" in the build preferences of Xcode). Deep down within Carbon this apparently stops events from working.

Annoyingly Eets, at the time, wasn't even being built as a bundle so I had to change that. It was time consuming and fiddly to do so - as CMake doesn't really have great support for Xcode application bundles, frameworks etc. It's getting there ... slowly.

After I changed CMake to create an application bundle and setup the Info.plist and .app directory structure, Eets is again working. I didn't change any of the C++ code to fix it. I just setup the .app as apparently required. Well I did learn something, even thought it wasted some time.

I hope this is of use to some Carbon API users out there.

Eets: Hunger. It's Emotional coming to Mac OSX

2009-10-13T01:49:00.000-07:00

We hinted at the coming of Eets in an earlier development log post. Now we can tell you that Eets. Hunger. It's Emotional is on it's way to the Macintosh. We love this quirkly little platform puzzler and we hope that Macintosh owners will too.

Eets was originally developed by Klei Entertainment for the PC. Later in 2007, Klei developed Eets. Chowdown for the Xbox 360 LIVE Arcade which was well received. Klei have now moved on to some new and exciting titles but it was their wish to see Eets come to the Macintosh. That's where we stepped in. We're now very excited to be part of bringing Eets to a new (and our adored) plaform.

Eets has been described as a homage to some classic games of the past the likes of Lemmings and The Incredible Machine. With it's bright colours and eccentric cast of creatures you quickly find yourself endeared by this title. Players must navigate Eets to the end goal, a "puzzle piece", of each level by using a mix of beasties and contraptions with their own unique abilities and properties. Prankster Whales, Marshomechs, Chocolate Cannons and Radioactive Gingseng all play a part in solving the puzzles preventing Eets from getting where he's going. Food is greatly important to Eets and it directly affects his mood, thereby changing the way Eets will navigate his way through the level. We all agree, Eets is a very hungry animal - although it's not clear what kind of animal he is. At first sight it's not unreasonable to think of him as a dog, but I've seen him described as a tadpole with legs and teeth.

Adding an extra dimension to the title is the inbuilt level builder allowing for user generated content. It adds hours of entertainment to Eets, when you've had your fill of playing through the levels shipped with the game.

Bringing it to the Macintosh has been quite a challenge. It was engineered originally with little expectation of it ever coming to the Macintosh platform. Written directly on top of the Windows API and DirectX we've had to recode large parts of it to run it on the Macintosh; including a total rewrite of the graphics code to make use of Open GL. It's coming along nicely with the game almost playable (see very early development screenshot below).

The big things left remaining to address on the Macintosh version of Eets are sound and some control issues. We're pretty confident the majority of the really heavy lifting has been done and progress from this point on will be straight forward (touch wood).

We'll keep you posted on progress as we get closer to releasing this fantastic title for the Macintosh.

Unity3D: Useful Tricks with Delegates

2009-10-04T06:26:00.000-07:00

It's probably fair to say that Unity developers are quite a broad community skills wise. There is mix of first time game developers, seasoned professionals, programmer orientated folks and those of a more artistic nature. For me that's part of the beauty of Unity it has purpose at so many different levels.

I wasn't that clear on a target audience for this post but I figure it's going to be of more use to the less experienced coders amongst us.

As somewhat of an aside, I'd be curious to see the breakdown of Unity developers between those who exclusively use UnityScript (js) and those who predominantly use C#. I'm using a mix, initially I was sticking more with C#, since it's more similar to the language I know best which is C++. Now I find the terseness and succinctness of the UnityScript quite compelling and I've been using it a lot for the last few components I've work on. There's a downside to UnityScript for sure, but this isn't the topic I set out upon.

One thing I kind of miss when using UnityScript in/as a behavior is the ability to create interfaces. When I say interfaces I mean in the object oriented sense. Interfaces are great when you want to interact with a whole bunch of different objects in the same way. To be more explicit lets look at it in the Unity context.

So lets say I've got a GameObject which has an array of other game objects. (see screenshots).

Normally these would be all identical objects, but what if we want to their functionality to vary somewhat from item to item? In object oriented languages this would be the realm of an interface, but in a Unity behavior (even thought it's an object oriented language) we don't directly have the capability of using an interface. So what can we do?

We can use delegates. Delegates applied sparingly can somewhat mimic this nice object orientated characteristic. It's not quite as elegant but it works just fine.

First of all, it's reasonable to ask if you've never come across the term. “What is a delegate?” It's called something slightly different depending on the computing language are talking about. In C and C++ the equivalent functionality you'd term a function pointer. In my mind the simplest description would be that a delegate is essentially a variable that contains a function or a method. You can “call” the variable just a like a function, and you can assign a function to the variable. If it doesn't make sense now, you may want to read a bit further to see it in action. This might make it clearer.

Say for example we have a bunch of GameObjects. Sticking with some sort of familiar tradition lets call them widgets. So we've got a bunch of widget GameObjects, we've attached our widget script and they're all working nicely. Now if we'd like their behavior to vary a little, how are we going to do that?

First of all lets define a widget script with a delegate that gets called in place of the normal functionality. Once we've done that we can attach another script to each widget to further refine it's behavior. The second script will attach to any selected widget GameObject and assign its own function to the delegate in the primary widget script. In this way you can modify the behavior of the original widget method however you wish. Let's look at some example code of this description, I'm of the opinion it will be much easier to understand.

In my example I have a Master GameObject that contains an array of Widgets. The code of the example script is as such. Note the public array of widgets. This is exposed the inspector screen just as we like it. We assigned our selected widgets in the inspector (see screenshot).


/* Master.js */

public var widgets : Widget[];

function Update () {
   for (var i = 0; widgets.Length; i++) {
      widgets[i].DoSomething();
   }
}

Next we create our Widget GameObjects and their associated widget script.

The widget script is kind of like our object orientated interface through which our Master game object interacts with the widgets. As far as the Master GameObject is concerned, all the widgets are identical.


/* Widget.js */

private var doSomethingDelegate = null;

function SetDoSomethingDelegate(func) {
   doSomethingDelegate = func;
}

function DoSomething() {
   if (doSomethingDelegate) {
      doSomethingDelegate();
   } else {
   /*
   Typical do something code ...
   */
   }
}

function Update () {
}

For deviation of the widget behavior, let's look at the DoSomethingElse script, which will attach to a widget and this modify it's behavior when DoSomething is called. Note that the DoSomethingElse is assigned in this scripts Awake function. This assures it's ready to go when the action begins.


/* DoSomethingElse.js */
private var widget : Widget = null;

function Awake() {
   widget = GetComponent(Widget);
   widget.SetDoSomethingDelegate(DoSomethingElse);
}

function DoSomethingElse() {
   /*
   The brand new wacky functionality that is different to the other widgets
   */
}

function Update () {
}

@script RequireComponent(Widget)

Finally note the “RequireComponent” directive to really make it clear that this script depends on the Widget script being in place.

So as I hope you can see we can now modify a widget's behavior in a myriad of ways using this technique.

Unity: Useful Tricks with Delegates

2009-10-01T19:02:00.000-07:00

Post has moved - please click here

What's in the works

2009-09-21T21:06:00.001-07:00

As a recently formed independent games studio, we've been asked a number of times what our game plan is (pun intended). Starting the studio in Western Australia after working for some big name developers and publishers in Europe represents quite a change. Not only a simple change in geography but a huge change in proximity to the big market zeitgeist, talent pool and investment/funding opportunities.

Despite having some experience in the industry to fall back on we're under no illusions as to what we can realisticaly achieve in a given timeframe. Not to mention we're all a bit older now than when we first entered the industry. No midnight crunches for us while trying to support families and preserve relationships. Initially we're going to keep things simple.

For me that means the first and most import goal is publishing something. Set attainable goals and achieve them; get the dev cycles going and something on the table. Don't get me wrong, I want to create something special, but even Speilberg didn't create his finest films on his first foray out the door. So something special, but achievable.

We were thinking about how this studio might work months before we left our industry jobs and made the migration to Australia. Looking around at opportunities to achieve our goals we did find a path that we think is a good place to start.

It's always been my feeling that to create something worthwhile, it never hurts to understand what makes something worthwile. This thinking walks hand in hand with the ability to identify greatness in others or another's achievements. It was this thinking and a fortuitous meeting of minds with the developers from Data Realms that laid the path we would choose to take for an initial foray into Indie Game Development.

Data Realms have spent years crafting a beautiful indie game known as Cortex Command. The first time I played it was a hurried affair in a lunch break. My initial exploration didn't do it justice but my interest was perked. A few weeks later with more time on my hands (and with a freshly downloaded build) I was able to spend enough time playing Cortex Command to begin to truely appreciate it. I felt then and still feel now that Cortex Command is one of those creative products that has some sort of destiny. With an idea in mind and a fanboy's appreciation in my heart, that motivated me to bring Cortex Command to the Macintosh. Spiritually, the Macintosh version of Cortex Command is the first title for Kruger Heavy Industries. The fact that it was mostly completed by myself before the company was formed probably only matters to the record keepers on Moby Games.

Later in the piece we were very happy to have elected to be involved with Cortex Command. It did very well at the last Games Developers Conference 2009 in the Indie Games Festival, picking up two awards (Technical Excellence and the Audience Award) (some video coverage available here).

Cortex Command is still actively in development, but is largely code complete - at least as far as the Macintosh porting effort is concerned. It's bugfixing and build making for the most part until release. A day we look forward to greatly. Dan, Prom and the rest from Data Realms are doing a fantastic job.

So, what else is in the works for Kruger Heavy Industries? Fresh from our experience porting Cortex Command we picked up another great game we felt deserved some love on the Macintosh. Currently in active development is the Macintosh version of Eets: Hunger. It's Emotional. It was developed by our friends over at Klei Entertainment. One of their first titles, it's been lavished with much love and attention to detail by the Klei team. We won't tell you too much about Eets right at this moment as we're looking forward to that in a future post. For now we would like you to know we're really looking forward to having Eets playable on the Macintosh and putting that second building block into the foundation of our little studio here in Western Australia.

First Experiences with Unity 3D

2009-09-14T00:21:00.000-07:00

I first heard about Unity 3D early last year when some rumblings were made about it in Indie Games Circles. I wasn't really doing much with regards to Indie Games at the time and the company I was working for at time had it's own technology. On top of that Unity 3D was only really available for the Macintosh platform at the time (Windows version was still in Development). With all that in mind it didn't seem like I was going to get a chance to try out Unity 3D any time soon.

Fast forward now to last month. I've just started a new contract for a local mob. We're using Unity 3D, predominately on the Windows platform. So I've finally got the chance to look at Unity 3D properly. My first impressions have been predominately positive.

Unity is probably best described as a Game Engine and Editor “all in one”. It's an IDE, a level editor and properties tweaker. The professional version also has some source control functionality. There is a lot of functionality included in the package an it has the potential to save an enormous amount of development time.

The User Interface

The User Interface is visually appealing, I suppose it would have to be to suit the fashion concious Macintosh crowd. The main interface is broken up in to several areas, the Game View, the Scene View, the Hierarchy View, an Assets View and the Inspector. The game view allows you to review the status of your Game, it's essentially what the game would like. It can be set to run, pause and stop basically allow you to run the game and see what's happening as you build it. If you want to see an animation running in your scene all you have to do is hit play.

The scene view is similar to the Game view but is more orientated towards the actual development process. The scene view will show the scene and level objects in a simple form as well as many of the other implicit objects required for the game logic. The Camera in the scene view is free moving. Models and Game objects can be orientated, placed and scaled all the in the scene view. The interface is quite a lot like 3DS Max in the basic controls.

The hierarchy view (a panel really) is clearly inspired by a Scene Graph. It is essentially a list of objects in the scene, it also displays (via it's heirarchical nature) how these scene objects relate to each other. With it you can quickly find any object in your scene. In the Hierarchy panel, you can select an object, then when you move your mouse pointer over the scene display, pressing “F” will focus the scene view on the select hierarchy object. This without a doubt saves a lot of time. The hierarchy view is also useful for attaching components (behavior modifiers, graphical sugar and script/logic) to your scene objects.

The inspector panel works closely with the hierarchy and asset views. All objects, behaviors and such in your scene have properties associated with them. These properties are exposed by the inspector and can be directly manipulated. Running the game in real time and tweaking values in the inspector allows you to rapidly tune settings for a visual effect or game play behavior.
Finally the last main view or panel is the Project or Asset panel. This is where you can see all the assets in the scene. It's also where you can import new assets into the scene and construct prefab objects (objects that can be used again and again). All assets that have been imported into the assets can be edited from their new locations. Changes are re-imported and applied almost instantly.

Programming

The actual programming side of is done via scripts written in Javascript or C# . Although there is the ability to use plugins in the professional version which are written in C, C++ and or C# - I assume on the Macintosh version we can also use Objective C). The Javascript is really UnityScript I suppose, while sharing many similarities with Javascript there are some notable differences as well, particularly when it comes to the way objects work.

Scripts are typically assigned to game objects where their interfaces are called as the game logic progresses. Scripts assigned to game objects are known as behaviors. The script editor built into Unity 3D is Scite which is a well known simple editor. For more professional programmers who are used to the fully feature code environments such as the likes of Microsoft Visual Studio they may be disappointed. The environment notably lacks any easily accessible debugging, so you'll probably be spending a lot of time doing the old print debugging thing of yesteryear. Thankfully as everything else about the environment makes achieving results easy, this probably isn't as painful as it sounds. At least for small projects.

Under the hood Unity basically creates dynamic libraries with the code that is compiled from the Game scene in development. This is most likely how the Unityscript/Javascript is so fast. Indeed the it becomes apparent that the Javascript i really just a thin veneer over the C# innards and as you start to realise the Unityscript's differences to Javascript it becomes clearer what is going on underneath. Of course it's not Microsoft .Net implementation but rather the C# implementation made available via the Mono project.

Source Control

In the professional version, Unity's own source control functionality is available. It's not brilliant. It's some hodgepodge or Unity 3D UI, with a backend of a Postgres database. Over low latency links it's horrible and generally it lacks features. Strangely it's also one of the most expensive accessories for Unity. I can sort of the see the logic in it, those requiring source control will most likely be the ones cashed up enough to be able to afford it. In effect subsidising the cost of Unity's development and cheap price to Indie Developers and students.

Conclusion

I'm overall feeling positive towards Unity 3D. I've still got a lot to learn but I can see enormous utility in the package for what amounts to (especially for Indies) a lot of bang for you buck. Depending on how my experiences go I may consider using the Engine/Tool myself on a title I've been mooting. I hope to post updates on my experiences as I go.

Net2Max is in my good books

2009-09-02T03:58:00.000-07:00

I've been using Net2Max for a couple of months now and I've been pretty happy with it. It's not exactly user friendly but once you understand the basics it does the job better and cheaper than everything else I've tried.

My business number runs on the system. I just chose the country and state I wanted the number to be associated with and connected it to my Net2Max and account and voila - I've got a business number. I've connected this number to a PABX system that I configured on Net2Max to do call routing exactly how I want. For the most part it goes to my voicemail box. Messages that are left get emailed to me immediately, and since I'm almost always online I can check them immediately.

If my business ever wants to expand or have a presence in another state or country, I can easily select a local presence number in just about every significant country. All the calls get routed back to my account.

Alternatively I can can configure any voip phone to receive calls for this number, of my skype account if I so wish. It's extremely versatile. I've got a Belkin VOIP router at home, I've got four standard phone ports in the back. One port is configured for my home phone number, the 2nd port is configured to my business number. During the evening, I plugin my wireless handset into port 1. During the day, if I'm working from my home office, I plug the handset into port 2 and switch off the voicemail.

All that flexibility is very useful and it comes at a reasonable price too. I'm currently spending about $3.00 Australian a month on business calls, the business number rental, voicemail and the pabx. I don't know how they do it so cheap. Best of all I think is the complete control I have over everything. I don't have to call up some dope on the phone and ask them to change the configuration of anything, it's all handled through a website online that I can login to from anywhere.

For me calling up is one of the last things I like to do, so this a huge plus to me.

Welcome

2009-05-05T01:23:00.000-07:00

Well a warm hello. This is the start of our development blog. Lets see how we go. We'll be blogging about technical things, the studio and other interesting things related to games development and Indie Games.