Introduction

The gaming hardware base today is more fragmented than ever before. With the majority of the gaming audience moving to the mobile and the web, the number of platforms to target for game developers has grown difficult to manage. The common topics to consider are whether one should make the switch to HTML5/WebGL, or perhaps use Flash, and how to reach the different mobile ecosystems at the same time with the least effort. To grow the variety, Microsoft has entered the mobile segment with a strong move on Windows 8, which should not be ignored lightly.

The universal language for high-performance rendering and gaming applications is still C/C++. It is the only language that allows writing code as close to the hardware as possible (assembly and SIMD), with no compromise to performance (no VM or GC) while retaining the support for widest possible cross-platform deployment. These are the premises on top of which gfxapi is built.

The goal of gfxapi is to provide universal deployment options for game developers without sacrificing a single millisecond of performance. With gfxapi, it is possible to develop applications fully in C++ and target a multitude of platforms with an automated deployment procedure.

Principles

The development of gfxapi is based on a clear vision for the following goals and non-goals:

Minimal Size.

The absolute requirement for developing on mobile and web platforms is to keep the code size and memory footprint low. The features gfxapi comes with are configurable. There are no plugin architectures or dynamic library loaders. Gfxapi builds to a single static library. Feature inclusion/exclusion is achieved with build-time configuration flags so that developers do not have to build or load features they do not need.

Not a Black-Box Framework.

The problem with frameworks is that they often hide the target platform and encourage the developer to write non-reusable code that ties themselves to the architecture of the framework. Gfxapi does not hide the environment, instead, it allows the developer raw access to specifics. The Direct3D11 and OpenGL device contexts are fully accessible, as are the Android and iOS environment objects, and so on. Gfxapi is not an application development framework, but instead aims to be a library that the user has control over.

Not an All-in-one Solution.

Gfxapi only provides a platform-independent access to the low-level rendering device. It does not implement a scene hierarchy, a renderer, or game editor UIs. This is because most games tend to do things differently. Gfxapi does not dictate how the higher-level scene management or rendering should be organized.

Self-contained.

Gfxapi does not require a heavy set of third party helper libraries to implement support for each platform. The few that it has are embedded into the codebase or automated in the build steps. MathGeoLib is a part of gfxapi. Gfxapi also (optionally) uses the libraries freetype2, crunch, stb_image, glew (on Windows only), and tinyxml, which are all embedded in the repository itself.

Test-driven Development.

The basic principle of gfxapi development is that only features that are demonstrated by unit tests or samples exist. Gfxapi development is organized around a continuous build system, and due to the large number of platforms to support, features that do not have associated tests implemented are not considered supported functionality.

Features

The library provides the following high-level functionality:

CMake-based Build System.

The CMake tool is used to implement the build system architecture for gfxapi. Gfxapi comes with cmake scripts for each supported platform, which enable automating application build and deployment for each target platform. The application developer uses familiar Visual Studio 2010, Visual Studio 2012 or XCode projects, as appropriate for the target platform.

Application Instance Class.

To hide the different application startup/bootstrapping operations and the main loop handling mechanisms required on each platform, gfxapi provides the MainClass interface, which the application developer implements to create the application. The MainClass object represents an instance of a running application, and it provides the entry points to other library functionality. To retain flexibility, using MainClass is not strictly necessary, and it can be avoided if the user application needs to implement main() or the main loop itself.

Rendering API Abstraction.

Gfxapi supports rendering using Direct3D11, OpenGL 3, OpenGL ES 2 and WebGL. It implements a lightweight wrapper over the required primitives in the rendering layer to hide the underlying API from the developer. The wrapper is modelled almost 1:1 after the Direct3D11 API itself, so converting existing Direct3D11 code to use gfxapi should be easy. Gfxapi does not support Direct3D10, OpenGL ES 1, OpenGL 2 or older, which means there is no support fixed function pipeline.

Input Devices Abtraction.

Different platforms all have their unique interfaces for receiving user input. Gfxapi implements a common event-based input system that works the same on all platforms. This is optional though, and the user is free to ignore it and implement custom code instead.

Texture Format Support.

To ease common programming tasks, Gfxapi comes with the stb_image library to add support for JPG, PNG, TGA, BMP, PSD, GIF, HDR and PIC file formats. It also implements a custom DDS texture loader, and uses libcrunch to add support for CRN textures. Gfxapi can also optionally use D3DX to load textures when targeting Windows 7.

Geometry Format Support.

Additionally, Gfxapi can load geometry data from OBJ and OGRE XML files. It also implements its own binary MSH file format for storing raw vertex and index buffer data for fast loading to GPU. There is also a work-in-progress integration with the OpenAssetImport library to load meshes from the formats it supports.

Deployment Options

The following development and deployment targets are available for gfxapi:

Windows 7 + Direct3D11/OpenGL3 + 32-bit/64-bit.

Develop using Visual Studio 2010 on Windows 7, and produce both 32-bit and 64-bit builds for Windows 7 that use either Direct3D11 or OpenGL3 as the rendering backend.

Windows 7 + Direct3D11/OpenGL3 + NPAPI.

Develop using Visual Studio 2010 on Windows 7, and produce NPAPI plugins for Windows 7 that use either Direct3D11 or OpenGL3 as the rendering backend. These web plugins can be run on Firefox, Chrome and Opera on Windows.

Windows 8 Desktop/Windows 8 Store + Direct3D11 + 32-bit/64-bit.

Develop using Visual Studio 2012 on Windows 8, and produce both 32-bit and 64-bit builds for Windows 8 that use Direct3D11 as the rendering backend. Target both Windows 8 Desktop and Windows 8 RT (Store) type of applications.

Windows 8 Phone + Direct3D11.

Develop using Visual Studio 2012 for Windows Phone 8 on Windows 8, and produce application packages for Windows Phone 8 that use Direct3D11 as the rendering backend.

Google Native Client + OpenGL ES 2 + 32-bit/64-bit.

Develop on a Windows 7 host computer, and produce Google Native Client binaries (32-bit + 64-bit) that use OpenGL ES 2 as the rendering backend. These web plugins can be run on Google Chrome on Windows, Linux and Mac OSX.

HTML5 + WebGL.

Develop on a Windows 7 host computer, and produce HTML5-based web applications that use WebGL as the rendering backend. These web pages can be displayed on Firefox, Chrome, Opera and Safari browsers on Windows, Linux and Mac OSX.

Android + OpenGL ES 2.

Develop on a Windows 7 host computer, and produce Android NDK-based applications that use OpenGL ES 2 as the rendering backend. These applications can be run on Android OS 2.3.3 (Gingerbread) and newer.

Mac OSX + OpenGL 3 + 64-bit.

Develop applications for Apple desktop Mac OSX, using XCode. These applications use OpenGL 3 as the rendering backend.

Apple iOS + OpenGL ES 2.

Develop applications for Apple iOS mobile devices, using XCode. These applications use OpenGL ES 2 as the rendering backend.

Linux + OpenGL 3 + 64-bit.

Develop applications for desktop Linux, using the superior Linux command line tools. These applications use OpenGL 3 as the rendering backend.