Thursday 27 October 2011

Development's ups and downs

Game development is sometimes testing! You get stuck on things, you go through boring phases, you wonder if you are going in the right direction. Often you have to fight though it to get that little reward that keeps you going.

Perseverance is not a long race; it is many short races one after another. - Walter Elliott
I do not think there is any other quality so essential to success of any kind as the quality of perseverance. It overcomes almost everything, even nature. - John D. Rockefeller
The road to success is dotted with many tempting parking places. - Author Unknown
It's not that I'm so smart, it's just that I stay with problems longer. - Albert Einstein

And I guess now I ought to stop reading quotes and do some work. :o)

Tuesday 11 October 2011

UI for Allegro 5

I found a nice UI system called GWEN. It has lots of advanced features and is very easy to embed. It sits nicely on top of your application and can just be wired into its resources, to save competing systems, e.g. input or texture management.

Example of Gwen UI from the Gwen site.
I ported it to Allegro 5, which was quite easy as the renderer and input abstractions are well designed. I did it on the Mac, but it also works just fine on my old Windows XP laptop. Gwen also provides rendering backends for OpenGL, DirectX, SFML, and Windows GDI.

[Note] I have forked GWEN in order to fix various issues with Allegro 5, etc. There are notes in the readme and on the wiki. You may want to prefer this version if you are using Allegro 5. Please report any issues in the Github issue tracker for Gwork.

If you have used Delphi, or Windows Forms you'll probably find it quite easy to pick up. There are unit test examples from which to learn, but other than that you have to plough through the code at the moment. Hopefully more docs and comments will appear soon to ease the learning curve. There is a small tutorial on doing layout with docking.

One of the things that is really nice about Gwen is the skinning system. It is all laid out in one bitmap, along with the colour scheme at the bottom.

The default skin for Gwen.



Saturday 9 July 2011

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.

Tuesday 3 May 2011

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.

Sunday 6 March 2011

Allegro 5.0 on Mac Snow Leopard

For more notes on Allegro 5 on Lion and Xcode 4 see this post.

I had been experimenting with Allegro 4.4, but now Allegro 5.0.0 has arrived. Apparently version 5.0 has had its API revamped and more functionality added, so I decided to give it a go. I believe it now expects hardware acceleration and has drivers for OpenGL and DirectX. Its appeal lies in its simplicity, good support, and is very cross platform, supporting Windows, Linux, OSX, iPhone, etc.

Build notes:

Dependencies

Previously I had been building libraries from their source and installing them in /usr/local using the usual UNIX build routine (i.e. download source and make). This is somewhat laborious and can be time consuming if something goes wrong (because not OSX compatible). This time round I decided to use MacPorts to do the lifting for me. This saves a lot of time. Just follow their standard installation instructions.

Then you need to install the libraries that you will need to compile Allegro 5. These are listed on this page, but aren't quite correct. I used:
sudo port install zlib freetype jpeg libogg libvorbis
Some of these need to be compiled in "universal" mode as they are compiled in 64 bit by default (which is the default of the compiler, new on OSX 10.6):
sudo port upgrade --enforce-variants libpng +universal
sudo port upgrade --enforce-variants physfs +universal
This will take a while if you are doing this from scratch (20+ mins). After this you should have a new /opt directory, which contains a load of new libraries. You can type "port installed" to see what you have. Some libraries will have "+universal" next to them.

Now download the Allegro 5 source, or get latest from svn. You can repeat the steps from here onwards when you get new versions of Allegro.

To build Allegro you can either build libraries or a framework, and you can either use makefiles or Xcode project files. I built libraries using Xcode 3, and now frameworks using makefiles. Frameworks are more in fitting with the Mac way of doing things, so probably best to use those.

Xcode 3 - Static library

To build using Xcode: Snow Leopard GCC compiles 64-bit code by default, but Allegro is not a 64-bit library, so we want to compile everything as i386. We first generate the Xcode files and then load them in Xcode 3 and change the settings for 32 bit (i386):
  • cd to/allegro
  • mkdir build
  • cd build
  • cmake -G Xcode ..
This will do a load of scanning for the dependencies it needs and then you'll end up with an Xcode project file: ALLEGRO.xcodeproj. This can be opened using Xcode 3 or 4. Although, at the current point (July 2011) I wouldn't recommend Xcode 4, it's just not ready.

For Xcode 3: open the the project file and (in the root project at the top):
  • Change the Architectures to 32-bit Universal.
  • I chose the RelWithDebInfo configuration. I haven't tried the others.
  • Change the active architecture to i386. This is important as Allegro is 32-bit.
  • Reading this article is useful if you don't know which SDK to use.
Build the ALL_BUILD target. You can run A5teroids and some of the example to check that it all works.

Sorry, I haven't built this using the project for Xcode 4. Use the frameworks below if you can't manage it. That's what I am using.

The install will fail because the script it is trying to run needs root access. So go back to the terminal and run the install command manually:
sudo cmake -DBUILD_TYPE=RelWithDbgInfo -P cmake_install.cmake
Then the Allegro files will be installed in /usr/local and you can include and link then from the usual places.

Frameworks

OSX 10.6 switched from 32 bit to 64 bit. Allegro needs to be compiled as 32 bit (i386). So we do the following in the unpacked allegro directory:
  • mkdir build
  • cd build
  • cmake -DWANT_FRAMEWORKS=1 -DCMAKE_OSX_ARCHITECTURES=i386 ..
  • make
  • make install
And Bob is your Auntie.

Hopefully at some point some kind person will add Allegro 5 to MacPorts to save having to do this.


New Project

The easiest way to set a new project up is to create a command-line application in Xcode. However, if we want to package all the assets, like normal Mac applications, you need to create a Cocoa application ("New Project..." > "Cocoa Application").

In the project settings, add "/usr/local/include" as a user header path. This will include the Allegro file that we just installed above. In targets, right click on your application and choose "Add..." and add existing files "/usr/local/lib/liballegro.dylib" and "/usr/local/lib/liballegro_main.dylib". Now, you should be able to build and run your application. However, two windows will appear! This is because the liballegro_main stub will create a window as well as your default application having one (in the .xib).

To remove the default app window (because we want the Allegro one) look in the "resources" folder and open "MainMenu.xib". This brings up the interface designer. In the list of objects, delete the NSWindow object, this will stop two windows being created when the application starts. We also don't need the auto-generated stub code for the application either, so you delete the "main.m" and "app delegate.m" files. You can also delete items from the menu you don't want by dragging them onto the desktop (and they disappear in a puff of smoke). If you build and run you should have one window now.

There is a tutorial on Allegro 5 on the wiki. The API looks a bit more tidy and better namespaced now.


[6-Mar-11] - Updated for Allegro 5.0.0. Notes were previously for the release candidates.
[25-Mar-11] - Added missing libvorbis to port install.
[26-Apr-11] - Using Xcode 3 for building. Xcode 4 wasn't available when this was written.
[7-Jul-11] - Notes for building with frameworks and Macports 32-bit builds.


Tuesday 22 February 2011

What motivates us?

Interesting talk on what motivates us. Studies find that cognitive work is not driven by financial reward, but more by a sense of purpose.