RTsoft Wiki

Use a svn client to checkout svn://rtsoft.com/rtsvn/proton to a directory. (ie, “c:\proton” - the checkout path filename should have no spaces)

The first example you should compile is RTBareBones. It's the simplest one, it's the app I use when porting to new operating systems or testing engine features.

RTBarebones is still around 40 “shared” framework source files, and one app level source file. (App.cpp/App.h)

It includes font loading, 2d blitting, and a super simple main game loop.

Navigate to /RTBareBones/windows/RTBareBones.sln and double click to open the solution in MSVC++.

Choose Debug GL from the configuration drop down.

Here is an explanation of what each configuration is (they all make Windows exe's btw, but different configs can help you emulate platforms better):

• Debug (or Debug Common) - Uses the PowerVR libgles library. Useful for debugging GLES specific issues, or testing loading of the .pvr texture format. (It's a compressed format specific to PowerVR, iOS can load them) Much slower than Debug GL. (Note: I don't think I can include .lib files from the PowerVR SDK, so this option probably won't work “out of the box”.. but here is how to set it up)
• Release (or Release Common) - Uses the PowerVR libgles library. You'll probably never use this.
• Debug GL - Most of your testing is going to be with this. Standard GL.
• Release GL - For a final Windows build this is what you should use.
• Debug WebOS - This config links with the WebOS “SDL like” libraries, useful for debugging WebOS specific issues. I don't have a “release WebOS”, not needed as the phone builds are done differently. If you have a gamepad plugged in, you can use it to fake an accelerometer.

Note from WoutervD - If importing the VS2005 project into 2010, you may need to set the bin directory as following:

←- not needed for VS2005!

Select the WinRTBareBones project, right click and choose properties. Select “All configurations” from the drop down and navigate to the general configuration properties page and set the output directory to “..\bin”.

Next, open main.cpp and double check what the screensize/mode is going to be. Main.cpp is actually shared between ALL the samples (and your own projects usually) so be careful with changes here.

Scroll down until you see something like this:

	AddVideoMode("Windows", 1024, 768, PLATFORM_ID_WINDOWS);
	AddVideoMode("Windows Wide", 800, 1280, PLATFORM_ID_WINDOWS);
        //OSX
	AddVideoMode("OSX", 768, 1024, PLATFORM_ID_OSX); 
	AddVideoMode("OSX Wide", 800, 1280, PLATFORM_ID_OSX); 
 
	//iOS - for testing on Windows, you should probably use the "Landscape" versions unless you want to hurt your
	//neck.
 
	AddVideoMode("iPhone", 320, 480, PLATFORM_ID_IOS);
	AddVideoMode("iPhone Landscape", 480, 320, PLATFORM_ID_IOS, ORIENTATION_PORTRAIT); //force orientation for emulation so it's not sideways
	AddVideoMode("iPad", 768, 1024, PLATFORM_ID_IOS);
	AddVideoMode("iPad Landscape", 1024, 768, PLATFORM_ID_IOS, ORIENTATION_PORTRAIT); //force orientation for emulation so it's not sideways);
	AddVideoMode("iPhone4", 640, 960, PLATFORM_ID_IOS, ORIENTATION_PORTRAIT); //force orientation for emulation so it's not sideways););
	AddVideoMode("iPhone4 Landscape", 960,640, PLATFORM_ID_IOS);
	AddVideoMode("iPad HD", 768*2, 1024*2, PLATFORM_ID_IOS);
 
	//Palm er, I mean HP. These should use the Debug WebOS build config in MSVC for the best results, it will
	//use their funky SDL version
	AddVideoMode("Pre", 320, 480, PLATFORM_ID_WEBOS);
	AddVideoMode("Pre Landscape", 480, 320, PLATFORM_ID_WEBOS);
	AddVideoMode("Pixi", 320, 400, PLATFORM_ID_WEBOS);
	AddVideoMode("Pre 3", 480, 800, PLATFORM_ID_WEBOS);
	AddVideoMode("Pre 3 Landscape", 800,480, PLATFORM_ID_WEBOS);
	AddVideoMode("Touchpad", 768, 1024, PLATFORM_ID_WEBOS);
 
	//Android
	AddVideoMode("G1", 320, 480, PLATFORM_ID_ANDROID);
	AddVideoMode("G1 Landscape", 480, 320, PLATFORM_ID_ANDROID);
	AddVideoMode("Nexus One", 480, 800, PLATFORM_ID_ANDROID);
	AddVideoMode("Nexus One Landscape", 800, 480, PLATFORM_ID_ANDROID); 
	AddVideoMode("Droid Landscape", 854, 480, PLATFORM_ID_ANDROID); 
	AddVideoMode("Xoom Landscape", 1280,800, PLATFORM_ID_ANDROID);
	AddVideoMode("Xoom", 800,1280, PLATFORM_ID_ANDROID);
	AddVideoMode("Galaxy Tab 7.7 Landscape", 1024,600, PLATFORM_ID_ANDROID);
	AddVideoMode("Galaxy Tab 10.1 Landscape", 1280,800, PLATFORM_ID_ANDROID);
 
	//RIM Playbook OS/BBX/BB10/Whatever they name it to next week
	AddVideoMode("Playbook", 600,1024, PLATFORM_ID_BBX);
	AddVideoMode("Playbook Landscape", 1024,600, PLATFORM_ID_BBX);
 
	string desiredVideoMode = "iPhone"; //name needs to match one of the ones defined above

This is how you can test “virtually” test many devices with your Windows builds. After things look good, then you can do tests on the device. Using this method saves a ton of time because MSVC debugging is fantastic, and the change/compile/test process happens in seconds rather than minutes.

Make sure you have desiredVideoMode set to “iPhone”.

Compile and run. You should see the fps near the top, some rects, a rotating triangle and some colored text scaling up and down near the bottom:

Because we chose iPhone, the screensize is 320×480. If you change to “iPad” and recompile, it will be 640×960. You can add more resolution by adding another “AddVideoMode” call.

If you ran this app on a real iPhone, tilting the device would cause it to rotate to each orientation automatically. (You can disable that later or limit to only landscape modes)

For Windows there are some hotkey equivalents for rotation, try hitting these:

• Ctrl-P - Portrait (same as how it starts up)
• Ctrl-U - Upside down portrait
• Ctrl-R - Right landscape
• Ctrl-L - Left landscape
• Escape - Quit

NOTE: The “fake rotate the screen” testing keys above only work on Windows, and only on some setups, such as iPhone and iPad.

RTBareBones is pretty simple, the app specific code is just two files, App.cpp and App.h. (note, the physical source is located in /RTBareBones/source)

The two functions to look at are App::Update() and App::Draw(). Replacing the guts of those two areas is a good place to start experimenting.

It also has code to read some keys, the touchscreen, and detect shaking. Check the debug log to see the messages.