jfreax / libgdx-cpp

gdx++ is a port of the awesome java libgdx 2d and 3d engine for C++ so we can run it on desktop, android and ios (hopefully)

gdx++: libgdx C++ port

Dependencies (Linux/Ubuntu)

• cmake
• libsdl
• libgles1-mesa-dev
• libgles2-mesa-dev
• libopenal-dev
• libvorbis-dev
• libopenal
• libvorbisfile-dev
• zlib1g-dev

Building GDX++ (Linux/Ubuntu)

Assuming you have the latest Android NDK on "ANDROID_NDK_HOME" and the android SDK on "ANDROID_SDK_HOME"

Optional: I'm installing the builded libraries and includes under build/local for convenience purposes as you won't need to sudo to install them.

git clone git://github.com/aevum/libgdx-cpp.git 
mkdir -p build/gcc/gdx build/android/gdx build/local

cd build/gcc/gdx

cmake ../../../libgdx-cpp -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=../../local

make install

cd ../../android/gdx

cmake ../../../libgdx-cpp -DCMAKE_TOOLCHAIN_FILE=../../../libgdx-cpp/cmake/android.toolchain.cmake -DANDROID_NDK=ANDROID_NDK_HOME -DCMAKE_BUILD_TYPE=Release

make install

Using GDX++ on your own projects

On a typical CMake project that would be using GDX++, first you have find the library:

on CMakeLists.txt

set(GdxCpp_USE_BOX2D TRUE) #optional: use this to enable Box2D and his Gdx layer
find_package(GdxCpp REQUIRED TRUE)
include_directories(${GDXCPP_INCLUDE_DIR})

If the library is not on a default location (/usr, /usr/local) you can specify a flag named GDX_ROOT pointing to the installation root or GDX_SOURCE pointing to the library source folder.

To actually build, you'll have to use a custom macro that handles the way the libraries are generated on it's different targets:

#If you used the finder the macros required to create cross platform items are already included, so
#to generate an "executable" (this setting will be changed to a shared library on android and a bundle on iOS), add the folowing code:

set(SOURCES
a.cpp
b.cpp)

set(HEADERS
a.hpp
b.hpp)

gdx_setup_target(mytarget EXECUTABLE "${SOURCES};${HEADERS}")

#pay attention to the quotes and the semicolon while passing variables as parameters to the macro (This is a cmake limitation).

#then add linkage normally:
target_link_libraries(mytarget ${GDXCPP_LIBRARIES})

#to generate a shared/static library (note that a shared library on iOS will be converted to a static one)
gdx_setup_target(mytarget STATIC "${SOURCES};${HEADERS}")
gdx_setup_target(mytarget SHARED "${SOURCES};${HEADERS}")

and when running the cmake command:

cmake -DGDX_ROOT=build/local REST_OF_CONFIG_FLAGS

or:

cmake -DGDX_SOURCE=~/sourcecode/libgdx-cpp REST_OF_CONFIG_FLAGS

Differences from libgdx

• The texture class constructors that received an managed texture data had to be changed to static constructors. This is because C++ contruction blocks us to use shared_pointers, so we had to make it two-phase-like. So instead of calling the constructor, you'll have to call, for example:

Texture::newFromFile()

with the same parameters that you would expect on the constructor.

• The pixmap class was converted to an interface

Analogically, the calls to create an PixMap now are:

Pixmap::newFromFile()
Pixmap::newFromPixmap()
Pixmap::newFromRect()

• The Pixmap class has turned into an interface. This had to be done because we can have different pixmap backends (currently we have Svg and Gdx2d). The gdx_cpp::Graphics interface now have to handle the TextureData and Pixmap resolution and creation. This was made to decouple the texture class from determining how to load and create TextureData (etc1, wich is not supported in all platforms per example).

What's working

• The linux backend has input, file and audio working
• The android backend has input, file and audio working
• SVG support through AntiGrainGeometry

What has to be done

• Backend polishing. Seriously, it's working, but there is a lot of stuff that is ugly and in a haste.
• iOS support
• GLES 2. Check if it's working
• etc