Monday, 2 August 2010

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.

Tuesday, 6 April 2010

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.

Monday, 5 April 2010

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.

Sunday, 28 February 2010