Torque2D for Linux first release

Hello all,

After hearing about the buzz around SteamOS and how it would be nice to see Torque2D at least possible to run on those machines, I've created a branch for Linux support.

FPS dropped because taking the screenshot made the Torque2D window lose focus.

How to get it

To get this first iteration of Torque2D for Linux, go to the GitHub repository for my fork: github.com/camporter/Torque2D. You'll either:

1. Need to clone the repo if you want a fresh copy in a new folder

   git clone https://github.com/camporter/Torque2D.git

   then change to the linuxsupport branch with

   git checkout linuxsupport

2. Otherwise, if you already have a Torque2D repo setup and you have no trouble moving between git branches, you can quickly get the linuxsupport branch by first setting up tracking the linuxsupport branch in your repo:

   git remote add -t linuxsupport camporter https://github.com/camporter/Torque2D.git

   then fetching the linuxsupport remote branch:

   git fetch camporter

   then finally switching to the linuxsupport branch by doing

   git checkout linuxsupport

For those building Torque2D on other platforms, please test that I haven't broken your builds or caused any bugs. I'm contemplating grabbing a Mac Mini so that I can to make sure that OSX stuff doesn't break. Haven't bothered getting VS set up on Windows to make sure things still work, but they most likely do.

This build was done on top of the last commit on the current Torque2D development branch.

Changes in the first commit

1. Add new folder with makefiles (source/compilers/Make).
2. Move the 'box2d folder to 'Box2D'. Update all references to the old folder to the new folder in all makefiles, project files, and includes. Most platforms are not affected, since they have case insensitive filenames.
3. Fix up includes to match the case of the header file.
4. Fix OpenAL problems. We now expect to load libopenal.so.1 using standard paths or at least expect that it exist in the same folder as the executable. There's lots of ugly OpenAL stuff going on still, but I tested audio and it seems to be working fine.
5. Fix some other problems due to incompatibilities with gcc and also undefined standard C++ behavior (such as with dSprintf's use of vsnprintf in certain cases).
6. Fix minor issue with cpu freq reporting.
7. Ripped CD audio/Redbook out. Don't think anyone's going to miss it.
8. Other things I can't think of off the top of my head.

Known issues

1. No cursor! This can be solved by changing SDL_ShowCursor(SDL_DISABLE); to SDL_ShowCursor(SDL_ENABLE); in UInputManager::activate()
2. SDL 1.3 has lots of ugliness associated with it in the current code. The next piece of the project will be to get SDL 2.0 going. Ideally a lot of the current Xlib crap will be able to go away at the same time :)
3. There's lots of things that should be defined at the platform layer that don't exist at the moment. Most of these aren't heavily used by the current codebase or scripts that exist.

32-bit building

If you're like me and you run a 64-bit machine, you'll want to setup a build environment just for building 32 bit programs such as Torque2D. My preferred method is to setup a chroot for this purpose and manage and access it easily.

For Debian-based users, here's a slightly old article about doing this here: help.ubuntu.com/community/DebootstrapChroot. Replace 'hardy' references with 'saucy' if you use Ubuntu, otherwise you can get this same information for Debian as well. Other distros can try something similar, or a bit more complex way is to setup something like VirtualBox, however that is more painful when you just want your chroot to be able to access the files in your home folder directly and easily.

How to build

First, you'll need the libraries below (if you're using a chroot like I explained above, make sure you are logged in as the root user in your chroot when installing the necessary packages).

1. build-essential
2. libsdl-dev
3. libxft-dev
4. libopenal-dev
5. nasm

Then, in a 32 bit environment, change directories to engine/compilers/Make and run

make -f Torque2D.makefile debug -j<#CORES>

while making sure to replace the number of cores with however many you have to speed up the build process. With an 8-core i7, I get

real	0m26.881s
user	2m56.995s
sys	0m11.218s

which is pretty awesome in my opinion.

Running

After you've compiled the 32-bit binary, you should be able to run it in a 64-bit environment.

I haven't performed any tests on any drivers besides the proprietary Nvidia ones as shown in the output above. However, considering how well it runs (steady 60 FPS unless tens of thousands of sprites are on-screen), there shouldn't be issues.

Future Plans

Hopefully these changes can be merged into the official codebase at some point, but more work needs to be done first.

Now, how do I convince Valve to give me a dev Steambox to start testing on their official hardware and new controller? :P

Enjoy!