I’ve decided to make the code I ended up with public in the hope that it avoids someone a little head scratching down the road. It should be noted that the following code makes use of Oscar Del Ben’s fantastic NSScreen+PointConversion category to help with determining the active NSScreen and flipping said screens coordinates.

The following code should handle flipped coordinate systems and multi-monitor displays gracefully. Also included is a function to warp the mouse (without simulating any events) to a specified point in screen coordinates.

- (NSPoint)convertToScreenFromLocalPoint:(NSPoint)point relativeToView:(NSView *)view
{
	NSScreen *currentScreen = [NSScreen currentScreenForMouseLocation];
	if(currentScreen)
	{
		NSPoint windowPoint = [view convertPoint:point toView:nil];
		NSPoint screenPoint = [[view window] convertBaseToScreen:windowPoint];
		NSPoint flippedScreenPoint = [currentScreen flipPoint:screenPoint];
		flippedScreenPoint.y += [currentScreen frame].origin.y;
 
		return flippedScreenPoint;
	}
 
	return NSZeroPoint;
}
 
- (void)moveMouseToScreenPoint:(NSPoint)point
{
	CGPoint cgPoint = NSPointToCGPoint(point);
 
	CGSetLocalEventsSuppressionInterval(0.0);
	CGWarpMouseCursorPosition(cgPoint);
	CGSetLocalEventsSuppressionInterval(0.25);
}

Unfortunately I wasn’t able to find a simple, uncluttered web interface for viewing historic App Store ranking data. Which is why I spent this weekend knocking up AppStoreRank.net. It’s a fairly simple site with a fairly simple objective: display data and don’t piss people off in the process.

I use it to track my own applications and to also get an appreciation for just how turbulent ranking can be towards the lower end of the top 100 scale. Hopefully some of you find it interesting too.

Houdini will soon appear in the Mac App Store. Relax! It’s still free. This is just a note to say that I will be retiring the currently active Sparkle appcast. Which means that all future updates will be exclusive to the App Store.

Edit: Houdini is now available to download.

SpriteRight is a spritesheet generator for the Mac that lets you import your existing images or stylesheets. Make your sites load faster, cut bandwidth costs and save time. SpriteRight even generates CSS code on the fly. And best of all, it’s available now on the Mac App Store.

The entire situation brings Eli Pariser’s talk on filter bubbles back into focus. It’s a wonderful presentation that really helps to personalise the net neutrality issue.

I’m in the process of writing a hobby game for the iPad that’s fairly far along in terms of development, but still an infant where aesthetics are concerned. It’s full of programmer art and debugging messages and generally things people don’t attribute to a polished product. So today I thought it would be interesting to document just how much work goes into a seemingly simple detail: handling player death and giving visual feedback.

In video games when players meet a grisly end their bodies are often gibbed. A gib, in this case, can be thought of as a chunk of meat or an appendage. In other words: generally stuff you want to keep about your person. Duke Nukem 3D was famous for its elaborate gib sprites (including everything from eyeballs to ribcages and, of course, the ultra-rare testicles).

Fortunately, the game I’m putting together isn’t 3D (or even faux-3D). In fact, it borrows more from the older generation of side-scrollers and platformers. So when it came to adding gibs to our game, I looked to more recent examples, such as the gore-heavy Super Meat Boy.

Jetpack Janitor (as I’ve affectionately nicknamed it) sees players navigating a variety of levels as a jetpack-clad janitor. You’ll move through various levels in a bid to return power to the ship you watch over, avoiding obstacles and hazards as well as solving various physics-based puzzles. Here’s a rough snapshot of a test level featuring a few keys, a closed airlock, and a wall of buzzsaws. You’ll have to excuse the programmer art.

When Stan (that’s our janitor) hits a buzzsaw, he is killed immediately. What we want to do today is not only kill Stan, but also have his body cut into ten or so meaty chunks and distributed about the level.

The Jetpack Janitor engine has been built from the ground up to integrate with the box2d physics engine. This means that every entity (object on screen) is represented by a physics-enabled object. The graphics you’re seeing, from the tilemap that makes up the level, to the player sprite and particle effects, are simple graphical representations that are updated by the physics simulation at regular intervals.

To get the ball rolling, I went ahead and created a Gib class. Because we wanted our gibs to roll around the ground after landing on a surface, I modelled each Gib instance as a circular dynamic body. By turning on debug rendering, you can see that now, when Stan explodes, his body is replaced by three Gib instances (shown here above the buzzsaws):

Unfortunately, while the Gib instances behaved as expected, something felt a little off. I spent a while tweaking their restitution and friction before reaching a point where things felt ‘right’. Finally, I increased the number of Gib instances spawned on death and made the radius of each Gib randomly decided upon instantiation.

With the Gib instances behaving nicely within the physics simulator it was time to up the gore level slightly by allowing each instance to create a finite number of decals. A decal is created each time a Gib collides with a static physical body (such as a wall). In this case, each decal represents a bloody stain that gets painted onto the level geometry.

The plan here was to use a single decal sprite which would then be rotated programatically to fit against the surface it had collided with. As you can see from my initial tests, the method I had hoped to use as a means of calculating decal rotation didn’t quite make the grade. You’ll notice some blood smears towards bottom of the screen are incorrectly rotated.

There are, of course, far more bullet-proof means of calculating the angle and position of such decals. But for our purposes, a simple check against the point of collision versus the relative position of our body seemed to suffice.

With decals working nicely, it was time to work on the actual Gib rendering code. This was a fairly simple case of scaling the meatwad graphic based on the randomly chosen Gib radius. Below I’ve included three screenshots of Stan meeting an untimely end:

So what’s next? Before this code can be considered final, it’s now time to hand it over to Glynn for an art and sound pass. As a result, the code I’ve written is likely to change to encompass the following requirements:

• A random variety of splatter decals and gib sprites
• Particle effects during the players initial ‘explosion’
• Particle emitters tied to each Gib instance
• And finally, the ability for Gib instances to generate squishy sound effects upon collision with other entities

Hopefully this post has given an interesting insight into the amount of work that goes into even a simple game element.

It was the first Mac application that I’ve realised in a personal capacity and it’s been very rewarding to hear that people are finding it useful. It’s been mentioned and reviewed in a couple of different places and seems to be doing pretty well for itself.

Really useful app! This is already improving my concentration and workflow. Very, very useful and well-done app. I’d pay for this on the MAS.

The app looks good and has a couple of nice settings. Despite the author claiming the app is ugly, it’s quite useful.

The NSFetchRequest in question uses an NSPredicate to fetch Files entities with a given path. As can be seen from the original query, I’m performing a case-insensitive comparison of each records path attribute with a receivedPath string.

NSPredicate *predicate = [NSPredicate predicateWithFormat:@"path ==[c] %@", receivedPath];
 
NSEntityDescription *entity = [NSEntityDescription entityForName:@"Files" inManagedObjectContext:self.moc];
NSFetchRequest *request = [[NSFetchRequest alloc] init];
[request setEntity:entity];

While I had indexed the path attribute and ensured that I was using an NSSQLiteStoreType backing store, I hadn’t considered exactly how CoreData would treat the case-insensitive modifier internally. By passing my debug build the -com.apple.CoreData.SQLDebug argument, I was able to ascertain that the comparison makes use of a custom CoreData SQLite function: NSCoreDataStringCompare.

Essentially this meant that SQLite was boiling the string comparison down to a fairly costly LIKE statement, meaning my index was being overlooked completely. To solve the issue I simply created a secondary attribute: lowercasePath, ensured it too was indexed, and used a direct string comparison, like so:

NSPredicate *predicate = [NSPredicate predicateWithFormat:@"path == %@", [receivedPath lowercaseString]];

The results were staggering. The function in question is no longer significant enough to even register during profiling runs.

A lovely set of free social media glyphs by GSIX Corp, Inc. Left here more for my own record. But please feel free to check them out.

Via 9-Bits.

Here’s a quick list of the changes we’re hoping to roll-out later this week:

• Within your Watchlist, the Upcoming section will now show the next episode of a series that is due to air. We think this one will make a lot of people very happy.
• We’re looking to introduce the ability to mark historic episodes as being seen/unseen. Making your way through an old Mad Men boxset? Not a problem. Tick episodes off as you watch them.
• Finally, we’re making it possible for users to allow friends to see what’s on their watchlist. The service is totally free, and it’s opt-in. You can see an example of a public watchlist here (note: still very much a work in progress).
• A number of UI tweaks and fixes to customise and polish certain native behaviours we weren’t very happy with.

Look out for Episodes v1.1 in the near future.