OSX: Carbon Event Loop not firing - Application unresponsive

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

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

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

Post has moved - please click here