bookmark_borderGetting started with Allegro 5.1 on Mac OS X 10.8 (Xcode 4.5, and homebrew)

In Dune 2 – The Maker, I have used Allegro quite a bit. Back then it was around version 4.2. Allegro is a library that allows you to make games. In essence it has functions for manipulating the screen (ie, drawing bitmaps, manipulating palettes, etc), use controls (mouse, joystick, keyboard, etc) and more. With plugins you could extend it further, to use fonts (TTF), networking, etc.

Currently, the most recent version is Allegro 5 which breaks with the Allegro 4 API and makes it impossible to convert from Allegro 4 to 5 (atleast for D2TM). From a nostalgic perspective I wanted to try Allegro 5 and on my new system which runs Mac OS X 10.8.

In this post I will describe how you can get Allegro 5 working on Mac OS X, under XCode 4.5. I had great help from the documentation provided, and hopefully this post is sufficient for you. If not, I would suggest to checkout this documentation, or this one.

Rough steps

To give you an idea what we’re going to do, here is the installation in very rough form:

  1. – Installing required software
  2. – Installing dependencies to make Allegro more useful and to get it compiling (cmake, etc)
  3. – Compiling Allegro for Xcode, installing it and making sure the Frameworks are installed in /Library/Frameworks
  4. – Setting up an Xcode project to test if Allegro works

Prerequisites (Installing required software)

Requirements for getting started, if you already have this installed you can skip the prerequisites

  • Mac OS X 10.8
  • Xcode 4.5 (with command line tools)
  • Git/SVN
  • Homebrew

Before we can start, we need to have installed some prerequisites. Which are Xcode (you can get this from the App store), git and svn. I have used homebrew to install dependencies, you can also use Macports but I do not have any experience with this. (as far as I can tell it should behave quite the same). My advice would be to install these in the following order:

  • – Xcode
  • – Install command line tools from Xcode
in Xcode, go to preferences, tab "Downloads" -> " Components" -> Command Line Tools
ruby -e "$(curl -fsSL https://raw.github.com/mxcl/homebrew/go)"
  • – The command line tools should have installed git and svn for you, try them out:
hit "svn --version", and "git --version" in your terminal.
If they are not installed, you could install them via homebrew (brew install git && brew install svn)

Installing required dependencies

As suggested by the Allegro 5 wiki we need to install dependencies. The wiki explains how to do it with Macports, but since I am using Homebrew, you need to do it like this:

brew install cmake

brew install zlib
brew install freetype
brew install jpeg
brew install libogg
brew install physfs
brew install libpng
brew install flac
brew install ffmpeg

The first one is cmake, which we will need to build Allegro. Cmake is required to create the OS specific build steps to compile Allegro, without it we cannot proceed. The other dependencies are used to make Allegro more useful. When we prepare to build Allegro in the next section, cmake will check what dependencies are installed. The more it finds, the more features it will provide in Allegro 5.

Note, you might get  a warning about zlib. If thats the case, you can ignore it.

Compiling Allegro for Xcode, and making sure the Frameworks are in /Library/Frameworks

Once we have everything set up, this step is relatively easy. Since we are going to compile it for Xcode, we basically are doing the same as the Allegro wiki is saying.

Open a terminal, and go (cd) to a directory where you want to get allegro’s sources. For example: ~/projects

cd ~/projects

We now need to fetch the sourcecode of Allegro, which we can do by using git clone. At this moment of writing, Allegro 5.1 is the current version. Our git clone command looks like this:

git clone git://git.code.sf.net/p/alleg/allegro

This takes a little while. Once git is done, you have Allegro’s sources in ~/projects/allegro.

Now: cd to allegro, and create a new directory called “build”, then go into that directory.

cd allegro
mkdir build
cd build

The first step is to let cmake (the first dependency we installed) prepare our build, then build it and then install it. This is done by the following:

cmake -G Xcode -DWANT_FRAMEWORKS=1 - ..
xcodebuild
sudo xcodebuild install

The last step requires you to enter your password.

I found that the last step did not work for me, in order to fix that I did:

cd lib/RelWithDebInfo

Within here all Frameworks are built. Now copy them over to your /Library/Frameworks directory with sudo. With this:

sudo cp -r *.* /Library/Frameworks/

If you don’t want to copy this over to your Library/Frameworks directory, then you need to remember the path to these frameworks as we are going to need them later.

Setting up an Xcode project and see it all working

This section is a copy & paste + improvement from this page.

  • Start XCode, create a new empty project (Other->Empty)
    Xcode new empty project
  • Add a Cocoa Application target to the project, let’s call it MyGame. (Click your project, then the + button at the bottom saying Add target, then Mac OSX->Application->Cocoa.)
    New cocoa application MyGame
  • Select the MyGame target, go to the Build Phases tab and add a new Copy Files Build Phase (+ button down right).
    • Select Frameworks from the dropdown
    • Leave Subpath blank
    • We leave this build phase empty for now, we will need it later.
      Add new build phase
  • Select the Build Settings tab then:
    • Note: You can change display from Basic to All at the top and use the search box to locate the following settings
    • Change Header Search Paths to (just copy & paste):
      /Library/Frameworks/Allegro-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroMain-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroAcodec-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroAudio-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroColor-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroDialog-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroFont-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroImage-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroPhysfs-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroMemfile-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroPrimitives-5.1.framework/Versions/Current/Headers /Library/Frameworks/AllegroTTF-5.1.framework/Versions/Current/Headers
      

      (yes, it is intended to be one line)
      add framework headers

    •  
    • In the targets Build Settings specify the Framework Search Paths as/Library/Frameworks.add framework search path
      • This is needed to have cross-platform code (#include <allegro5/allegro.h> working – otherwise paths like using #include <Allegro-5.0/allegro5/allegro> would work without changing the search path)
      • If you use another location, one way to save on typing is to double click the input field, then navigate to the Headers folder in each framework and drag it into the xcode input list
    • Delete Prefix Header (Edit->Delete)
      • You can of course use your own prefix headers – but the default Cocoa one will only work with objective C projects that’s why we remove it, assuming MyGame is a cross-platform C/C++ project
  • Add all the Allegro frameworks as follows (this can be done in many ways, a group just keeps things tidy):
    • Select the Summary tab
    • Click the + button under Linked Frameworks and Libraries and add all the Allegro frameworks
      • In case they are not listed use the Add Other button and navigate to /Library/Frameworks to find themadd frameworksselect frameworkslinked frameworks added
    • Go to the Build Phases tab, then in the list to the left select all the Allegro frameworks and drag them to the Copy Files entry which we added before
      drag frameworks to copy build phase
    • Select all the frameworks again and this time drag them to the Frameworks group to the left (just to have things more tidy)
  • Don’t forget to remove the created source files under MyGame and add your own source code instead (note the main.m in Supporting Files for example)
    • Create a new main.c
      create new main
    • Give it the following content:
#include <allegro5/allegro.h>

int main(int argc, char **argv) {
   al_init();
   al_create_display(640, 480);
   al_clear_to_color(al_map_rgb_f(1, 1, 0));
   al_flip_display();
   al_rest(5.0);
   return 0;
}

Caveats

  • Cannot find header files: Make sure you have set the header paths correctly. Try to copy the one line given above, into your header paths (remove old ones first). If that does not work. Try adding them one by one, to make it easier to copy/paste I have provided them for you separately as well:
    /Library/Frameworks/Allegro-5.1.framework/Versions/Current/Headers
    /Library/Frameworks/AllegroMain-5.1.framework/Versions/Current/Headers
    /Library/Frameworks/AllegroAcodec-5.1.framework/Versions/Current/Headers
    /Library/Frameworks/AllegroAudio-5.1.framework/Versions/Current/Headers
    /Library/Frameworks/AllegroColor-5.1.framework/Versions/Current/Header
    /Library/Frameworks/AllegroDialog-5.1.framework/Versions/Current/Headers
    /Library/Frameworks/AllegroFont-5.1.framework/Versions/Current/Headers
    /Library/Frameworks/AllegroImage-5.1.framework/Versions/Current/Headers
    /Library/Frameworks/AllegroPhysfs-5.1.framework/Versions/Current/Headers
    /Library/Frameworks/AllegroMemfile-5.1.framework/Versions/Current/Headers
    /Library/Frameworks/AllegroPrimitives-5.1.framework/Versions/Current/Headers
    /Library/Frameworks/AllegroTTF-5.1.framework/Versions/Current/Headers
    
    
  • Compiling works fine, linking does not work: Make sure you have specified the Framework Search Paths as/Library/Frameworks.

bookmark_borderOS X (10.8) Mountain Lion path settings not ‘picked up’ in RubyMine

Recently I have switched jobs to Zilverline.

And so far I love it there.

One of the things I now work in is OS X (10.8.2). I am programming in Ruby using RubyMine. I think RubyMine is great (especially since I am coming from IntelliJ as a Java programmer).

However, one of the things that bugged me was path variables not picking up in RubyMine.

From terminal all my stuff works great. Ie, rake spec, rails, etc. No problem.

However it seems RubyMine does not launch with the same path variables set as you terminal does. Also, the suggestions for does not work in OS X 10.8.

There where two ways for me to get around this problem. One is to simply launch RubyMine from terminal:

open -a /Applications/RubyMine.app/

Because you launch it from the terminal itself, RubyMine will get all the environment settings from there.

Another way was to edit the default settings in RubyMine for (in this case) rSpec:

rubymine_rspec_defaults

And set the environmental path with value:

/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:$PATH

rubymine_set_path

Now all rspec tests will use this environment path and run fine.

bookmark_borderSlick 64 bit and Linux

Recently I wanted to run Slick on linux in a 64 bits environment. I got it working on Windows a while ago but I forgot to include natives for Linux and Mac OS X.

To get it working on Linux I simply redid the steps I did back then. I’ve tested the results on Linux and also on Windows, with success!

If you are interested, then you can grab the natives here; and the JARs from here.

(or just simply clone dune2themaker4j and get it all in one go)

bookmark_borderA Randori with Corey Haines

Saturday 8th of September 2012.

I came to Amsterdam Amstel train station, to pick up Corey Haines who I had asked if he wanted to meet the local community in Amsterdam and have some fun coding.

After I first introduced myself to a complete stranger (I swear he really looked like Corey Haines :))…
I then walked to (the real and smiling) Corey Haines and got us to the car to get to our location.

It was a fun evening coding. Around 10 people came and we mainly focussed on coding. I want to share one of the highlighting moments (to me) of that evening.

A Randori.

I never did a Randori before, but I really liked this form of group programming, so let me share this with you. Perhaps you might want to try it yourself with a group of developers you know.

So what is a Randori?
If I had to put it in one sentence: A Randori is a pair-group-rotating-programming session.

What we did
We did a Kata, but not all by ourselves… we did it all together.

Doing a Kata on your own is fun.
Doing a Kata with multiple people surely would be more fun right?

In this case we did the LED Display Kata.

But how did we do it as a group? Basically it works like this:
You have one person controlling the computer (called the Driver). Another person, called the Navigator, has a say in what should be made (design-wise). The Driver and the Navigator form a pair.

The rest of the people (the Audience) has a role as well:
When doing the Kata (in TDD of course), while you are in the red phase (test fails), the Audience must remain silent while the Driver and Navigator try to get the test to green (test passes). The Driver and Navigator may talk and work it out. Once the test is green, the refactor phase starts, the Audience is allowed to bring in suggestions. Want to shut up the audience? Write a failing test 😉

After a few minutes (in our case 5 minutes) you switch roles:
Navigator becomes Driver
Driver becomes Audience member
someone from the Audience becomes Driver

That’s a whole ‘session’. Reset the timer, and continue with the Kata where the previous pair left off.

Since you cannot write new code without a failing test, the Navigator is obliged to write (or let the Driver write to be more exact) a failing test first.

To avoid major rewrites of the code, there is a restriction to the Navigator. He may only refactor big changes after introducing an amount of new tests. Only when the tests pass, the Navigator may introduce major design changes.

So why is this fun?

It is fun for several reasons:
– It resembles a real world problem, where you have to work with existing code (and you can’t change the whole design because you feel like it).
– It’s fun to have short discussions about the code and its design
– You learn a lot from others when discussing code and design
– You learn how Java sucks by having no String.join() 😉

Picture or it did not happen!
Here you can see Corey Haines (at the left) in the session, looking at code that Arjen (at the right) is typing. And yes, I am taking this picture so you don’t see me on it of course! 🙂

Recap
Doing a Kata is a fun excersise alone. If you are with a group of people you could consider doing a Randori, and have fun coding together. The Kata itself is only the means to pair program, fix a problem, in existing code you did not write and trying to

Practical: What do you need
– A group of people (around 10 people)
– A computer with a dev environment installed (testing framework required)
– A big screen / a beamer

Thanks!
Special thanks to Corey Haines for coming over and let us have this experience!

Footnote: Later Arjen, Daniel and I had worked on the LED Kata again in a teamviewer session. We made a working solution (we wanted to crack the problem badly), which is also on Github.

bookmark_borderAnother reason to participate in a coderetreat

I’ve attended a coderetreat not so long ago in Rotterdam.

I have talked about coderetreats before; how they help improve your skills.

The most important reason to join coderetreats however is to just have fun.

I had a good time!

Why don’t you join a coderetreat event nearby and have a good time as well? 🙂

DSC_4348