Gwynne's Blog

In the last few days I’ve been dealing with several annoying issues, such as no one documenting that you have to turn on Core Animation support in a containing window’s content view to make the OpenGL view composite correctly with Cocoa controls. Four hours wasted on one checkbox. Sigh.

Still, there’s some progress to be had.

1. The loading bar now displays and loads all the various data needed.
2. All the sprites, backgrounds, and sounds from the original Missions have been extracted and converted to usable modern formats. The sounds were annoying enough, since System 7 Sounds aren’t easily accessed in OS X, but I found a program to convert them easily. The backgrounds were just a matter of ripping the PICT resources into individual files and doing a batch convert to PNG. The sprites… those were a problem. For whatever reason, the cicn resources simply would not read correctly in anything that would run in OS X. Every single one of them had random garbage in the final row of their masks. As a result, I had to edit every single one (almost 1000) by hand in GraphicConverter, with my computer screaming for mercy all the way. Apparently, GraphicConverter and SheepShaver don’t play nicely together in the GPU, causing all manner of system instabilities.
3. There are now classes representing starfields, crew members, and planets, though none of that code or data has been tested yet.
4. I’m now building with PLBlocks GCC instead of Clang. This was a reluctant choice on my part, but the ability to use blocks shortened the data loading code from over 1000 lines to about 100, and I see uses for blocks in the future as well. Pity the Clang that comes with 10.6 refuses to work correctly with files using blocks and the 10.5 SDK.
5. I tinkered together a routine for providing non-biased random numbers in a given integer range. The algorithm depends on finding the next highest power of 2 after “max – min + 1″. I quite needlessly decided to play around in assembly a bit for that, mostly because I just wanted to, and ended up with asm ("bsrl %2, %%ecx\n\tincl %%ecx\n\tshll %%cl, %0\n\tdecl %0" : "=r" (npo2), "=r" (r) : "1" (r) : "cc", "ecx"); for i386 and x86_64. I fall back on a pure-C approach for PPC compilation. I haven’t benchmarked this in any way, and I know for a fact that doing so would be meaningless (as the arc4random() call is inevitably far slower than either approach). It was mostly an exercise in knowing assembly language.
6. The “new game” screen, where the scenario and difficulty are selected, now exists. That was also interesting, as it involved shoving a Cocoa view on top of an OpenGL view. I can use that experience for all the other dialogs in the game.

As always, more updates will be posted as they become available.

Alliance Headquarters
Stardate 2310.12630998555023

Those who have been using Macs for at least 14 years may or may not remember a space game for old Macs that went by the name “Missions of the Reliant”.

It was a really fun little game with a few missions in it, changable crew members in your ship, powerups for your ship, a nice big galaxy to hang around in, systems that took damage and could be repaired… if you’re thinking Rescue!, don’t, Missions was much better.

Anyway, like all the old Mac games, it’s long since nonfunctional on modern machines. But I wasn’t willing to settle for that, so I pulled up my e-mail and wrote a letter to Michael Rubin, the original author of Missions, asking if I might get the source code and take a crack at porting it to OS X.

His enthusiasm was beyond anything I could have hoped for. I’m very grateful to him for the opportunity he’s given me to bring a classic back to the Mac. I’ll be posting updates here regularly about my progress on the port.

Progress Report 1

Well, I’ve got the code, and I’ve looked it over. Ah, the old glory days of Pascal, inline A-traps, GWorlds, manual event handling… The Mac Toolbox did almost nothing for you; it was a true low-level interface to the OS, something I feel we’ve gotten away from in these days of Cocoa. Sure, OS X has the POSIX interfaces, but they’re a whole different world. Anyway, the code is a real trip back to olden times, and I love every minute of it.

First step was to create the Xcode project. That took about three hours.

Wait, what? Three hours? Well, once you figure setting up the project settings, the target settings, tweaking the things Xcode’s templates don’t get quite right, editing the pregenerated files to not have broken line breaks and incorrect heading comments, and writing the entire Info.plist for the application, that’s a lot of work! I had to look up Info.plist keys, UTI listings, sweep the original source code for the proper value of NSHumanReadableCopyright, and ask a question or two about semantics in the #macdev IRC channel.

Next step, I figure, is to sweep up all the original visual resources – strings, pictures, icons – and reorganize them out of old-style rsrc files into a modern application’s Resources folder. Yes, I’m aware you can still use resource files in OS X, but I feel if you’re going to do something, you might as well do it right!

After that, I have to take a little time out to brush up on my OpenGL 2D, it’s been awhile since I used it and I never did use it for anything this complex. Binding several dozens of textures to represent all the various sprites should be a fascinating undertaking.

I’m enjoying the hell out of myself *grin*. Thanks again, Michael!

Time and time again a thread will come up on the xcode-users mailing list about how to make Xcode put a build number in an application’s Info.plist.

The first answer is always agvtool, but it’s the wrong answer, as agvtool is a version manager for public versions. It’s what generates all those wacky numbers you see in Mac software, such as “Mac OS X Version 10.6.2 Build 10C540″ or “Xcode version 3.2.1 build 1613.0″. It’s certainly not the simple build number people are looking for.

Everyone has their own way of dealing with this, as Xcode makes it extremely difficult to handle it in any elegant way. For example, because Xcode absolutely insists on processing Info.plist before doing anything else in a build (why? why!?), you can’t just plug in a build setting replacement and be done. Various and sundry methods exist, most of which involve either writing the value to the generated Info.plist in the built product or modifying the original Info.plist on every build.

I don’t like those methods, so I came up with one that will work nicely and store the build number as a setting within the project file. Much nicer, IMO, than having to touch your Info.plist file every build and then committing the numbers to your version control system.

1. Add a new Run Script build phase to your project. Place it before all other build phases if you want the number to increase for all builds, or after if you want it only to increase on successful builds.
2. Make sure “Run script only when installing” is shut off.
3. Enter “/usr/bin/osascript” as the Shell for the script.
4. Enter this script:

   tell application "Xcode"
       set prj to system attribute "PROJECT_NAME"
       repeat with config in build configurations of project prj
           try
               set x to build setting "CURRENT_PROJECT_VERSION" of config
               set value of x to ((((value of x) as number) + 1) as string)
           on error
               set value of build setting "CURRENT_PROJECT_VERSION" of config to "1"
           end try
       end repeat
   end tell
   set srcrt to system attribute "SRCROOT"
   set iplstf to system attribute "INFOPLIST_FILE"
   do shell script "touch " & srcrt & "/" & iplstf
   

5. In your Info.plist file, add or set a key like this:

       <key>CFBundleVersion</key>
       <string>${CURRENT_PROJECT_VERSION}</string>
   

Figuring out how to make build numbers on a per-target or per-configuration basis is left as an exercise to the reader :-).

P.S. I hate Applescript, but it’s the only way I know of to set build settings in an Xcode project.