Cross platform SDK cheat sheet

Android

Build C++
Navigate to directory where the jni/Android.mk file is (there may be multiple projects -- do them in order of dependency).
Type into Terminal:
~/android-ndk-r8b/ndk-build

Get Crash Log Info:
Type into Terminal:

~/src/android-sdk-macosx/platform-tools/adb pull /data/anr/traces.txt .

This will put crash info into traces.txt

Determine where are a crash is in C++:
android-ndk-r7b/toolchains/arm-linux-androideabi-4.4.3/prebuilt/darwin-x86/bin/arm-linux-androideabi-addr2line -C -f -e libBMSnow.so 000708e6

Export a signed android apk:
Right click on the project in eclipse
Go to “Android tools”
Click export signed apk
Uninstall builds from device, and then use adb to install the signed apks for testing

Install a signed android apk:
~/src/android-sdk-macosx/platform-tools/adb install SWNookTab.apk

iOS

Create a pvr texture
Download PVRTexTool from http://www.imgtec.com/powervr/insider/powervr-pvrtextool.asp
From the command line use:
/Applications/PVRTexTool/PVRTexToolCL/MacOS_x86/PVRTexTool -f OGLPVRTC4 -i alley1icon.png -m -yflip0 -o ../GHBowlingiOS/alley1icon.pvr

MAC

Record a video
Go to applications and launch quicktime player
Run the mac build and resize the window to whatever
Quicktime menu bar: file, new screen recording
Click the little down arrow next to the record button to make it use microphone
Click the record button and choose record part of the screen.
Drag over the app window
Click record.

Touch all files in a directory
find . -exec touch {} \;

Get into Sandbox mode in GameCenter
https://devforums.apple.com/thread/168811?tstart=0

Submit a new binary
In dev studio, Product->archive.
When that build finishes, organizer shows up.
Click the new binary in organizer, and click distribute.
Select Mac App Store
Log in to itunes connect when prompted
Select the application.  You must have already set the app to ready for upload on the web site.

To fix “does not contain a single-bundle application” error
From Tim Swast on stackexchange: “Turns out it is an issue with dependent projects in XCode 4. If this happens to you, go through the Build Settings for all your dependent projects (e.g. static libraries) and make sure that the "Skip Install" option under "Deployment" is set to YES.”

To get a receipt during development:
1) Sign the app with a development provisioning profile (not retail)
2) Make the app exit(173); from main.
3) Run the app once from finder (not from xcode)

Windows

Make a DDS file
contrib/texconv.exe -f [format] -o [outputdirectory] [file]
for format, use BC3_UNORM for textures that have alpha, BC1_UNORM for opaque textures

Windows Phone

Add data file(s) to the project (the C# project)
-Make an empty folder in the project to put the file(s) into initially
-Select Add -> Existing Item on the empty folder
-Multiselect all files you wish to add.
-Next to the “Add” button, click the arrow, select “Add as Link”
-Multiselect all the files in the previously empty folder. Right click and select “Properties”
-Set “Copy to Output Directory” to “Copy if Newer” Close the properties window
-Drag the files to the actual folder that the game will be looking for them in (ex: SB in the SBPhone project)

Data file Protip for the WinPhone C# project editor: Let the editor help you pick the right version of the files.
If you are including files that are versioned across platforms, add the highest priority folder first. EG: Add files from the SBWinPhone directory, then the SBWin8 directory, then the SBMac directory, then the SBIphone directory.
When you drag from the dummy folder into the real folder, it will only copy items that do not already exist in the real folder. You can then remove the remaining items from the project.

Query memory use:
Windows::Phone::System::Memory::MemoryManager::ProcessCommittedBytes
(use %llu with printf)

Blackberry

To install a pre-built binary:
You can deploy your signed bar file using the blackberry-deploy utility included in the bin folder.   Follow the instructions here: http://www.tidevs.org/topic/6-how-to-deploy-a-bar-application-to-the-bb10-alpha-dev-device/  Make sure the device is in developer mode.

./blackberry-deploy -installApp -password DEVICE_PASSWORD_HERE -device IP_ADDRESS_OF_DEVICE -package /Users/YOUR_USER_NAME/Downloads/Apps_for_the_Dev_Alpha/Facebook.bar

Getting on the Mac App Store

Big Mountain Snowboarding was just released on the Mac App Store, 1 week late for the grand opening. We started on the port as soon as the "within 90 days" announcement was made.

Technical Difficulties

I talked about a lot of the details of the port in a previous blog post.

Playtesting and Revision

Big Mountain Snowboarding was created as a handheld tilt game. Obviously that's not the ideal control scheme for someone on a 27" iMac. I wanted to do something cool with the touchpad so we turned it into a joystick, and made a couple fallback controls for people who don't have a touchpad. We had some back and forth and some revision on some pretty bad early controls.

We then took a macbook over to the bostonindies demo night and got some people we don't know to play it. The people struggled with it. The controls were not good enough to release at that point, so we spent another couple days trying to improve it. They are much improved, but I'm not convinced they are awesome. We'll probably have to make a couple patches before we really get there.

Apple Approval

Our first attempt at submission happened on 11/19/2010. We never left the waiting for approval stage. I had made several improvements and decided to pull the app to upload another attempt on 12/1/2010. After a couple weeks of waiting we got a rejection because the .app name was not the same as the application name, "Big Mountain Snowboarding OSX". I fixed this and resubmitted. About another week later we were rejected for having "OSX" in the name. I think whoever said the names didn't match up could have also mentioned that the name was unacceptable, but ok.

On 12/30/10 we were approved and all set to be a launch title. Then a few days later I noticed a game-breaking bug that slipped in to the game when making the build to remove "OSX" from the name. We share our engine between all of the games we make and we don't branch, so development of one game can cause us some bugs in other games.

I submitted another build at about 3 in the morning of 1/4/2011, with the app store set to launch sometime on 1/6/11.

Actual Launch

We had to make the decision between missing the app store launch or shipping a broken build. We were worried about getting nothing but 1 star reviews early on killing any chance of future sales, so we removed the app from sale before launch. We watched 1 million downloads happen on the store the first day while not being a part of it. It was a tough call, and I'm still not sure which was right. I woke up early on Tuesday to pull the app and we had already sold 4 copies at $4.99 each.

I was getting a little anxious earlier today about whether or not being "developer removed from sale" was preventing our approval so I sent Apple a mail asking about it. I guess someone from Apple liked the game because we were approved shortly after and placed in the "Staff Favorites" section of all games. I also dropped the price to $0.99 for the launch to try to get us some initial chart placement.

I'm hopeful. BMS isn't the game I'd make from scratch for the Mac platform, but it wasn't a viable market back when we started. The more platforms with an audience available for the little guy the better.

Porting from iPhone to OSX

If you've followed us at all you know by now that I like porting to new platforms, at least new platforms that support C++. Every port seems to make the base engine a bit better, and it brings in a few extra bucks to support continued development. With the news of the Mac app store coming soon I had to jump on porting the Golden Hammer engine and Big Mountain Snowboarding to OSX.

Our engine started on Windows, moved to OSX (carbon), then to iPhone/iPad, then to Android. The OSX port was never really finished because the iPhone took off. Carbon is outdated technology (see below), so for the port back to OSX I started over using Cocoa.

The port isn't fully ready for release, but within a week I was able to get the game pretty much working. This was definitely the easiest port so far.

Carbon vs Cocoa (use Cocoa)

OSX supports two different platform layers, Carbon and Cocoa. Carbon is in C, only runs on 32 bit, and does not seem to be fully supported anymore. The Carbon implementation in my engine gets a ton of deprecated code warnings, and there's a Mac App Store requirement that apps not use deprecated technology. I have not seen an official and specific announcement from Apple on Carbon, but to be safe it's better to go with Cocoa.

Also, Cocoa is almost a direct equivalent of Cocoa Touch, the API used for iPhone development. There are a few little differences that I'll note in the next section, but for the most part you can make copies of your iPhone platform layer with different includes, fix the compiler errors, and be ready to go.

Cocoa vs Cocoa Touch

As I said, Cocoa is almost exactly like Cocoa Touch. For most of my classes I was able to just make a copy of the iPhone version, add some different frameworks, rename a couple classes and be good.

The frameworks I'm currently using are:

• Cocoa.framework
• OpenGL.framework
• ApplicationServices.framework
• OpenAL.framework
• AudioToolbox.framework
• AppKit.framework
• CoreData.framework
• Foundation.framework

Most UIKit classes have an AppKit equivalent. Instead of UIView, there's NSView. Instead of CGPoint, there's NSPoint. The first line of defense on a compile error is to stick an NS in front of the class name and see if that works.

32 bit vs 64 bit

This probably won't matter to most developers, but Cocoa will compile for 64 bit systems. We're doing some behind the scenes magic with pointers and such, so I had to go through the codebase and replace a bunch of long data types with int32_t and u_int32_t, and remove some of the more questionable pointer code.

OpenGL vs OpenGL ES

For a first pass implementation, you can think of OpenGL as a near direct equivalent to OpenGL ES1. This is a horrible simplification, and I fear a lot of OpenGL users coming at me with pitchforks for saying it. A better way to think of it is ES1 is almost a direct subset of the full OpenGL, and you can get ES1 code running on OpenGL pretty easily. I have not yet ported our ES2 shader code, so I can't comment much on that aspect.

The includes you want are:

• #include "OpenGL/gl.h"
• #include "OpenGL/glu.h"

Make a copy of your ES1 implementation, change the includes, and hit compile. You will get a ton of compile errors. Most of them are easy to fix. For any function or variable that has "OES" at the end of it, simply delete the OES part. For any function named something like "glFrustumf", delete the "f". This will take care of 99% of the compile errors.

I'm not quite 100% sure, but I don't think PVR4 support is available. If I'm wrong on this let me know! It would save me some work. Right now I just have uncompressed textures, but DXT support seems to be available for use.

OSX Input

Modern macs support multitouch through the touchpad. The gotcha is that the mouse needs to be over the window in order for the app to receive any touch events. I'm planning on supporting keyboard inputs for those without a touchpad, and making the game fullscreen so we can always get the touch events.

You'll want the following functions in your NSView:

- (void)mouseMoved:(NSEvent *)theEvent

- (void)mouseDragged:(NSEvent *)theEvent

- (void)mouseEntered:(NSEvent *)theEvent

- (void)mouseExited:(NSEvent *)theEvent

- (void)mouseDown:(NSEvent *)theEvent

- (void)mouseUp:(NSEvent *)theEvent

- (void)keyDown:(NSEvent *)theEvent

- (void)keyUp:(NSEvent *)theEvent

- (void)touchesBeganWithEvent:(NSEvent *)event

- (void)touchesMovedWithEvent:(NSEvent *)event

- (void)touchesEndedWithEvent:(NSEvent *)event

- (BOOL)acceptsFirstResponder { return YES; }

You'll also want to call these somewhere:

[window setAcceptsMouseMovedEvents:YES];

[view setAcceptsTouchEvents:YES];

Additional platform considerations

The straight port of snowboarding runs at 2ms/frame on my 13" macbook, or 500fps. This is without making any use of multithreading or doing any real hardcore optimizations anywhere. I think any halfway decent straight port of an iPhone app should run at crazy speeds on a low end Mac.

So is a straight port good enough? I have no idea and neither will anyone else really until the Mac App Store has been out a while. Is it competing with Steam and games like Half Life 2, or will the audience want smaller simple games? Can't tell yet! I'm exporting higher res maps and doing something in the middle.