Tag Archives: Leopard

Missions of the Reliant: Back on the Radar!

It’s been a long time since I made any meaningful posts about Missions of the Reliant, but here I am at last to tell you all that I haven’t abandoned it! First before anything else, thanks to everyone for your exemplary patience with me over the last year or so with no word.

Coming back to the code after all this time and with the experience hard-won in other code, I can see that in the past I was both absolutely brilliant and somewhat stunted :). However, most of the issues that I see have more to do with the code having been originally designed when Leopard was the latest and greatest OS; the technically inclined among you will remember with horror the days of no libdispatch, libcache, libclosure, ARC, or ZWRs. I say without shame that a lot of problems I’ve had (and a few that still exist) would never have happened if I’d had ARC to work with from the beginning.

This brings me to the secondary point of this post – Missions will be the better (and the more quickly completed) for an ARC migration. ARC is supported on Snow Leopard, but one of its most powerful features, Zeroing Weak References, works only on Lion. I had this same debate when SL itself came out, and I’m faced with it again: Am I comfortable with limiting Missions to working only on Lion?

So here I am, asking for the opinion of the loyal followers of this project again, with it kept in mind that I’m working on the code either way: How many of you would be left out by a Lion requirement? (And, more amusingly, how many of you would upgrade to Lion at last just to play!? :)

I’d like to say thanks again to everyone who’s bothered themselves keeping up with my near-silence over the time since I started working on this port. I’ll post again as soon as I have the project building in Xcode 4 (yes, it’s been so long since I touched it that I have to retool it for a whole new Xcode version!). Until then, happy space flights to you all!

Missions of the Reliant: Cleaning up the wreckage of the train crash

I’m back, and I didn’t give up on Missions! I’m sure there must be exactly one person out there who cares :-).

But seriously. I don’t have any new features to show at the moment, unfortunately. When I went to implement the laser cannon for the player, I realized I’d never be able to test it without something to fire at. I also realized the cannon itself would be useless without the target scanner since it has to lock onto a target. The scanner is also useless without something to scan. So, it was time to implement the base code for mobile enemies. Probably should’ve done that long ago, and here’s why…

As we all know, I’m using Objective-C to write this code. That means, among other things, that my code is object-oriented in nature. Up until this point, things like planets, starbases, and the player had all been entirely separate implementations. This is what Mike did with the original code. As always, what he did then was only sensible for the time and environment, but I can avoid a hell of a lot of code duplication by giving everything that exists in space a common superclass: a “Presence”. (Presences are themselves subclasses of the even more general “Responder”, which is used for everything that needs to process game happenings in any way, but that’s only a side note). As one can imagine, since I didn’t have the foresight to design the code this way to begin with, implementing it now required some significant refactoring.

Another issue cropped up halfway through the refactoring: The severe limitations of Apple’s built-in Key-Value Observing, which I use extensively throughout the code to avoid having to call “update this” and “update that” manually for every single affected object whenever something changes. For example, KVO doesn’t let you use blocks for callbacks, and if a superclass and a subclass both register for the same notification, there’s no way to manage the two independantly. Fortunately, Michael Ash noticed these problems some time back, and created a replacement, his MAKVONotificationCenter. Unfortunately, even the updated version published by Jerry Krinock didn’t do everything I needed, at least not in a way that I found usable with blocks added to the equation. Managing observations by tracking the resulting observation objects means having lots of instance variables to hold the observations, and since I’m building for Leopard, I can’t use the new associated objects for the purpose.

“Wait a minute,” you’re saying! “Leopard? Then why are you talking about using blocks?” Answer: I’m using PLBlocks.

So, armed with PLBlocks on one side, and Michael Ash’s typically brilliant code on the other, I dove in and pretty much rewrote the entire MAKVONotificationCenter to do three things it didn’t before:

  1. Block callbacks.
  2. Tagging observations with a simple integer value.
  3. Several alternative ways of specifying groups of observations to remove, based on observer, target, key path, selector, tag, or most combinations thereof.

With that done (and unit tested, and Doxygen-documented), I’m now integrating them into my revised class heirarchy for Missions itself. With any luck, I’ll have at least a screenshot of a fighter flying around before the week is out. Stay tuned, those of you who are crazy enough to stick around for all this :-).

Footnote: I was finally able to find a way to access the original model files for the game’s graphics; with some luck and a bit of help from Mike (I’m clueless when it comes to this stuff), there may be higher-quality graphics to be seen in the screenshots soon.

Key-Value Observing on classes

In the course of experimentation, I just discovered a neat trick. You can use key-value observing on a class object! Consider this simple example:

#import <Cocoa/Cocoa.h>

static int      Test_x = 0;

@interface Test : NSObject
+ (int)x;
+ (void)setX:(int)x_;

@implementation Test
+ (int)x
        return Test_x;

+ (void)setX:(int)x_
        [self willChangeValueForKey:@"x"];
        Test_x = x_;
        [self didChangeValueForKey:@"x"];
@interface Observer : NSObject
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context;

@implementation Observer
- (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context;
        printf("observed for %s, value = %d\n", [keyPath UTF8String], [Test x]);

int     main(int argc, char **argv)
        NSAutoreleasePool               *pool = [[NSAutoreleasePool alloc] init];
        Observer                        *o = [[[Observer alloc] init] autorelease];

        [[Test class] addObserver:o forKeyPath:@"x" options:NSKeyValueObservingOptionInitial context:NULL];
        [Test setX:99];
        [[Test class] removeObserver:o forKeyPath:@"x"];

        [pool drain];
        return 0;

And it works!

$ gcc kvotest.m -o ./kvotest
$ ./kvotest
observed for x, value = 0
observed for x, value = 99

It has some caveats, of course:

  • Automatic notification doesn’t work, probably for some reason having to do with the way the runtime implements class objects and the method swizzling KVO does to make automatic notifications work. Your setters have to explicitly call -willChangeValueForKey: and -didChangeValueForKey:
  • This is a hack. It’s not documented to work at all and thus Apple is under no obligation to see that it keeps working.
  • You’re not supposed to do things like this with classes. You’re supposed to define a singleton object, e.g. [NSNotificationCenter defaultCenter] and use that.
  • I’ve only tried this on Snow Leopard (though it was compiled against the Leopard SDK). I don’t have anything else handy to test with.
  • I haven’t tried this with any of the more advanced KVO features (to-many relationships, dependent keys, NSKeyValueObservingOptionPrior).
  • Obviously, as shown this isn’t thread-safe, though that’s more for the use of the static variable to hold the value.

The only use for it I can think of offhand is when you have a class which keeps a list of its objects and provides a method for accessing that list as an array, and you want some other object to be notified when that list changes (for example, one could in theory want to observe changes in NSValueTransformer’s +valueTransformerNames). The documentation explicitly states, “Instead of observing an array, observe the ordered to-many relationship for which the array is the collection of related objects.”, so to see changes in the list by KVO, one has to observe the property of the class itself. Classes can’t have properites (or static instance variables, come on Apple), so something like this is one way of doing the trick.

Use at your own risk!