Features

Catalyst:

Cross platform build scripts sitting on top of CMake. Makes it easy to build your application for multiple platforms and multiple IDEs.Independent Use: Many of Gail’s components are designed to be used outside of Gail. This allows for use of individual pieces for integration in other projects (like the network driver, multithreated language translator, QT support, and crash driver).

 

Documentation:

Very well documented using Doxygen. Integrates with KDevelop and Xcode, and easily can be used in other IDEs.

Cross Platform:

Currently supports Linux, OSX, Windows, iOS, Android, but easily portable to any other platform that supports C++. You can do development on one system, and easily port it to another.

Resource Drivers:

Just like platform drivers, all resource loading is handled similarly. If you need to add another format, its just one driver away.

Debugging tools:

GAIL Allows direct access to its memory usage and rendering system, allowing you to trace bugs easier. Any object can be output directly, making it very easy to output information. Classes such as DebugBlock make it easy to time specific areas of code, and Backtrace allows you to get a functional backtrace anywhere in code.

Serialization:

Gail objects can be marked as serializable, allowing them to easily be output to an XML (plist) based format and imported back into an object (can be expanded to custom formats easily). Similar to NSCoding and other systems.

Driver Model:

Drivers in Gail provide three major features depending on the context. These allow the specific implementation to separate itself from using the driver. For example, all of the AudioSystem drivers which play sounds share the same interface, allowing you to use them the same no matter which one you’re using.

Main patterns used:

  1. Cross platform support. Drivers keep the underlying platform hidden and allows you to just write your stuff ontop of Gail, and automatically support all the platforms Gail support. Examples: Window (creates a window), Renderer (graphics systems), VFS (various places to load files)
  2. Abstraction. Some drivers are just to abstract it to make a single API for a set of common functionality. For example, you would almost never switch SQL drivers in the middle of the project, but its there if you need it.
  3. Group usage. If you need to use multiple drivers at the same time, this allows you to use entire groups with a single command. For example, Trophy lets you say an achievement the user got, and it’ll automatically forward it to all drivers enabled. So if they use openfeint, gamecenter, and your own custom system : you can use it without caring on the details of where it goes.

Resource Model:

Similar to the driver system, but for various resources that need to be loaded. Allows the developer to not worry about where things are placed in the filesystem and easy accomodates changes to that system. Perfect for modding.

All resources (images, sounds, etc) use the resource system allowing files to be loaded without knowing the specific type (png, jpeg, etc).

Localization support:

Basic localization support.