First off, a screenshot. It might not look like much (or anything), but this is actually a bit of a milestone: that’s a glk window in CocoaGlk running under aspen:

The reason this is interesting is that it was actually several days worth of work before CocoaGlk could achieve the same feat. I’ve been able to take across even some of the UI code from the ‘full’ OS X version of CocoaGlk, so things are progressing quite fast.

There are still a few things that I need to make some decisions on, though. Read on for the details.

Read the rest of this entry »

After some wrangling, I managed to get the SDK to download. Apple’s servers decided to reset my download after 12 hours at 1.6GB in such a way that Safari thought the entire thing had downloaded, so no resuming… Or at least there would have been no resuming if I hadn’t started a new download and applied some text editor-fu to the Info.plist in the .download package to make it think that the 1.6Gb file was the thing it should have been resuming. Sheesh, even the hopeless transfer manager that Microsoft makes you download stuff from MSDN is better than this.

This means that I managed to get the SDK installed an hour ago, and spent some time pointing it at the GlkClient source files, which compiled with barely a hitch: mostly I just needed to replace Cocoa.h with UIKit.h and change some NSColors to UIColors. Awesome: you can compile UI-less glk interpreters now. That’s the easy part done: now I need UIKit implementations of the glk protocol classes, and some new startup code to run the interpreter in a separate thread instead of in a separate task (which would be pointless on the iPhone and would probably annoy Apple anyway).

I’ve also created a Google Code project for this, so you can track progress at http://code.google.com/p/cocoaglk.

So, Apple have (finally) released the iPhone SDK today. developer.apple.com is apparently too busy celebrating this momentous occasion to actually bother to respond to any http requests so I haven’t had a chance to look at the SDK yet.

Even so, I plan to port CocoaGlk as soon as I get my hands on it, at least assuming the requirements for distributing free software aren’t too onerous. $99 for a key doesn’t sound too bad to me, anyway.

I’m not entirely sure what to expect; I haven’t played around with jailbreaking my iPhone, so I’ll be going in blind. What I think is likely, however, is that half of CocoaGlk will port just fine: that is, the GlkClient framework that interfaces with the interpreters. What is less certain is how well the UI half will port: that is, GlkView. If NSTextView is ported, and the typesetter behaves the same way, then it’s going to be really easy to get the UI working in some manner, and probably not that hard to support all the features of blorb.

Getting games onto the phone is also a bit of a challenge. I think that taking some of Zoom’s existing inventory management and connecting to IFDB might be a good idea.

I’ll post a beta when I get things working: I imagine a glulx or frotz-based interpreter is likely to be released first. I’ve been thinking about doing something with LLVM to JIT games; something that would be a curiosity on the fast machines that CocoaGlk runs on at the moment, but which could be vital to running games on the much slower iPhone.