Rapping backwards

Clever rap video. Good work!

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.

Banana head

I think we've all had days like this...

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.