Xcode 8 notes

Just installed Xcode 8. Let's see what Apple have in store. Nervous about installing Xcode as anything pre 7.x was a patchy. The 4-5 series were just alphas and should never have replaced 3.x.

First thing noticed, the font has changed! Ok, we'll roll with that. GUI looks largely the same. Try some editing: comment in/out shortcut not working.

Fixing comment shortcut

Other users having same problem in the betas. Fix kudos to Chris Hanson from Twitter. From terminal:

sudo /use/libexec/xpccachectl

And you have to restart your Mac. Just log out/in won't work.

I think plug-ins are used in Xcode 8. XPC appears to be an IPC protocol, part of Grand Dispatch. So I guess this is how the plug-ins talk to Xcode. Ok so that looks fixed.

Still no column display

For something that claims to be a source code editor, it is pretty strange that the column number isn't displayed anywhere. You can get line number from the sidebar, but not column, which is useful for commenting and layout. Will update issue ticket for this.

MacPorts notes

Some notes on use MacPorts on the Mac.

Usage

Packages

Find new packages:

port search name 

 Find what is currently installed:

port installed  

Maintenance

Upgrade existing MacPorts database:

port self update 

Update outdated packages (e.g. after database update):

port upgrade outdated 

Remove old packages (e.g. after updating outdated):

port uninstall inactive

Clean up to save disc space ("du -hs /opt" to find existing usage before and after):

port clean installed

Mac terminal replacement - iTerm

If you ever use the command-line on the Mac, the default system terminal works, but having colour syntax highlighting and better presentation makes things a lot easier to read.

An alternative is iTerm:

iTerm history: Version 0.10 iTerm still works if you want simpler version. This was mothballed when the lead developer became a brain surgeon! (almost). It has been patched for OSX Lion. iTerm2 is still under active development. You can also get it with tmux support (but I don't use this).

Xcode 4.3 Complaints!

Just downloaded and trying Xcode 4.3.1. Quite frankly, after 4.0 and 4.1 I gave up and went back to Xcode 3.2.6. I'm sure this has been said in other places, but I think Apple have deprecated Xcode 3 too quickly and moved to something which was at best alpha quality (4.0), and is now beta quality (4.2+). That said, Xcode 4.3 does have a more "solid" feel about it.

Other people also have taken issue.

My issues with Xcode 4.3 are:

Key maps

The keys still clash with system defaults. I like Command+N for swapping desktops. Single-step etc clash with functions on laptop keys. Why not add the Xcode 3 mappings as an option? Why did you need to change them? You can use the Xcode 3 keys on a laptop or desktop keyboard quite happily. And not having to remember a whole new set of keys is a big win.

Editor

Simple things, like, which column am I in? Where is this displayed? This is basic stuff for a code editor.

How do I compile a single file? Seriously. Come on.

UI

You cannot drag any of the side panels around. What about making the sidebar items (project browser, objects, errors, etc) dockable/moveable so that you could have some on the right? E.g. file browsing on left, but then error list on the right. Or top and bottom of the sidebar? Should remember layout between sessions. Same for debugger features. -- If you have used Eclipse then there are lots of solutions and alternatives with a more flexible approach like that.

This is more of a minor one, but the toolbar at the top occupies too much space. It hardly displays anything. Maybe merge it into the title bar? Make icons smaller?

Top toolbar takes up too much space.

Version Control

I haven't really used these features because I use Mercurial. It's just what I use. Why not add Mercurial support, it is not going anywhere. It is a good DVCS. You have also removed Perforce support, please re-add.


Summary

Apple: I haven't used all of the features of Xcode 4, and I'm not a full time Apple dev. I know Microsoft are making Visual Studio worse, but do you have to try and compete with them? Xcode could be so much better if you didn't try and change everything at once. Leave the Xcode 3 key maps. At least then people can turn a blind eye to the other shortcomings of the IDE. I'm sure in a year or two it will be a better IDE, but right now please address the day-to-day usage issues instead of trying to cram in more functionality.

Notes on using Allegro 5.1 on Mac

This is some notes I made whilst setting up Allegro for use on my Mac. I'm fairly new to Mac, having been a Windows programmer for a long time, so these notes may change as I learn more about the correct way to do things on the Mac.

Dependencies

Get all the libraries and tools that Allegro5 needs from Macport. This saves a lot of time. Very nice system. You can check what you have installed using:

port installed

You will need the following:

sudo port install zlib freetype jpeg libogg libvorbis libpng physfs +universal

If you have libraries installed that aren't 32 bit, and you get the "different system not i386" link error, they need to be recompiled with "+universal" (i.e. i386 and x86_64) . i386 is needed by the iPhone simulator. OSX desktop apps will use x86_64. You can force MacPorts to recompile any libraries using the following (and replace LIBNAME!):

sudo port upgrade --enforce-variants LIBNAME +universal

cmake should have been installed by MacPorts, but if not:

sudo port install cmake

Note: you will need at least version 2.8.8 of cmake if you are using Xcode 4.3 or newer.

Build 

make

Easiest way to build and install Allegro for OSX is use make. Get the Allegro source and in that directory:

• mkdir build
• cd build
• cmake ..
• make
• sudo make install

Add "-D WANT_FRAMEWORKS=1" to cmake if you want frameworks.

Add "-D CMAKE_OSX_ARCHITECTURES=i386" if you want 32 bit libs. - I had to do this initially, I think because some of the ports wouldn't compile 64 bit. No longer necessary.

I don't use frameworks. Default install directory is "/usr/local".

Xcode

You can generate Xcode project files for Allegro and build using Xcode. I do two builds of Allegro. One for OSX and for iOS.

• mkdir build_osx
• cd build_osx
• cmake -D SHARED=0 -G Xcode ..
• xcodebuild -project ALLEGRO.xcodeproj -target ALL_BUILD -arch x86_64 -sdk macosx10.7 -configuration Release
• cmake -D CMAKE_INSTALL_PREFIX=/my/install/path -P cmake_install.cmake 

I turn sharing off so I get static libs. You'll need to do this for iOS as dynamic libs aren't allowed.

Using

Don't use Xcode 4.0, it isn't ready. Use Xcode 4.1 or Xcode 3.2. Xcode 4.3 seems okay, still needs work. Stick with Xcode 3.2 if you like, I do on my laptop.

I create a Cocoa application and removed what I didn't want. If you followed make build instructions:

• Add "/usr/local/include" to header search paths.
• Drag in the Allegro libraries that you want to link to in "/usr/local/lib".
• Go into Interface Builder and delete the default Application and Window. Allegro supplies these.

Linking

The frameworks you need to for OSX are:

• AudioToolbox
• IOKit
• OpenAL
• OpenGL
• Cocoa

The frameworks you need to for iOS are:

• CoreGraphics
• Foundation
• OpenAL
• OpenGLES
• QuartzCore
• UIKit

The following error means you have the wrong "main" declaration:

dyld: Symbol not found: __al_mangled_main
Referenced from: /usr/local/lib/liballegro_main.5.1.dylib
Expected in: flat namespace
in /usr/local/lib/liballegro_main.5.1.dylib

It should be:

int main(int argc, char **argv) 

Other Info

There are other notes on the Allegro wiki on how to build Allegro from Git.


[16-Jul-11] Note about Xcode 4.0.
[27-Oct-11] Xcode 4.1 is fine. It doesn't crash and is faster than Xcode 3.2.
[Mar-12] Xcode 4.3. Compile 64-bit.
[29-Mar-12] Added +universal to "port install" so we get i386 and x86_64 libraries. I also updated the notes on the Allegro wiki.
[8-Jul-12] Added frameworks to link for Allegro 5.1.
[19-Dec-12] Notes on Xcode building.

iMac 2011 Buying Decision

This is not a full review of the iMac 2011 refresh, rather some comments on my decision making process for buying one.

There are no cosmetic changes, just a bump in spec, although the increase in power looks quite impressive, especially in the high end 27" iMac's graphics.

New features are:

• Thunderbolt - high speed video/data connect. Peripherals won't be cheap. :(
• "iMac displays feature "in-plane switching," or IPS. Originally designed by Hitachi in 1996, IPS improves color and contrast at sharp viewing angles." (source)

Things improved:

• CPU (faster).
• GPU (faster).
• Camera (quality).
• Screen (quality).

CPU

All of the iMacs are now quad-core (i.e. i5). The higher models can be bumped up to i7, which has hyper-threading (i.e. 8 hardware threads on 4 cores, 2 on each).

This thread contains lots of information comparing the 2010 and 2011 models.

Comparison of iMac 2011 processors.

The i7 3.4 Ghz vs i5 3.1 GHz appears to be (from CPU performance comparison, not real world):

•  ~25% faster transcoding in Handbrake.
• ~10% faster at Photoshop.
• ~10% faster at image rendering in 3DS Max 2010.

The i7 is £160 extra in the 27" top model. So it's about a 10% increase in price (of the whole iMac) for ~10% increase in performance. If you do a lot of video transcoding then it's a ~25% increase in performance for 10% extra, which looks like better value for money.

Initial Benchmarks

Initial iTechVision initial Geekbench tests:

• Geekbench:
• i7 3.4 Ghz in 32 bit OSX: ~11750, in 64 bit OSX: ~12700 (8% increase).
• i5 3.1 Ghz in 32 bit OSX: ~8400 (~71% of i7). Approx 9500 if 13% increase.
• i7 ~20% faster than MBPs with i7.
• i7 the same performance as MPs from 2009-10.
• For comparison (32/64 bit) from Mac Geekbench:
• MacBook Pro (13-inch Mid 2009) Intel Core 2 Duo P8700 2.53 GHz (2 cores) = 3510/3851.
• MacBook Pro (17-inch Early 2011) Intel Core i7-2820QM 2.3 GHz (4 cores) = 10383/11179.
• iMac (27-inch Mid 2010) Intel Core i5 680 3.6 GHz (2 cores) = 6829/7745.
• iMac (27-inch Late 2009) Intel Core i7 860 2.8 GHz (4 cores) = 8328/9712.
• iMac (27-inch Mid 2010) Intel Core i7 870 2.93 GHz (4 cores) = 9122/10544.
• Mac Pro (Mid 2010) Intel Xeon E5620 2.4 GHz (8 cores) = 12722/14083.
• i5 3.1 GHz is:
•  same performance as i7 2.93 Ghz from last year.
• ~86% the performance of MacPro Xeon 3.33 Ghz 2010: 6 core and costs £3400!

The difference between 32 and 64 bit OS appears to be around 8-9% on Macbook Pros and around 12-15% on iMacs.

Graphics

There appear to be some people who are discontent that Apple uses mobile graphics devices in their iMacs, but this has always been the case. Some modern graphics cards make stupid amounts of noise, and if you are editing music, or trying to concentrate then it can be very off putting. The mobile cards create far less heat, and therefore need less cooling, and are quieter.

This table shows the previous graphics cards used in iMacs:

Comparison of past and present iMac graphics cards.

The Radeon HD 6970M, in the high end 27" iMac has a much higher spec than the other cards, and appears to be about 70% faster than the HD 6770M found in the lower spec iMac. There is £250 difference between the two models (which also includes a faster processor and more VRAM on the graphics card). The HD 6990M card can also be upgraded to 2 GB VRAM for £80.

HD 6970M
This review compares the Radeon HD 6950 1 GB and 2 GB models, and the GeForce GTX 560 Ti. This is interesting because the iMac uses the HD 6970M and has 1 and 2 GB options. The review is not for the mobile version (i.e. the 6950M) but it does show what effect adding VRAM has. The conclusion is that adding VRAM doesn't necessarily speed up the framerate, but it does allow higher quality AA and higher screen resolutions (and the iMac has a massive screen!). The HD 6970 looks to be about 10% more powerful than the 6950.

RAM

Apple's RAM costs are very expensive. I don't know how they justify it. The iMacs come with 4GB of RAM. This comes as 2 x 2GB sticks, which live in 2 of 4 slots, so more can be added easily and cheaply from a third party.

• RAM specification from Apple.
• 4GB supplied.
• Maximum possible: 16GB (4GB in each slot).
• 2 or 4 GB may be used in each slot.
• Apple price:
• 8 GB (2x4) = £160.
• 16 GB (4x4) = £480.
• This is for 2010 iMac, but if prices are similar, options are:
• 6 GB (2x2 + 2) = £17 (inc VAT).
• 8 GB (2x2 + 4) = £34.
• 12 GB (2x2 + 2x4) = £67.
• 16 GB (4x4) = £134. Possibly get money from selling 2x2 GB.

Price Comparison

Apple are often accused of ripping their customers off. And whilst I find it really hard to see how they charge so much for RAM, bigger hard drives and SSD, the basic packages do seem quite competitive. Often, systems that are compared just aren't of the same quality. They have poorly quality screens or make loads noise, or aren't as powerful in one area.

If you look on the Dell site, at their high end gaming rigs, a roughly equivalent spec looks to be the Alienware Aurora i7-2600. It is £1300 (with £230 off). A 27" monitor, the U2711, is £839. So that totals ~£2140. This is also doesn't include software like iLife. The top end iMac is £1889 with i7 and 2GB VRAM.


Conclusion

The extra £250 to jump from the lower to the higher spec 27" iMac is worth it for the extra graphics performance, plus the faster processor.

The extra £160 for the i7 also looks quite good value if you look at the benchmarks. Superficially (according to Geekbench) it looks like you get 37% increase in power for around a 10% increase in price. Of course not all applications will get this full benefit, but you do get a faster processor and most things will run at least 10% faster.

It is also worth investing in some more RAM. Using Apple RAM is ludicrously expensive. Buy the base spec and upgrade later from a third party. 4 GB is plenty for casual use. 8-12 GB is useful for audio/video editing and multi-tasking.

For me, I'd like to play games, program, and have the computer for some time, so I think I'll go for i7 and the 2GB of VRAM option. Games are always using more VRAM, and it might be used for GPU processing. If you don't play games then you probably won't need the 2GB of VRAM. And if you don't edit video then the i5 might be good enough for you. It is still a really powerful machine.

Afterthoughts

[9-July-11] I've since bought my Mac and am very happy with the nice big screen. It is a beast as well, incredibly fast. I noticed it was a little sluggish at first, but I think this is because the CPU/motherboard is so fast that any disc access seems very slow (including any virtual memory swapping) in comparison.

I upgraded to 12GB (Crucial 2x4GB sticks + the existing 2x2GB) and this really speeds things up. Aperture was almost unusable before, but is lightening fast now. I decided not to get an internal SSD, but I can now see why you'd want one.

I am also very happy (so far) with the gaming performance. The GPU performance was worth waiting for as I think previous 27" iMacs were slightly underpowered. All the games I have tried so far run at maximum settings (everything on max/ultra), at maximum resolution without any lag at all. The CPU barely breaks into a jog as well. Starcraft 2 and Settlers 7 both have no problems at all. Looking forward to id Rage.

[4-May-11] Added initial Geekbench test results from (shop bought?) iMac i5 3.1 GHz.
[4-May-11] Added details on gfx performance and 2GB VRAM upgrade.
[9-May-11] Updated conclusion after reading more benchmarks. Added Dell comparison.
[9-July-11] Added afterthoughts.

Starcraft 2 hang on Mac 10.6.5 fix

Been playing a lot of Starcraft 2 lately. Great game, and works okay on Macbook Pro (on low settings). Just upgraded OSX to 10.6.5 and started getting the game freezing up on the login screen. I think Apple have been doing some driver optimisation work.

You can fix this by restarting your Mac in safe mode. (23-Jan-10: There is an Apple help page). You do this by restarting your machine and holding down the shift key whilst it restarts (i.e. from power on). This apparently clears out the OS caches. This takes about 5-10 minutes and you'll see a grey loading bar under the apple on the white loading screen. Once you've got into OSX just restart your machine again (in normal mode) and everything should be fine.

You'll notice that the game is considerably faster now. Quite why the graphics drivers have been so bad for so long would be an interesting question for Apple. I can now run at full res on my second monitor and with medium texture settings. I tried medium settings for everything but the framerate was awful. It is a big visual improvement over everything on low previously.

21-Nov-2010: Another thing you might try, after restarting in safe mode, if you are still having issues, is to run the Starcarft 2 "Repair" application. You can find this in the directory: Applications/Starcraft II/Support. Not sure what this does entirely, but it should ensure that everything is up to date and correct.

(23-Jan-2010: Added link to Apple safe mode help. Thanks "Anonymous"!)

ClanLib 2.2 on Mac OSX 10.6

These are just some notes on building the new version of ClanLib, 2.2, on Snow Leopard. The XCode version of ClanLib using frameworks is pretty broken and hasn't been maintained in some time. It also doesn't look the developers will fix this any time soon. To quote some of the issues:

[...] The 0.9 code base is partly based on 0.8 which already had Mac support, so most of the module are trivial to fix into compiling again. The main porting issue is clanDisplay+clanGL where the window management and AGL context management code needs to be updated. Most of that can once again be taken from 0.8 and updated from that point forward (the code might even already be in 0.9 in a broken state - haven't checked), but you might also just find it easier to rewrite parts of that platform specific code.

In general the code in ClanLib is very modular in the sense that the Win32, X11 and OSX code is usually cleanly separated so porting is mostly just a matter of finding the equivalent OS X functions. Unfortunately when I originally did the OS X port, I mainly relied on the Carbon API mixed with some posix stuff (pthreads mainly) and I hear Apple removed support for Carbon in 64 bit OS X. Having virtually no experience with Objective C or Cocoa I do not know how difficult it is to switch to the equivalent Cocoa functions.

One last issue regarding OS X support is that I personally rely on a simple program called scan.cpp that reside in the Setup/OSX directory which generates a makefile for my purposes. The reason I bring this up is because that while there exist a XCode project, it is currently out of date. It is probably just a matter of bringing the source files into sync to get that project back and operational, but I am personally so allergic to the IDE of XCode that I reverted back to my makefile generator when I ported clanCore and clanNetwork to Mac in 0.9. You are naturally free to fix this project (which officially is the way we tell users to build 0.8 for Mac), but I will have to stay on the makefile myself simply because Apple changed the XCode project file format and my ancient G4 Powerbook with OS X 10.3.9 on it cannot read it after you update it. [source]

And:

I forgot to mention that we will naturally gladly update the framework bundles for any dependency library used by ClanLib. The only problem is that I somewhat forgot how we built them and at least at the time the documentation on library framework bundles provided by Apple was somewhat limited.

Since I do not know how much experience you have with building framework bundles I'll just tell you what I know and hopefully you can use that for something. 

Technically a library framework bundle is simply a normal dynamic library arranged in a certain directory structure (just like application bundles are just directories). In traditional unix environments (BSD, linux, etc.) the include files are placed in /usr/include/ClanLib-0.9 and the dynamic libraries in /usr/lib. But for a framework library those same files are placed in ~/Library/Frameworks/LibraryName/Headers and ~/Library/Frameworks/LibraryName/LibraryName.

To port any library to an OS X library bundle is therefore a "simple" task of simply taking the header files and the output dynamic library and place them in this directory structure. Unfortunately it seems the linker in OS X is rather dumb (at least in 10.3) and requires the dynamic library file to built directly into this directory structure. If you want more details on how to do this manually outside XCode, try take a look at the scan.cpp program that came with ClanLib.

An easier option may be to simply recreate the makefile for the dependency library in XCode. Using this strategy will ensure that the framework bundle is at least correctly built, but great care must be taken to ensure that it is the same source files and defines that are used for the build. I think the current framework bundles available on the website were built using this strategy.

Finally we might be lucky that someone else already did create an OS X framework bundle for some of our dependency libraries. Googling for that first wouldn't hurt. [same source as above]

make

There are a few compilation errors with ClanLib 2.2 out of the box for Mac since it hasn't been maintained in a while. Anything inside #ifdef __APPLE__ is a little stale. Also, as stated, there is no support for certain features, like joystick input.

XCode Project

To fix the Mac issues, the easiest way (for me anyway) is to fix the XCode project. Source code is checked into the Gameres project. Also, on the Mac it seems that OpenGL is only supported via a framework, and I'd like to use OpenGL.

Dependencies are as follows. Apologies if I make any mistakes, these are vague notes from my install. We need to make everything 32-bit as ClanLib is 32-bit (like Allegro). So when you compile the following libraries do:

• ./configure CFLAGS="-arch i386"
• make
• sudo make install
• make clean

Libraries required by ClanLib. You can get these from the download page (in case you need binaries of the same versions).

• libxml2: This is the XML library used by fontconfig. You'll have make this from source as the precompiled Mac binaries install as a framework.
• fontconfig: I installed version 2.8.0. This required libxml2.
• freetype2: I got version 2.4.1 of this font library.
• libpng: I have version 1.4.3 of the PNG library. There seem to be some serious bugs with earlier versions so make sure you have 1.4.3 or later.
• libjpeg: I got JPEG library version 8b (of 16-May-2010).
• pcre: Regular expression library version 8.10.

Now, if installed at the default location, you should have some includes and libraries in /usr/local. I may add the binaries to Gameres at some point.

After a few hours work I managed to fix up the project and get it compiling and linking. It is currently untested and no doubt missing features.

Using Allegro 4.4 on Mac

Building

I have Macbook with Snow Leopard 10.6.2 installed and Allegro 4.4.1.1. I did have some hiccups with Allegro 4.4.0.1. Not sure if this was my fault or the distro as I'm still newish to the Mac and the Allegro Mac instructions are a bit dated.

I first tried building Allegro as a framework, but this doesn't work as I think it should. If you include a framework using: #include "Allegro/allegro.h", the internal Allegro files don't prefix with the framework name "Allegro". So, you end up adding the framework path, which is pointless, so you may as well just compile Allegro in /usr/local and link it from there.

Get Allegro (I used 4.4.1.1). Unzip. I have cmake 2.8. In the Allegro directory :-

• mkdir build
• cd build
• cmake ..
• sudo make install
• make clean

Dependencies:

• OpenGL - included in OS.
• libpng, zlib and vorbis - These can be downloaded and installed as standard libs in /usr/local. I don't bother with fink or Macports as I don't want the clutter. I want everything to work "natively". There are some details under the pygame build instructions.

So you should now have a working copy of Allego in /usr/local/include and /usr/local/lib, with some executable utilities in /usr/local/bin.

From the mailing list it appears that you can only compile Allegro as a 32 bit library, there is no 64 bit support so any libraries or frameworks and the dependent libraries will have to be 32 bit. Leopard default is 32 bit. Snow Leopard default is 64 bit.

Creating project in Xcode

• Create a new command-line C++ tool project.
• Paste in the GL example.
• Add /usr/local/include to the header search paths in project settings.
• Add the following frameworks to "Link with Binary Libraries" :
• Cocoa.
• OpenGL.
• Carbon. (Ideally you shouldn't need this, but there is some reference to ShowMenuBar and HideMenuBar, which doesn't appear when you build Allegro as a framework.)
• Add the following libraries from /usr/local/lib :
• liballeg.4.4.dylib
• liballeggl.a
• liballeg-main.a  (This is a stub for "main" that glues Cocoa to Allegro.)
• Build the target and it should compile and link.
• You are now good to go at writing OpenGL games using Allegro.

[8-Apr-10] Changed because building as framework just doesn't work properly.

Clanlib vs Allegro vs SDL on Mac OSX

I want to write a little game in C++. Previously, on Windows, I've used Clanlib. This is nicely designed and has pretty much all you need for a game. However, I now have a Macbook (OSX 10.6.2) and Clanlib has fallen behind the times Mac-wise as it still uses Carbon. There don't seem to be any plans to port it and I don't have the experience or time to this work. So I had a look round at the alternatives (again!).

Clanlib 2.1

• Pretty mature, modern library with some nice features (e.g. slots and GUI support).
• Hardware acceleration through OpenGL or DirectX depending on platform.
• Windows and Linux are well supported but Mac has fallen behind, no Cocoa support.
• Version 2.0 was the previous 0.9 version; and 1.0 is the old 0.8 version, renamed. Version 1.0 compiles for the Mac but uses the 32-bit Carbon API. In Xcode 3.2.1 you can no longer create a Carbon project, it must be Cocoa; and if you want to do iPhone, this must definitely be the case.
• Xcode project files provided for Mac. Version 2 needs work.
• Licence: BSD.

SDL 1.2 / 1.3

• SDL is a well thought out low level library, but SDL libraries a bit scattered and some look unmaintained.
• Very portable and core well supported.
• OpenGL compatible.
• Uses Cocoa on Mac.
• Can be built as a framework. 
• Basic sprites don't support rotation.
• Licence for version 1.2:  LGPL.
• Licence for version 1.3: Dual licence, LGPL and commercial (closed source). On embedded platforms (e.g. iPhone) you have no choice but to buy a commercial licence or you are forced to go open source.

Allegro 4.4

• This is quite an old game library but seems to be well supported. Some of it is quite archaic, with palette support and support for old DOS compilers.
• Mac port uses Cocoa.
• API being reworked in Allegro 5.
• Can be built as a framework.
• Uses cmake to generate project files.
• Polling API.
• Minimal external dependencies (e.g. includes JPEG decoder).
• Licence: Giftware.

Allegro 5.1

• Allegro 5 been a long time in development, but worth the wait. Allegro had a lot of cruft from DOS and pre-graphic cards. The latest version is 5.1.
• The API is a lot more organised than 4.x. It is simple and elegant.
• The live version, straight from git (with build instructions) is available. Please note that whilst this contains new features and fixes, it also sometimes contains bugs (which happens during development). If you aren't comfortable with this use the latest stable release.
• OpenGL and DirectX renderers (hardware accelerated) by default.
• Event based API (i.e. not polling).
• Notes on building for Mac OSX.
• Licence: Giftware.
• (This was version 4.9 in the original comparison, which was a work-in-progress version of Allegro 5.0.)

Conclusion

I like the extra features that Clanlib and Allegro supply in their default libraries. Clanlib unfortunately uses Carbon on the Mac and Mac version not supported for long time. This is a real shame because Clanlib includes everything you need (including a GUI).

SDL provides extra features in libraries which I find a little scattered and iPhone development requires a commercial licence if you don't want to release your source code.

So as a result I decided on switching to Allegro 4.4, because unsure how mature 4.9 is, and generally Mac lags behind the main development platforms (Linux and Windows). I'll build my own API, hiding some of the the archaic nature of Allegro. I also decided on Allegro because I found the retro games site, which uses AllegroGL. :-)

I've now switched to Allegro 5. It is still a nice simple API, much improved and tidied up, and libraries updated for modern hardware. Works fine for OSX 10.6.  This is the best, simple cross platform (Windows, Linux, OSX) solution I have found.

[24-Jul-10] Updated because SDL 1.3 has now move to dual licence.
[25-Mar-11] Updated for Allegro 5.0. Removed notes on 4.9 as not useful.
[16-Jan-13] Updated notes on Allegro 5.1.

Building pygame on OSX Snow Leopard

The version of pygame available on the pygame site works for the python.org version of Python. I want one for the system Python (2.6.1 64-bit). I decided to revisit this after giving up (very easily) the first time.

• First, get pygame source. I'm trying with 1.9.1 release. This sounds like recipe now.
• Untar the source and python config.py reveals some dependencies are necessary. Config will show you which ones you have available.
• The pygame dependencies are as follows. So we'll need collect these. Notes follow.
• SDL.
• SDL_ttf  (fonts).
• SDL_image.
• SDL_mixer.
• smpeg.
• PNG.
• JPEG.
• SCRAP  (cross-platform clipboard).
• PortMIDI.

SDL

• There is a Mac SDL 1.2 package on the downloads page.
• I got SDL-1.2.14.dmg.
• Version 1.2.14 has Snow Leopard support according to the ReadMe.txt and is the minimum requirement. See notes below from UniversalBinaryNotes file:

64-bit Universal Binary Notes:

SDL 1.2.14 is our first release with Snow Leopard on the market. In order to make SDL compile and run in 64-bit, we had to remove code that depended on deprecated Mac APIs and move over to more modern Mac APIs.

In addition, Apple has stopped shipping gcc 3.3 and the 10.3 SDK.

Because of all these combined factors, we have made the decision to make Mac OS X 10.4 the new minimum requirement for SDL.

Our official SDL.framework is compiled as a 3-way Universal Binary (64-bit Intel, 32-bit Intel, 32-bit PowerPC.)

Certain APIs that SDL relies on were not made 64-bit ready by Apple until 10.6. This means even though 10.5 had preliminary 64-bit support, SDL will not compile or run correctly in 64-bit mode on 10.5. So there are two fallout items from this.

First, you can only compile 64-bit code on Snow Leopard or greater (which removes the possibility of 64-bit PowerPC). 

Second, this presents a corner-case where if you have a 64-bit Intel executable in your Universal binary and try to run on 10.5 on an 64-bit Intel Mac, it will launch and crash. To force 10.5 to use the 32-bit version instead of the 64-bit, you should set the LaunchServices key, LSMinimumSystemVersionByArchitecture, in your application's Info.plist. Our SDL/Xcode templates for Snow Leopard already set this up for you.

One additional fallout item is we had to remove the SDL Custom Cocoa Xcode template project. It depended on NSQuickTimeView which was deprecated and removed from the SDL codebase. It may still be possible to recreate the behavior that this template demonstrated, but we would need a volunteer to investigate this.

In addition, the SDL satellite projects were affected by the 64-bit transition.

- SDL_mixer depended on legacy Quicktime for midi playback support. We had to disable midi. (Recall that we also disabled MP3 support awhile back because we never got SMPEG working during the Tiger/Intel transition.) To fix this, we would need a native Core Audio backend for SDL_mixer.

- Since we have changed the baseline to 10.4, we took this opportunity to switch SDL_image over to a new native ImageIO based backend. This makes the binary about 10x smaller, greatly simplifies our maintenance requirements and build process as we no longer have to maintain build systems for 3rd party dependencies, and gives us access to more image formats.

- The static library target for SDL_ttf no longer works because we no longer have access to a libfreetype.a. We have been relying on Apple's supplied libfreetype.a, but they stopped shipping a static version starting in 10.5 which means we have no static 64-bit version. But since 10.4 is our new baseline, all these systems should have libfreetype.dylib installed, so it shouldn't be much of a problem to use SDL_ttf as a dynamic library which dynamically links to libfreetype.

-Eric Wing 2009-09-23

• To install SDL 1.2.14 we copy the SDL.framework to /Library/Frameworks:
• sudo cp -r /Volumes/SDL/SDL.framework/ /Library/Frameworks/SDL.framework

SDL_ttf

• There is a Mac OSX package on ttf project page.
• I got version 2.0.9.
• sudo cp -r /Volumes/SDL_ttf/SDL_ttf.framework/ /Library/Frameworks/SDL_ttf.framework

SDL_image

• Get package from image project page.
• I got version 1.2.10.
• sudo cp -r /Volumes/SDL_image/SDL_image.framework/ /Library/Frameworks/SDL_image.framework

SDL_mixer

• Get package from mixer project page.
• I got version 1.2.11.
• sudo cp -r /Volumes/SDL_mixer/SDL_mixer.framework/ /Library/Frameworks/SDL_mixer.framework

smpeg

• From icculus page.
• svn co svn://svn.icculus.org/smpeg/trunk smpeg
• We'll skip this for, it's optional.

PNG

• Get libPNG from the Sourceforge project download page. I got 1.2.42.
• Don't run configure. Instead: cp scripts/makefile.darwin Makefile
• make
• sudo make install

JPEG

• Source files available at Independent JPEG Group site. 
• I got v8 source (10 Jan 2010).
• ./configure
• make
• sudo make install

PortMIDI

• Source is hosted on Sourceforge. 
• I got version 2.00. Fairly new. 
• Note: PortMIDI uses cmake to generate makefiles. So you'll need to have that installed. I have version 2.8.0. 
• make -f pm_mac/Makefile.osx 
• cd Release 
• sudo make install 

SCRAP

I think this is support for the clipboard for pygame. We are missing sdl-config from our SDL framework install so we can't configure SCRAP to build it. We'll skip this.

Building pygame

So after all that palaver, you can now go to the pygame source and run the config.py.

One problem: Portmidi seems to have changed the name of its static library. It now has "_s" appended. config_darwin.py needs editing:

config_darwin.py:    Dependency('PORTMIDI', 'portmidi.h', 'libportmidi_s', ['portmidi']),

Now:

• python config.py
• python setup.py build
• sudo python setup.py install

After testing... some of the examples work, but fonts don't. :(  This is something to do with SDL linking with a new dynamic library version of freetype which I think is in the /usr/X11/lib direcotory, but this isn't in the dlopen path... Grrr.

Building PyQt4 on Snow Leopard

Here are some notes on building PyQt4 on OSX 10.6 as I always seem to miss a step every time I do this! It should be very similar for all POSIX systems except for a few flags here and there.

My set up: Intel MacBook Pro, OSX 10.6.2, Python 2.6.1 (Apple system python 64-bit, not python.org 32-bit Python).

Get Qt LGPL package. Note, you want the Qt Cocoa libraries as PyQt4 expects 64 bit libraries. The default libraries in the Qt SDK are for Carbon (32-bit) for backwards compatibility. Snow Leopard gcc compiles 64-bit code by default.

• Look here: http://qt.nokia.com/downloads/mac-os-cpp
• Download and install Cocoa 32 & 64 bit libraries.
• Notes on Qt blog: http://labs.trolltech.com/blogs/2009/08/31/qt-46-on-mac-os-106/
• Qt Snow Leopard development notes: http://doc.trolltech.com/4.6-snapshot/developing-on-mac.html

Get latest sip. Build and install:

• python configure.py
• Check configuration is what you want.
• make
• sudo make install

Get QScintilla package from Riverbank.

• cd Qt4
• qmake -spec macx-g++ qscintilla.pro
• make
• sudo make install
• make clean

Now get Mac PyQt4 from Riverbank:

• python configure.py
• Accept the GPL license.
• Check the configuration log doesn't contain anything silly.
• make
• Go and make a cup of tea. You have plenty of time.
• sudo make install
• Test to see if there: python -c 'import PyQt4; print PyQt4'

If you get some error about PyQt4 being 64-bit and Qt is 32 bit, you've installed (or built) the default Carbon version of Qt. Build or install the 64 bit Cocoa version, as instructed above.

Now, back to QScintilla package as we're going to build the Python bindings. This has to be done after PyQt has been built and installed.

• cd Python
• python configure.py
• make
• sudo make install
• make clean

Now the Qt Designer QScintilla plug-in:

• cd designer-Qt4
• qmake -spec macx-g++
• make
• sudo make install
• make clean
• Start Designer and make sure the QScintilla plug-in is there.

Microsoft Shopping Channel Slated

Oh dear, can you smell the fear? Watch the video.

It's like the Microsoft Shopping Channel. Has Ballmer really been reduced to this?

Judging by the comments on the BBC site page I think many consumers have seen the light. Microsoft has failed to deliver. They missed the internet, tried to stifle competition, spent too long on luke warm Vista, and now they're worried about losing market share because they've missed the mobile market. People don't want a PC on a slate. They want something fast, responsive, easy. You don't want to "go into PC mode" when you pull your phone or slate out of your pocket.

And I don't think it's even due to Bill Gates leaving. Microsoft just seem to be doing the same thing, but in a less savvy way now. Microsoft want to be everything to everybody, and you just can't do that. Microsoft have the desktop; it's a given, but Apple have exploited their niche very well, and quietly beavered away to create a great operating system which is part of a package that provides great software that is relevant to people today. For the average user, they hardly need to shell out for anything after buying a Mac. You get iPhoto, email manager, a proper web browser (HTML5?), Garageband, Xcode, and not forgetting Time Machine.

Personally, I'm totally sold on the Mac at home at the moment. I didn't want anything Vista on it. It seemed like a sideways move. What does Vista do amazingly better than XP? Ultimately, the thing that sold me on OSX was Time Machine. I went from one shop looking at Sony laptops with Vista on and then into the Apple store. There was picture on the wall of Time Machine and I suddenly realised that Macs aren't more expensive, and even if they are, they are worth it. You save time and have a more enjoyable user experience. To have fully automated backups on a Mac, completely transparently all you need is an external hard drive.

I'll probably be slagging off Apple one day when they become the complacent, greedy, corporate overlords that everyone hates, but for now I can't wait to see what the "iSlate" will offer. Microsoft are clearly rattled.

Spaces and Command Key

I've finally settled on a set up for switching spaces that I'm happy with on my MacBook. I started off using the command key + arrows to move from one space to another. But the problem with that is that it conflicts with editing any text, as command + arrow keys moves to the start end and end of things, which is a big thing to lose.

I've tried control + arrows and option + arrows, but you always lose some functionality. It doesn't seem very well thought out. And why can't you use the "fn" key on a MacBook with the arrows?

So I've given up on command + arrow keys and now I use command + number keys. This works well for the laptop, or for the keyboard I plug in for serious typing. You can't type properly on those new flat ones. Bah!

It's very quick and comfortable once you're used to it, especially if you use command + tab for switching applications

Toneport UX2 4.2.5 Beta drivers

I tried installing the newer Toneport UX2 4.2.5 beta drivers to see if it fixes the current problem with the 4.2.4 beta drivers. For me, this is: if you disconnect the UX2 USB device and reconnect it, it starts making the choppy noise again. You then have to restart your MacBook with the USB device connected to get it to work properly again (which is a real pain as you have to start all your apps again).

My spec: MacBook Intel '09, OSX 10.6.2, Toneport UX2.

Didn't realise the beta drivers existed until today as they are not well publicised. Remember to click the "beta" tick box on the Line 6 download page:

At first attempt I installed them over the 4.2.4 drivers that I installed, but this doesn't work. I got choppy noise again, but not the same as the first time with the 4.2.4 drivers. Ended up having to uninstall everything and start again.

To anyone from Line 6 reading this: Why don't you supply an application to clean up all traces of Line 6 applications? Dragging applications to the trash can won't delete all files on a Mac. Most of the hassle I have had was figuring out that you need to remove stuff from /Library etc, and that you need to do a clean install. This might stop a significant number of complaints, which I'm sure is losing you customers. I'm only a casual musician, but I'll bet more dedicated musicians are much more frustrated at the situation.

I had to use AppCleaner to get rid of everything (otherwise "kext error" appears):

• Restart (so we start with clean slate).
• Run AppCleaner.
• Uninstall Line 6 Gearbox using AppCleaner.
• Uninstall Line 6 Monkey using AppCleaner.
• Restart.
• Uninstall Line 6 drivers (Use program in Line 6 directory in Applications).
• Restart (to start again with no Line 6 software).
• Install latest Gearbox (3.70, contains 3.4 drivers).
• Install latest (4.2.5 beta) drivers (over Gearbox drivers).
• Restart.

Don't install Line 6 Monkey. Apparently the current version can't recognise half the hardware and don't know what other problems it causes.

So, the good news is that you no longer have to restart to get the UX2 to work if you unplugged it.

The Line 6 site claims:

This driver addresses the following issue:

* Various audio pops, clicks, and glitches - FIXED

I'm not quite sure what problem they are referring to, unless other devices besides the UX2 weren't fixed with 4.2.4. The problem I had was disconnecting the USB device.

The bad news is that the drivers still aren't there yet as they aren't 64 bit. I.e. you can't run your MacBook in 64 bit kernel mode where it is something like 30% faster in some cases. Snow Leopard defaults to 32 bit mode for safety, which a lot of people won't even realise. You can tell whether you have 32 or 64 bit kernel mode by doing:

Apple menu > "About this Mac" > "More info..." > Software (In "Contents" left bar) > "64-bit Kernel and Extensions"

You'll see:

To use your Line 6 device this must say no. Line 6 haven't added support for the new Snow Leopard 64 bit kernel yet.

• To boot into 32 bit mode (default) hold down "3" and "2" keys when restarting your Mac.
• To boot into 64 bit mode hold down "6" and "4" keys when restarting your Mac.

More info.

Field

Field looks like a really interesting piece of software. It is step on from Processing, providing a richer IDE with features like embedded editing widgets. I haven't used it in anger yet, and it is still beta, but it looks promising. There are apparently 6 years of work in there so there must be a lot more than meets the eye!

What I also like is the implementation philosophy that other libraries and technologies should be embraced and integrated, rather than rewrite everything. It appears that Field provides a wrapper around other technologies and allows time coordinated use of them. The screen shot about shows the canvas. Left to right is the timeline and the boxes represent things going on.

It will be interesting to use the editor and experiment with the embedded widgets. I've thought about a similar concept for my Guish project, where you'd have interactive GUI elements mixed with text that you enter, like in a terminal. Pure text terminals see really out of date now, and it's about time there was some suitable graphical enhancements.

Other pieces of work by the Open Ended Group that look interesting are Breath, which explores different graphical representations of music, and Musical Creatures, which explores digital creatures that can interact with their environment.

Toneport on Snow Leopard

UPDATE (25-Nov): Please read: 4.2.5 beta drivers are available.

I managed to get my Toneport UX2 working on my (2009 Intel) MacBook Pro with Snow Leopard after a bit of fiddling around. I installed Snow Leopard before finding out that my UX2 is not officially support yet (doh!), but there are beta drivers. I take this to mean that they haven't ironed all the issues out. I couldn't find anything (easily) on the Line 6 forums to help sorting this out. It seems a lot of people have the same problem.

Writing drivers is complicated, and converting drivers from 32 to 64 bit is non-trivial. If you've tried to run Vista 64 they had all the same issues (i.e. no/buggy 64 driver support for a lot of things for quite a while).

Initially I just installed the latest 4.2.4 drivers, but this created "choppy noise" (cutting out, popping, white noise, etc). I did get the "kext" error whilst installing, so assume something was going wrong (but I didn't spend time finding out what). Snow Leopard is all 64 bit now, so some drivers won't work. If you just install the latest drivers something must get confused.

The trick is to completely remove all Line 6 software and start again. I rebooted several times, cautiously, to allow the OS to remove unwanted files. I used AppCleaner to uninstall applications because otherwise some files get left behind (e.g. config and data files). If you don't use AppCleaner, this won't work.

• Restart (so we start with clean slate).
• Run AppCleaner.
• Uninstall Line 6 Gearbox using AppCleaner.
• Uninstall Line 6 Monkey using AppCleaner.
• Restart.
• Uninstall Line 6 drivers (Use program in Line 6 directory in Applications).
• Restart (to start again with no Line 6 software).
• Install latest Gearbox (3.70, contains 3.4 drivers).
• Install latest (4.2.4) drivers (over Gearbox drivers).
• Restart.

After you have done this your Toneport should work as normal. The order is important. My Toneport works fine with Garageband and Gearbox now. I'll keep an eye out for new drivers.

Not a bad idea to bung the guy who wrote AppCleaner a couple of bucks, because this won't work otherwise. :)

I'm not a Line 6 support engineer, if this doesn't work for you, sorry!

UPDATE (7-Oct): After disconnecting the UX2 and using my laptop elsewhere, and then plugging the UX2 back in, the crackling came back again. I managed to get rid of this by leaving the UX2 plugged into the USB port and rebooting the Macbook. It seems like disconnecting the UX2 and/or the Macbook going into sleep breaks something in the 4.2.4 drivers so you have to reset the machine.

Snow Leopard

Well, I upgraded to Snow Leopard recently (10.6.1). Normally I wait a while with new operating system versions until they've had a chance to patch them (e.g. version X.Y.3). I waited quite a while before installing Leopard as it was such a big upgrade. Snow Leopard is supposed to be a "tweak", with the biggest changes at low level, where everything has gone 64 bit.

The biggest problems here will be with hardware drivers breaking (as I found out with my Toneport UX2). Still, compared to Vista 64 this doesn't seem to be much of a problem. Microsoft is notorious for releasing beta quality software and then patching it after users have tested it. Apple seem to be a bit better at releasing, but then they control the whole hardware and platform more strictly, so they have less margin for error.

Snow Leopard does seem more responsive, not that Leopard was slow. Apps seem to start faster, and the Finder is instantaneous. This is a breath of fresh air after using Window's sluggish Explorer (on XP). It's pretty poor that it can take a couple of seconds to refresh, even on a high spec machine.

Snow Leopard no longer supports PowerPC so my old G5 will have to stay on Leopard, and will probably be appearing on ebay. I believe applications are also compressed, which allows them to load faster. It's faster to decompress something into memory from disc, as the bottleneck is your slow hard drive (especially on a 5400 RPM laptop drive). My laptop does seem more zippy, and I got a massive chunk of hard drive space back, ~10GBs?!! I have XCode and a load of other stuff that would benefit.

Not really noticed any visual changes, but it does seem strangely more pleasing to the eye. Upgrade cost is relatively cheap and Apple have been smart not to charge a lot for something which doesn't give a lot of end user features, but a lot of work will have gone into all the optimisations it provides. Worth upgrading for the extra responsiveness.

Mac usable coloured terminal

When using a terminal window on the Mac (or on any system!) if everything is the same colour it is difficult to tell the difference between file types. E.g. there is no difference in presentation between a file, a directory and a link.

If you are using a bash shell (it tells you in the title bar what type it is), you can configure colouring using your profile. This lives in the file: ~/.profile. Add your changes to the end of the file.

There are some helpful blogs with information on what to add, but I found the bold lettering difficult to read. You achieve something more readable just using 'ls -G'. So add:

alias ls='ls -GF'
alias ll='ls -hl'

The -F option also tells you what the object type is (man ls), and ll adds an extra command to save doing ls -l.

You might also want to change your terminal prompt. The default is the machine you are logged into, which is a little pointless if you know it, and takes up a lot of screen. I find the following quite useful:

export PS1='\t \w> '

\t gives you the time in 24 hour format. It also gives seconds and can be a useful way of timing commands roughly. \w tells you the current directory.

Upgraded Mac to Leopard

Been getting more into the Mac recently. Did a clean install of Leopard (OS X 10.5) and it seems there are a lot of subtle improvements over Tiger. I held off doing this for a while since a lot of open source and freeware software hadn't been updated.

Seems more polished generally. Once nice thing is connecting to a Windows machine over a local network is a lot easier. Despite the apparent ease of a lot of things in OS X some things were a little esoteric, or half arsed. Generally, though I now seem to spend less time messing around trying to get things done. Quicksilver also seems somewhat redundant now as Spotlight has been added.

This is the last upgrade of OS I'll get for the PowerMac G5 I have. Apple are apparently on a big push to optimise OS X for Intel now and have dropped support for PPC. Not too surprised at this as the machine is starting to feel a little sluggish now and starting to think about upgrading, but not quite sold on the pricier Mac hardware yet. For starters, Mac laptops have relatively small screens for the price (although it helps with battery life). For a desktop replacement though you need a bigger screen.

Also got an external hard drive so I can use Time Machine. Now this is a great piece of software. Not only does it just back everything up transparently it also sets your backup schedule for you. And the presentation is excellent as well, screens travelling through space. Corny but well done ;-).

Haven't had to retrieve anything major (yet!) but it's nice having that feeling that everything is being backed up in case you have a catastrophic drive failure (which will happen eventually, and has happened to be twice before on PCs). Now to backup my Windows laptop I can just copy my documents onto the Mac and they'll be backed up. :-)

Just getting into using Spaces now. With four of them you have four desktops which is very handy for programming where you have web and document references open, a compiler and testing environment. Well you need one screen just for Xcode because of all the window clutter.

Another addition is Mobile Me although yet to try this. Unsure what I'd use it for at the moment. I use Google and Yahoo for my web storage at the moment.