SteveStreeting.com

My MacBook Pro appears to now be in a state of quantum flux. As previously mentioned it worked fine yesterady when I took it in, and indeed I used it for most of the morning (testing) and most of the evening (doing some Dx10 work). This morning though, it was back to the same problem so I took it in again to demonstrate it.

As if to mock me, whilst it at least demonstrated the problem on boot up, as I was filling the incident report form in and it was sitting idly on the desk untouched next to me, it suddenly decided to right itself. ‘Hey, I can work when I want to!’ it jeered. Since the engineer isn’t in on Saturdays I booked it in for surgery on Tuesday next week and took it home on the assumption I might get some use out of it, to which the MBPs response was to fail again when I got home. Spiteful little bastard.

Clearly there’s some kind of bad connection or temporary problem, I’ve tried the obvious highly technical things like wiggling the lid hinge and light ‘tapping’ to see if it’s a physically dodgy connection but it has no effect. Maybe it’s temperature related, although when I had it back home I left it on for a while to get a little warm and it didn’t change. Hey ho.

I’m reminded of a certain classic british sitcom:

Percy: He must be on his last legs by now, My Lord.
Edmund: Yes, but how many sets of legs has that man got? Really, I wish he’d make up his mind — either he dies, or he lives forever! It’s his shilly-shallying that’s so undignified.

Amen.

Typical. Not unwelcome, but still typical. After experimenting multiple times with my broken MacBook Pro last night, I’d given up and first thing this morning I took it to my local Apple reseller, iQ (actually there are 2 in the island, but iQ are ‘Premier’ resellers and that’s where I bought it). I was explaining the problem and fired the machine up, and what do you know, it was fine.

Weirdly, the last thing I’d tried last night was clearing the PRAM & NVRAM (hold Command-Option-P-R when starting) since I’d read some reports of that solving some unusual issues. Having done that, nothing changed, but I assumed it had actually cleared the settings because I got the ‘chime’ at powerup time, which I don’t normally because I turn the speakers off, one of the settings kept in the PRAM I think. So I’d been resigned to it being a genuine hardware fault.

So I had a chat with manager Justin whilst I was there, and based on the description it sounds like either it was a temporary glitch which resetting did solve after one additional power cycle, or it’s an intermittent hardware problem, perhaps with the GPU or the DAC which feeds the LCD (he seemed to think that was more likely given the symtoms than a broken LCD, even though the external monitor worked). Since getting back I’ve run the Apple Hardware Test in ‘extensive’ mode but it didn’t highlight anything. We’ll have to see.

He also told me that iQ fix Apple hardware in-house, Justin has all the Apple Technician certifications so he can just take it into ‘the basement’ to replace bits with full warranty cover. That’s really handy to know and makes me feel happy about having bought it there. On the whole they were really helpful and friendly so I can say I had a positive customer experience there. It’s only a small place and they don’t have that many staff (it only opened about a year ago) but I hope they carry on.

He also told me they don’t think they’ll get Leopard today despite being all geared up for it with extended opening times and such - the Jersey store even put on drinks and nibbles that they’re either not going to use or will just grow fat on in-store

Yes, I fired up my MacBook Pro today with the intention of getting on with some more Dx10 work, but was greeted with a completely corrupted display. It appears that other things are still working, as I can still make some things out through the garbage - right from power on I get the top third of the screen as mostly greyish blank, and the bottom two-thirds as a ’smeared’ version of what I should be seeing, although when I tried sleeping and waking it, I temporarily got a correct login screen view in the top third but it slowly faded into garbage, whilst the bottom section was still smeared. Grr.

So, it’s completely unusable. Only just over 3 months old too, and it worked fine on Monday with no ‘events’ in between that would suggest breakage, it just died on its own. Looks like I’ll have to take it down to our local Apple reseller - I only hope they can just replace the LCD or something, since I spent ages setting up both OS X and Vista the way I like, and I really don’t want to do that all over again. I also had some work in progress code on there I’d prefer not to lose, although it wouldn’t be a disaster if I had to.

In all, grr.

So, a formal release date for Mac OS X 10.5 aka ‘Leopard’ has been set now, 26th October or just over a week away. Really it should have been out by now, this represents a 4-month delay on the original release schedule which was to see it released with the ‘Santa Rosa’ Macbook Pro line - slightly disappointing but keeping it in context, it could have been a lot worse.

The pricing is kind of interesting - for a single license it’s £85, which places it smack in the middle of the Vista price range (OEM versions of Vista range from £60 to £100, ignoring the pointless Home Basic), but far more interesting is the ‘family pack’, which can be installed on up to 5 machines in a single household for £129. Now, I’m doubting that very many households actually have 5 Macs, but even if you have 2 it’s a saving, and it starts looking very attractive indeed at 3. I’m actually surprised Microsoft hasn’t done something like this to encourage the flagging sales of Vista, although I’m guessing the demand would still be stunted somewhat by the upgrade requirements in a family environment where apart from little Johnny who perpetually salivates (or worse) over Crysis screenshots, the rest of the household are likely to be running sub-par machines.

Also, I’m sure I’m not the only one to notice that ‘upgrade’ versions of operating systems seem to have quietly become irrelevant. OEM versions of Vista are cheaper than buying a retail upgrade from XP, and Apple don’t even seem to offer upgrade deals for Leopard; the price probably doesn’t warrant it. Hopefully this is an increasing sign of commoditisation in the operating system market, which can only be a good thing. The days when you could sell an operating system based on whether it did ‘true’ multitasking or whether it crashed less or not are finally over - consumers rightly just expect these things as standard. The differentiating factors in commercial operating systems now are not so much major core features (although they can still be a factor, like Time Machine), but style and ease of use. Application compatibility is still a factor to some degree, especially given the considerable success Microsoft has had over the years wooing developers to be single-platform with easy to use tools & frameworks (starting as far back as the first version of VB), but in the wider industry more and more application stacks are now cross-platform, thanks in no small part to the open source community; so you’re rarely stuck without a good application option on any platform now. So without style/flair or ease of use, you have no real need to buy a commercial operating system anymore, there are plenty of free ones that will give you the same thing with perhaps a little more coaxing (e.g. the next version of Ubuntu, which has Compiz enabled by default).

This is where Vista failed in my view. Style wise it’s stuck in a difficult situation - you can’t change too much without alienating the existing user base, but at the same time when you don’t have that many core new features that people need (hence the artificial welding of large chunks of the Dx10 featureset to Vista when most of the major features could have been delivered in XP, a transparent shoring up of the value proposition) , you have to try to do something interesting. The interface changes in Vista feel mostly derivative and ‘bolted on’ in a way that makes them entirely discardable - necessary perhaps to scale back to people who can’t run Aero, but it also saps the value right out of them. I can happily run Aero on my machine, I just choose not to because I don’t see the point, my user experience is not enhanced in any substantive way by having it turned on, as opposed to my battery life and ‘lap temperature’ which certainly benefit from having Aero off. Because OS X was built with the assumption that hardware graphics were available everywhere, the effects that are there feel like they have more of a core purpose. They also don’t toast the machine constantly ;). I have no idea how much actual usability benefit Compiz brings to Linux in everyday use since I’ve never tried it, perhaps others can comment on how well that works.

Still, I’m not going to be rushing out and grabbing Leopard because although there are a few things I like the look of (particularly XCode 3), I’m not champing at the bit, and I have plenty to keep me busy for a couple of months anyway. I’ll let it bed in a bit first and perhaps upgrade early next year.

Here’s a quick tip for you - XCode helpfully makes using precompiled headers in your project a cinch, even easier than trusty old MSVC in fact, which is a good thing. Unfortunately, it also places the result of said precompilation step in a shared location by default, namely /Library/Caches/com.apple.Xcode.$(UID)/SharedPrecompiledHeaders. It actually creates folders in this location corresponding to each combination of target name and a hash of the compiler settings used. The idea here, which seems sound to begin with, is that it wants to try to re-use the results of the precompilation as many times as possible.

Again, this unfortunately becomes a problem the minute you want to use multiple branches of the same project / target, because the target names and compiler hashes are identical, but the headers themselves can be very different - and you start getting funny compiler errors when everything in the code looks perfectly fine. The problems of course go away the minute you hit ‘Clean’ or touch a header that’s included in the PCH, and I’d missed this problem until now because I just happened to be jumping between branches relatively infrequently on OS X so one of those conditions masked the problem. Then all of a sudden it bites me in the ass when I’ve seemingly made no changes.

It’s easy to fix, just hit Apple-I on the top-level project node, pick ‘All Configurations’ and ‘Build Locations’ and change the ‘Precompiled Headers Cache Path’ to something relative to the project. Presto, no more branch-hopping PCH issues. Once again the default XCode setup really doesn’t like to play with multi-branch development practices, something that can confuse otherwise experienced developers who are new to the tool. Well, it confused me briefly anyway

Ok, so despite not getting a great deal of useful advice on the Apple developer forums about the framework issues I’d encountered, through reading, thinking and discussions with Justin I’ve now changed the Ogre build setup so that it copes with both multiple versions, debug and release configurations and eliminates the issues surrounding where to install frameworks.

The answer was basically pretty simple. Whilst frameworks would lead you to think of Linux centrally located shared libraries on steroids, what with the ability to be Universal (PPC and x86 compatible), in fact in practice they are much better used like the local shared libraries you would use on Windows apps. Whilst frameworks can contain multiple major versions in one central place, which would lead you to believe that that’s how you should try to use them, in practice for an app developer, trying to put things in /Library/Frameworks is a nightmare. For many reasons:

1. Permissions - the easy one
2. Versioning - the fact that XCode doesn’t easily allow you to choose what version you link to
3. Configuration - you can’t have debug and release versions installed at the same time
4. Installation - it breaks the ‘drag & drop install’ idiom

So, as of the latest CVS, which will become 1.4.5, we’ve dropped the idea of using a shared framework location, and instead frameworks will be assumed to be contained within the application - ie under Foo.app/Contents/Frameworks. In order to resolve the issue that in our samples it would result in frameworks being duplicated a huge number of times, we now use a Run Script phase in the build to symlink frameworks into these locations rather than using the traditional Copy Files build phase. Obviously this won’t work if you then copy the app somewhere else (without also moving the frameworks relative to it) so when making a real deployable application you would obviously use a genuine copy. Because everything is local it also makes simultaneous debug & release configurations easy to support.

So the end result was quite straight forward, albeit rather unintuitive when you read up on the features of Frameworks, which really lead you away from this solution towards a centralised approach, with the way they are presented. Nevertheless, when you look at some other applications, you clearly see that containment is the ‘normal’ way of doing it - yes it means that you duplicate libraries all over the place in the file system if you use several apps that use a single framework, but it’s the only way to get that self-contained, drag & drop application setup that solves all of the issues from UI consistency to version choice and debug/release configuration.

If you update from CVS branch ‘v1-4′ now you’ll get the changes. There’s also a new dependencies package on the Sourceforge page which reorganises where the dependency frameworks go. You’ll need to remove Ogre.framework and the dependency frameworks like Cg.framework from /Library/Frameworks since they now live locally in ogrenew/Dependencies.

Oh, and here’s an odd thing I discovered. If you change the path to an existing external framework in XCode (rather than deleting and re-adding it), make sure you open the Get Info panel on it, and uncheck and recheck the boxes next to the targets using it. If you don’t, you seem to get inexplicable linker errors saying it can’t find the framework - probably a dirty flag issue or something. Puzzled me for a little while anyway.

One of the unfortunate things about Mac OS X is that graphics driver support lags behind other platforms. Drivers are bundled with OS X system updates rather than being updated separately and occasionally there are bugs which take longer to get resolved on OS X than on other platforms as a result.

We’ve had this problem before, and we appear to have got it again now. In our example media, we have some hardware skinning shaders written in GLSL; we also have Cg and HLSL versions, but the GLSL version is there to prove certain features such as passing arrays of uniforms - bone matrices - to GLSL. Works fine everywhere I’d tried it, but I did notice that on OS X our skeletal animation demo runs like a pig, and yet it runs perfectly fine on Vista on the same hardware when using GL.

I’ve got a lot of things on my plate so I hadn’t looked into it much yet, but hellcatv picked up on it in the forums recently. Luckily it appears he’s got an Apple support contract or at least better contacts than me (Apple don’t answer tech support without a contract or per-incident fee, and my posts so far to the public Apple developer forums have remained mostly unanswered) so we managed to get to the bottom of it.

The issue is to do with ‘aliasing’ of vertex attributes - that is, two different vertex components accidentally sharing a single attribute number. Skeletal animation requires the use of extended attributes, at least if you don’t want to burn texture coordinates pointlessly on it. Ogre recognises certain attributes in GLSL shaders such as ‘tangent’, ‘binormal’, ‘blendWeights’ and ‘blendIndices’ and automatically hooks them up to those semantics as passed through our geometry format (for those who don’t know, our geometry format is completely flexible and described by a declaration in which you link up buffer offsets and buffer ids to a ’semantic’ to indicate how vertex data should be interpreted). These attributes don’t have fixed ids, GL lets you bind custom attributes to any number; but we don’t assume here, we compile and link the GLSL and ask the GL runtime what it’s assigned the custom attributes to. And herein lies the problem.

In theory, attributes can be assigned any ID, even the builtin attributes like gl_Vertex and gl_Normal. However, in practice many manufacturers make the builtins refer to fixed IDs all the time and don’t like you to try to change that or override them with custom attributes. Thus, for example gl_Normal is usually attribute #2, so you’d better not use gl_Normal in your shader and also bind a custom attribute to #2, otherwise you get ‘attribute aliasing’ which drags performance into the gutter. We avoid making any assumptions here and after compiling and linking the GLSL, we ask GL what the attribute numbers are.

On Windows and Linux, if you’ve used gl_Vertex (attrib 0) and gl_Normal (attrib 2) and 2 custom attributes (blend weights and blend indexes), the custom attributes come back from the GLSL compiler as #1 and #3 respectively. Obviously it’s worked out that it can’t use #2 because it’s being used by gl_Normal. If you don’t refer to gl_Normal in your shader, #2 is used.

On Apple however, it appears that the custom attributes are bound to #1 and #2 even if you’re referring to gl_Normal. This immediately causes attribute aliasing and hence the performance drop. Apple initially said they thought we were causing this, but after clarifying what we do and why I think it’s correct (and works on other drivers), Apple have now indicated that "We are working to resolve this bug in future updates.".

Hopefully this gets fixed soon. One possible work around is to change our code so that we pick fixed, very high numbered attributes that are always out of the way instead of asking the GLSL compiler to tell us what to use. This isn’t as elegant though, so I’d prefer to wait to see if Apple fix their driver in the short term. Interestingly the same problem occurs on ATI and nvidia so it might be a mistake in some shared implementation perhaps.

It’s a shame - games like Bioshock get driver updates specifically for them, as did iD’s games beforehand - I remember how many GL driver issues we had when using new extensions iD hadn’t in their games, stuff that I’m sure would have gotten fixed much quicker if iD had been releasing a game using them. The rest of us, having a much lower profile, have to just cross our fingers and hope it won’t be too long.

As I’ve blogged before, I’ve spent a fair amount of my spare time recently getting to know OS X development, and one thing I’ve wanted to do is get an automated SDK build going for before the next release goes out. Annoyances with the organisation of framework versions, and issues with driving PackageManager from the command line have all frustrated those efforts, but nevertheless I’ve made progress. Today, however, despite having a mostly working installer I decided to change tack completely and drop PackageManager in favour of a disk image (dmg) instead:

The reasons for deciding to do this are numerous. Firstly, the issues with framework versioning in a build environment have basically meant that the only way to do this reliably is to contain everything in a single folder anyway, so that all the references are local, rather than using multiple framework versions in one central location. This means that PackageManager’s ability to install different things in different locations (central and per-user) became useless. Having a global framework system just doesn’t work for development when version selection is non-existent. Secondly,  for some incredibly bizarre reason PackageManager is totally incapable of defaulting the install location to anywhere derived from the users home directory - the only way to do it is to install somewhere else and copy, which is messy, especially if you want the user to have a choice of install location, which I do. Finally, and perhaps most importantly, I’ve experienced more app distributions now and now realise that installers aren’t en vogue in OS X like they are in Windows - DMGs rule (here’s a selection - yeah I know mine isn’t as pretty but I don’t have that much time :)).

For those who don’t know, DMGs are just ‘pretend’ disks / volumes. They can be read / write or read-only and can be compressed and encrypted if you want. OS X uses them as containers for burning DVDs and distributing software among other things, they’re very flexible. As a software distribution mechanism, they gel with the OS X ‘drag and drop install’ idiom whilst at the same time being more elegant than a simple .tar.bz2 archive. So generally, they’re a good thing.

Creating the ‘look’ is as simple as creating a base disk image using Disk Utility (or the command line version ‘hdiutil’, more on that in a sec), mounting it and playing with the appearance in Finder (just make sure the view opions are set to just this folder). Any changes you make are preserved in the image next time you mount it. This becomes your ‘template’ DMG that you can populate with content with the SDK script.

To mount, update and finally write and compress a DMG from the command line is pretty easy. To start with, we have to mount the template image we created by hand (you probably want to bzip2 this image for storage in source control):

mkdir tmp_dmg
cp template.dmg workingcopy.dmg
hdiutil attach workingcopy.dmg -noautoopen -quiet -mountpoint tmp_dmg

Copy whatever you want into the mounted location tmp_dmg, then you’re ready to finish up. Firstly, you want to make sure that when the user double-clicks on the dmg that it not only mounts, but automatically opens that nice folder you designed. The ‘bless’ command does this:

bless -folder tmp_dmg -openfolder tmp_dmg

Finally, you want to unmount the image and compress it.

hdiutil detach tmp_dmg
hdiutil convert -format UDBZ  -o OgreSDK_$OGRE_VERSION.dmg workingcopy.dmg
rm -rf tmp_dmg
rm workingcopy.dmg

That’s it! The -format UDBZ tells hdiutil to BZip the image so it’s nice and compact, ready for uploading. Seems to work pretty well. I have a few loose ends to tidy up like writing a new ReadMe but otherwise I think I’m done, so should be able to release the next version in a few days.

Much as I love using OSX now, I still miss my Windows development tools. Even though I’ve gotten used to using XCode and related tools now, they still have multiple limitations that really annoy me when I’m trying to get things done.

I mentioned a little while back that I’ve wrestled with Framework versioning and debug / release configurations. I’m not much closer to solving those in any way I feel is elegant, or even adequate. XCode seemingly just doesn’t want you to develop against more than one version or build configuration of a Framework, and if you do, you have to bend over backwards to make it work.  In terms of versioning, I’ve reorganised the build setup on OSX now so that both the Ogre framework and Samples share a build location, which allows me to make the framework reference in the Samples relative to the build location, so the Samples project at least can now build independently. I plan on bumping the major version of the Framework in Shoggoth soon so that at runtime, both can co-exist. This solves the problem for the samples, but doesn’t solve it for any other project. For those, I suggest referencing the Framework ‘Relative to Project’ or even ‘Absolute Path’ to ensure they build against the right version.

Debug and release isn’t solved though. Whilst some core Frameworks have debug versions with a _debug suffix akin to using the _d suffix on other platforms, there isn’t a nice way to set up XCode to produce or consume that per build configuration. I.e. it would seem sensible to tell XCode to append _debug to the framework name only in the Debug build configuration - but you can’t. It would also be sensible to tell XCode to look for _debug suffixes when consuming Frameworks only in Debug builds, but you can’t - you can only do it globally. Also, when using many external frameworks you may only want / be able to use debug frameworks for some of those; but again XCode only allows you to tell it to look for the _debug suffix globally. How bloody stupid is that? I can’t help but think that no-one at Apple has really thought this through, since this is incredibly basic build managment stuff.

So, pretty annoying. I’ve been working with PackageMaker recently to get an SDK built for OSX, and have been scripting it so it’s all automated. That went fine for creating the individual packages for components (as you have to do to install things in different locations), but when I came to build the distribution package which wraps them all, it worked fine in the GUI but from the command-line it just fell over. Some hunting in the Apple mailing lists revealed that PackageMaker doesn’t like building distribution packages via the /Developer/Tools/packagemaker alias, you have to use the full /Developer/Applications/Utilities/PackageMaker.app/Contents/MacOS/PackageMaker path to avoid it crashing - depite the alias working fine for individual packages. Odd, but sure enough that got me past the crash. But then I found that it wasn’t referencing my single packages properly - it gave me a ‘missing size field for <blah>’ for every package and the install fails. More hunting on the Apple mailing lists revealed that PackageManager also can’t handle relative paths when building a distribution package from the command line, you have to use absolute paths. Which is completely useless as I need this to be location independent. Grrr. So now my plan is to set it to absolute and then script a text replacement to the project file before firing it off, to see if that works. Really shouldn’t have to, this is an obvious bug.

It’s nice of Apple to give us free developer tools like this, but by God do they have some nasty rough edges. Here’s hoping that XCode 3 and related tools cleans some of this stuff up.

Ok, so I’m much more comfortable with XCode than I was to start with. It’s still pretty weird and I personally prefer the way other tools like MSVC organise themselves in terms of project structure and settings, but I can live with it - just. There is, however, one issue which is breaking my balls and I can’t seem to solve it - that is, managing multiple major versions of a framework effectively.

Ogre always has (at least) 2 major versions on the go at any one time, the development version and the stable version. Both will be being updated, but one will have interface breaking changes and the other just bugfixes. Very simple. Now, OS X Frameworks have the ability to store multiple major versions within them, which at first glance seems perfect for my needs.

However, when it comes to referencing frameworks in XCode, you don’t have the option to pick what version of a framework you reference. You can only pick the top-level framework, and it seems that it insists on following the ‘Current’ link to the version which is presently set as the current version when linking. Software built against previous versions presumably still runtime links against the older versions, but at build time you have no choice. So they assume that you only ever want to build against the very latest version of a framework, which totally sucks because I definitely do not. I have 2 versions on the go at all times, at least. Add to that that you can only have one of debug or release builds installed at any one time, and this becomes an organisational nightmare.

I figure I can do something like this: when I switch between versions, and when I switch between debug and release builds, I can flip over the ‘Current’ version link using a ‘ln -s’ to the version I’m currently wanting to build with. Similarly, if I want to flip between debug and release builds I’ll have to copy the appropriate build output from the folder into the /Library/Frameworks. But, this is particularly clunky and error prone. I’ve been hunting around in XCode looking for a ‘reference version X of framework’ option in the external framework link but I can’t see it. The documentation doesn’t even offer any kind of advice on managing multiple versions of a framework, it only pays lip service to the fact there can be multiple major versions, not how to actually organise them. Come on, doesn’t everyone do this? Or does everyone making Mac software only maintain 1 version of everything??

Debug / release builds are poorly managed too - I’m used to being able to link against debug and release whenever I want, but with XCode all I can do is link against whatever is currently built & installed in /Library/Frameworks. In multi-project, multi-library situations that really sucks. I don’t want to have to script the replacement of all frameworks my app references with debug or release versions depending on what I want to run at a particular time. Justin mentioned there might be a way to reference the XCode project instead of the framework to get XCode to do this better, but I couldn’t locate any information on this and my experiments with it failed. The core frameworks use what they call an ‘Umbrella framework’ to allow both debug and release versions to be installed at once, but the docs then strongly advise you not to try to do that for user created frameworks because of more gotchas. Grr.

So now I’m used to the XCode environment, I’m getting really, really annoyed with the logistical set up of the library system. Am I just missing something or is it really this retarded?