gdx++: libgdx C++ port

Dependencies (Linux/Ubuntu)

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

Creating your cross-platform project (the easy way)

You can use the python gdx-wizard script that will setup a project containing all dependencies, paths, symbolical links and assets already built in. You can just modify it's source to your needs after that. A sample call to setup an ios and an android project on a Mac would be:

#call this on libgdx source folder
python gdx-wizard.py --gen-mode ios,android --root-dir ~/projects/ --project-name Test  \
--android-sdk /data/applications/android-sdk-linux_x86/ --package-name com.aevumlab.test \
--android-ndk /data/applications/android-ndk/ --ios-sdk-ver 6.0 --android-target android-10

To generate for android and linux, just change the gen-mode to android,linux. You can safely call the script many times as it will try to only include missing stuff, never remove them. So you can start on linux and later on migrate to Mac without problems (I hope :)

iOS Note

When using Xcode to edit your new project, ensure that the "Base SDK" configuration is correctly pointed to the iOS SDK. I haven't found a way to magically set this parameter from cmake yet, so this is needed by now.

Android Note

You'll still have to add the Gdx-Android backend which is located under src/backends/gdx-cpp-backend-android/android_support to your eclipse workspace and add it as a library dependency to your project.

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 built 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

ANDROID_NDK=PATH_TO_ANDROID_NDK cmake ../../../libgdx-cpp -DCMAKE_TOOLCHAIN_FILE=../../../libgdx-cpp/cmake/android.toolchain.cmake -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
• iOS support
• GLES 2

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.