Building RTBareBones on Linux and a small fix

[Aki Koskinen]

Hello everybody, new first time poster here

I checked out Proton source code yesterday and started tinkering with it. The first thing I set out to do was to build the Android version of RTBareBones and try it out. As my development environment is Linux I had to try things out a bit in order to get things running. By following the instructions for Windows [1] and looking at the various .bat scripts this was actually very easy (way easier than on Windows actually, since Android NDK usage on Linux is so much easier).

I did have to do one small change to the source code. The file shared/GUI/RTFont.h includes RTFontFileFormat.h but the file name is actually rtfontfileformat.h – the only difference being the case of the letters. I changed the include to the lower case file name but as good a change would be to change the rtfontfileformat.h file to CamelCase. This discrepancy obviously makes no difference on Windows but on Linux where file name case matters it stopped the compilation. I leave it to Seth to decide which change to make to the source code – do you prefer CamelCase headers or is rtfontfileformat.h lower case for some reason.

With that change in place I run these commands:

$> cd RTBareBones/android
$> android update project -p .
$> ndk-build
$> mkdir -p assets/interface
$> cp ../bin/interface/* assets/interface/
$> ant debug

That produced the .apk file which I was then able to install to a device and run. Easy enough

Running 'android update project -p .' modified RTBareBones/android/local.properties to have the correct Android SDK location – it says in the file comments that this file shouldn't be checked in to a version control system in the first place

I did have the latest versions of Android SDK and NDK setup and in use already before starting this, so that eased things up compared to the Windows quide [1].

Next I'm thinking to try to run the barebones example on a Linux desktop which I suppose will need a bit more coding...

Cheers, Aki

[1] http://www.rtsoft.com/wiki/doku.php?...:android_setup

[Seth]

Thanks very much for the info! - I've gone ahead and changed rtfontfileformat.h to RTFontFileFormat.h on svn.

Hmm, didn't know about 'android update project -p', I should probably kill local.properties as you suggest and possibly have that run every time it's built... one less thing to worry about.

[Aki Koskinen]

Thanks for the reply.

Thanks very much for the info! - I've gone ahead and changed rtfontfileformat.h to RTFontFileFormat.h on svn.

Bit of a mistake there: the file is now called RTFileFormat.h in svn – missing "Font" from between.

Hmm, didn't know about 'android update project -p', I should probably kill local.properties as you suggest and possibly have that run every time it's built... one less thing to worry about.

It's enough to ever run the 'android update project' command only once. Unless you change the Android SDK location, the Android build target version or something similar.

In other news: today I've been hacking together a Linux desktop version of the barebones example and after a lot of copy-pasting code (from the WebOS side mostly) I managed to get it running It's using SDL like the WebOS version so it was mostly just copying stuff and commenting out things that didn't make sense to me. What I've got now is the barebones example running on a window and with ESC it terminates. Animations of the example seem to run. I don't really know what else works and what not.

That's enough for today, I'm off to bed now

[Seth]

Bit of a mistake there: the file is now called RTFileFormat.h in svn – missing "Font" from between.

Oh god, arghg, sloppy. :wheelchair: Fixed...!

It's using SDL like the WebOS version so it was mostly just copying stuff and commenting out things that didn't make sense to me. What I've got now is the barebones example running on a window and with ESC it terminates. Animations of the example seem to run. I don't really know what else works and what not.

Excellent.. hmm, yeah I hadn't really though of taking advantage of SDL for a linux version, but it makes a lot of sense.

One problem I assume you'll hit when you get to other samples is the command line util RTPack.exe - (turns jpgs/pngs into .rttex optimized texture format, converts bmfont files to .rtfont, etc) - without it there is no way to build resources in linux.

However, in theory it CAN be tweaked to compile in linux (its source is in tools/RTPack), it does require Clanlib V1.X though. It does use PVR libraries to output pvrct compression which I don't think have linux versions, but that support could be #ifdef'ed out, ... I never use it anyway.

It's enough to ever run the 'android update project -p' command only once.

My thinking is by putting that in the normal build scripts people would never have to even think about running in once - aiming for "easy as possible", but with Android setups.. man, long way to go.

Anyway, good stuff.

[Aki Koskinen]

One problem I assume you'll hit when you get to other samples is the command line util RTPack.exe - (turns jpgs/pngs into .rttex optimized texture format, converts bmfont files to .rtfont, etc) - without it there is no way to build resources in linux.

However, in theory it CAN be tweaked to compile in linux (its source is in tools/RTPack), it does require Clanlib V1.X though. It does use PVR libraries to output pvrct compression which I don't think have linux versions, but that support could be #ifdef'ed out, ... I never use it anyway.

Third day in a row, third project compiling on Linux Today I tweaked the RTPack tool to compile on Linux. It turned out Imagination provides the PVRTexLib for linux too (even both 32 and 64 bit versions). So I didn't have to ifdef any functionality out. I haven't yet tested the tool though. It compiles and when run without arguments it prints the help text. That's precisely how much I know currently. Tomorrow I'll check if the functionality also works.

Btw. I have been using CMake for the build scripts. There are now build scripts for the barebones example and the RTPack tool.

Next I'll check if RTPack really works here too and try to get the RTSimpleApp running on Linux. After that I could clean up the changed code and scripts a bit and start submitting patches.

[Seth]

Excellent!!

[Aki Koskinen]

OK, seems that the Linux version of RTPack did it's job. At least RTSimpleApp seems to be able to load the image and font resources which I think prooves it

I also tried building and running the RTLooneyLadders on Android. It seemed to compile, install and run just fine but it crashed a lot. No idea why. I used a Samsung Galaxy Tab 10.1" tablet. I didn't yet do a build script for LooneyLadders for Linux so I don't have any results on that.

I have been cleaning up the code I have changed and I could start submitting some patches. I was thinking of making five patches out of the changes I have currently. The first one is attached to this post. I'll submit the rest in individual posts with a short explanation what the patch is about.

Note: I have only tested the Android and Linux builds with these changes. I tried to make the changes such that the Windows and other versions aren't affected but these aren't tested since I don't have a Win nor Mac system. It's good to test that the Windows and other versions aren't ruined by these changes before submitting to svn.


The attached patch makes changes to files in the 'shared' directory.
1) The biggest change is the addition of shared/linux/LinuxMain.cpp which initializes the graphics system for Linux desktops.
2) A new preprocessor definition RT_USE_SDL_AUDIO is introduced and used in shared/Audio/AudioManagerSDL* to possibly enable the SDL audio system on other than WebOS systems too.
3) In shared/Audio/AudioManager.h the AudioHandle type is now defined as uintptr_t. Pointers to various objects are cast to AudioHandle throughout the code. The previous definition uint32 is too short on 64 bit systems and might cause precision loss. uintptr_t should be the same size that void* type is on all systems. (This change isn't Linux specific in any sense but because of the different size of pointer types in 32 and 64 bit architectures – regardless of the OS. I just happen to have a 64 bit system...)
4) Other minor changes include adding the std namespace and some letter case changes in various places to get stuff compiled.

Note: the LinuxMain.cpp version in this patch hardcodes the window size to 320x480. A same kind of size selection logic what is in shared/win/app/main.cpp should be added here too. Also the various shorcut keys and possibly other features found in the Windows build aren't working on this Linux version. I'll add these features later once I figure out what all features the Windows version has.

[Aki Koskinen]

This patch modifies the files in tools/RTPack directory so that it builds on Linux. The changes in this patch include:

1) Added CMakeLists.txt and build.sh to make building on Linux easy. Note that build.sh is supposed to be exacutable (it says so in the patch file (*) but I don't know if that notion goes all the way to the repository). Short build instructions in ReadMe.txt.
2) Put Win specific fopen and vsnprintf variants inside preprocessor guards and use the C standard ones on non-windows systems (windows could probably use the standard ones as well but I left it unchanged since I didn't want to touch the windows version without knowing all the possible details).
3) The way of accessing PVRTextureUtilities has apparently changed in PVRTexLib version 3.20. Added a preprocessor check that should work with both the old and new interface but untested on PVRTexLib versions < 3.20.
4) Added std namespace and some letter case changes in various places.

Note: all the cmake scripts for Linux in this and other patches use system wide zlib libraries and headers. Hence the resulting executable is dynamically linked against zlib instead of building in the code to the binary. I didn't check if there were any changes made to the zlib code bundled with Proton source and if there is a good reason why that source should be used. I was thinking to also dynamically link the boost stuff but didn't do that yet. Currently boost stuff is build in to the binaries from the code bundled with Proton source.

(*) Excerpt from the attached patch around line 261:

Property changes on: tools/RTPack/build.sh
___________________________________________________________________
Added: svn:executable
   + *

[Aki Koskinen]

This patch adds a cmake build script for linux for the RTBareBones example project. No code changes were needed.

Also added a small set of instructions to RTBareBones/android/readme.txt on how to build the Android version in Linux.

[Aki Koskinen]

This patch adds a cmake build script for linux for the RTSimpleApp example project. Few code changes made:
1) Use AudioManagerSDL on Linux.
2) If playing of the mp3 fails, try to play the ogg.

[Aki Koskinen]

This patch adds a couple of tools that can be used on Linux. They are called buildAndRun.sh and update_media.sh and they are placed in tools/linux directory. Both scripts should be executable (once again, says so in the patch).

The buildAndRun.sh script does what the name says: builds and runs a project. It calls the needed cmake and make commands for building. It also calls the update_media.sh script which is similar to the update_media.bat scripts for Windows.

There aren't any usage instructions for either script anywhere but those could be added to the wiki for example.

To note: update_media.sh (and hence buildAndRun.sh also since it calls update_media.sh) isn't safe for RTBareBones since it erases the bin/interface directory which is svn controlled. This isn't checked or told anywhere

[Seth]

Awesome work. Going to commit everything shortly.

To comment/answer misc things:

A new preprocessor definition RT_USE_SDL_AUDIO is introduced and used in shared/Audio/AudioManagerSDL* to possibly enable the SDL audio system on other than WebOS systems too.

Good - that's what I was thinking too.

Note: the LinuxMain.cpp version in this patch hardcodes the window size to 320x480. A same kind of size selection logic what is in shared/win/app/main.cpp should be added here too. Also the various shorcut keys and possibly other features found in the Windows build aren't working on this Linux version.

One option to reduce duplication (and introduce more #ifdef ugliness but.. meh..) is require main.cpp to be added - it's what I did for the webos simulation (you'll see a #ifndef RT_WEBOS that ignores the bottom 6/7ths of the file). Then, calling InitVideoSize() will set it up so GetPrimaryGLX() and GetPrimaryGLY() return it. Not a must or anything!

all the cmake scripts for Linux in this and other patches use system wide zlib libraries and headers. Hence the resulting executable is dynamically linked against zlib instead of building in the code to the binary. I didn't check if there were any changes made to the zlib code bundled with Proton source and if there is a good reason why that source should be used. I was thinking to also dynamically link the boost stuff but didn't do that yet. Currently boost stuff is build in to the binaries from the code bundled with Proton source.

I have made zero changes to zlib, libjpg, libpng, boost so feel free to use official versions and not my included ones. The windows projects just statically link the included zlib.lib, and the iOS xcode projects link the zlib that is available on the phone - but platforms such as android, webos, playbook I don't know about (?) so I just include our own via source. (same goes for the other external libs, libjpg, etc) Optimally we'd use existing versions on each platform but when it's missing or whatever... yeah, directly including source is easy. As for the subset of boost I include, it's just to minimize the setup for windows people.. but being in the linux world you're used to scripts that download dependencies and whatnot so it probably feels a little strange and redundant to have all this stuff included.

Put Win specific fopen and vsnprintf variants inside preprocessor guards and use the C standard ones on non-windows systems (windows could probably use the standard ones as well but I left it unchanged since I didn't want to touch the windows version without knowing all the possible details).

I think Windows would be fine but I'm less sure about the other platforms... (like fopen_s vs fopen, right? ) Maybe it works everywhere, I just always step timidly when it comes to change because I expect one of the platforms to break everytime. I mean, Android only recently gave decent C++ support out of the box, was using a hacked version of the NDK for like a year so I could use boost.

Anyway, very impressed with how far you've got, looks like I'll be able to claim p+ supports 7 platforms...

[Seth]

Ok, committed patches, very smooth

[Aki Koskinen]

Ok, committed patches, very smooth

Good stuff.

Am I lacking some svn-fu or are these files missing from the repository:
- RTBareBones/linux/CMakeLists.txt
- RTSimpleApp/linux/CMakeLists.txt
- tools/linux/buildAndRun.sh

Also tools/RTPack/build.sh and tools/linux/update_media.sh seem to have DOS linebreaks in the svn which might cause some problems when trying to run them.

[Seth]

Hmm, very strange. The patch did create those files but I guess it didn't svn add them for me.. hrm. And I definitely did not edit the .sh files, the patch must default to the current os' line breaks when create text files (?). In any case, I think I've fixed it... I will give you commit access, it's probably the only way you can add something and not have me break it...

[Aki Koskinen]

Hmm, very strange. The patch did create those files but I guess it didn't svn add them for me.. hrm. And I definitely did not edit the .sh files, the patch must default to the current os' line breaks when create text files (?). In any case, I think I've fixed it...

Yep, everything seems to be there now. Great. Now it's my turn to get the rest of the examples to compile and run on Linux as well

I will give you commit access, it's probably the only way you can add something and not have me break it...

Sure. Just tell me what I can and can't do with those rights.

[sundar]

this is awesome stuff. i was hoping someone will port this awesome sdk to linux. great job

[Seth]

Ok Aki, I send you logon info to rtsoft@... (email from your profile here) .. if you haven't gotten it, please email me directly.