Saturday, April 24, 2010

BallDroppings for Android Update 1.1

BallDroppings for Android received its first substantial update today. The primary feature addition was the ability to share the worlds you create with others via email. The world is sent as a binary attachment that the recipient can open if they also have the BallDroppings full version. They can then save it on their own device if they want. Here are some screenshots:





The next nice addition was thumbnail previews of worlds that you have saved on your device. This makes it much easier to find that awesome creation that you forgot the name of.



There were a couple of minor changes as well. For example, the option for stereo sound has been moved from the Sound settings dialog to an application preference in the new Preferences screen, which you can get to via the menu. I figured that this was a setting that someone would probably want to set globally anyway. Calibration of tilt gravity has also been moved to the preferences screen, since it's usually a fire-and-forget operation.



What about the feature listed in the app description that says "Screen size independence"? Well, this is directly tied to the ability to share worlds with others. Since not everyone has the same size screen on his or her Android device, something had to be done to make the world coordinate system uniform across all devices. That's exactly what this feature does - all worlds will behave and sound the same for everyone now.

An unfortunate side-effect of screen size independence is that any worlds you saved on your device before this update will need to be converted to the new format, but only if your device has a screen larger than the "default" Android size of 480x320. Users with screens larger than this will have their worlds scaled-down to fit in the new coordinate system. This one-time operation happens during the database upgrade process that takes place the first time you open the new version of the app. Converted worlds will look mostly the same as before, but they probably will not behave or sound like they did since the physics of the balls is very sensitive to the slightest difference in the position and orientation of the lines.

I apologize for this inconvenience - it's possible that someone's masterpiece could be ruined. But I felt this was a necessary evil in order to prepare BallDroppings for many exiting new features, such as multi-player and sharing worlds on an online gallery.

Oh, and one more thing that you might miss if you don't look closely. The Physics screen no-longer has the Tilt toggle button for tilt gravity. Instead, there is now a Gravity Mode chooser that will allow for more gravity variations. (Currently the only options are the ones that were there before: Downward and Tilt).



I hope you enjoy the new features. Now I'm off to work on the next release!

Wednesday, April 7, 2010

BallDroppings for Android Released


Today marks the release of BallDroppings, Tesuji Games' first mobile toy for the Android platform. I first encountered this delightful game when it appeared as one of the first Google Chrome Experiments when the Google Chrome browser launched. I was immediately addicted and I knew that it would be a perfect fit for a mobile game.

BallDroppings was originally created by artist and designer Josh Nimoy in 2003, and it has been ported to many platforms over the years. Many thanks to Josh for allowing Tesuji Games to develop the official Android version.

Here's a demonstration video that shows just about every feature of the initial release:



BallDroppings is available for Android versions 1.5 and up, and comes in both Full and Lite versions. See the BallDroppings page for more information. Or scan the barcodes below to go straight to the Android Market and join the BallDroppings phenomenon!

BallDroppings (full version)


BallDroppings Lite

Monday, April 5, 2010

2-D Graphics on the Droid: After the Storm

My last post generated quite a stir over the weekend, with many able to reproduce similar results to mine but wondering whether it really matters. Others swear that they don't see any negative impact to their 2.1 experience on the Droid. A commonly offered explanation is that perhaps a 30fps cap was put in place in order to provide better battery life and possibly more responsiveness to touch input.

Here's why I don't buy that explanation. Something many others have noticed (and that I didn't stress enough in my initial post) is that there is quite a bit of fluctuation from 30fps to 60fps and back at seemingly random times. This is worse than just having a 30fps cap since it causes a jerky effect in some apps (not all applications, just some).

Others have suggested that devices such as the Droid and Nexus One are "fill-limited" to 30fps. I asked Chris Pruett, Google's Android Developer Advocate (and author of the awesome Replica Island game) about this. He confirmed that this is the case, but only for OpenGL (3-D) graphics. He said that since the Droid and Nexus One have such large screens, the bottleneck for 3-D graphics on those devices is actually writing the pixels to VRAM. Ed Burnette, author of the excellent book Hello, Android also confirmed this for me. Thanks to both guys for their help.

In any case, my test application runs at a solid 60fps on the Nexus One. So it seems "fill-limiting" doesn't explain the 2-D graphics issues either.

I logged a bug in the Android database at Google Code. It's been assigned to a developer for inspection. If you'd like to follow the status of the bug, go here and vote for it by "starring" it.

Friday, April 2, 2010

2-D Graphics Slowdown After Motorola Droid 2.1 Update

UPDATE: I have logged a bug in the Android database at Google Code. It's been assigned to a developer for inspection. If you'd like to follow the status of the bug, go here and vote for it by "starring" it.

Tesuji Games is nearing the release of its first "mobile toy" for the Android platform. Since the primary development phone around here is the Motorola Droid, I was excited to see Verizon begin rolling out the upgrade to Android 2.1 this week. Although I haven't yet received the upgrade, a friend has, and the results were...well, disappointing. Oh, I have no problem with the new features - they seem to work fine. And the live wallpapers? Very nice. My problem is with the performance of my application, which sees its framerate cut virtually in half when run on a Droid with 2.1.

Here is a video I made of two Droids running a test app I wrote to demonstrate the issue. (No, this isn't the eagerly anticipated debut release from Tesuji Games :-)



So what's going on? Both phones have virtually no other apps running (just what's necessary for the operating system to function). The test application is doing about as little as it possibly can do, at least from a game perspective. There is a loop that draws a black background bitmap, then the moving dot, and finally the text to display the frame rate statistics. Most games have a lot more work to do for each frame than this, so it would seem that the best frame rate one would consistently be able to achieve on a 2.1 Droid is 30 FPS. In case you are new to game design, that's not a particularly impressive number. 60 FPS is the accepted standard for smooth game play.

I did some digging with the Android debugging tools and found that there is indeed a difference in the CPU usage profile between the two phones. The process for the test app is called "org.lagtest". Check out these awesome pie charts (click for larger versions):

Droid with 2.0.1:


Droid with 2.1:


It looks as if on 2.0.1 the application is given more CPU to work with, and the "Idle" slice is smaller. (Why does Idle need so much time?) Still, the charts don't seem to explain the drastic difference in frame rate.

Just for grins, I snagged my wife's HTC Droid Eris with Android 1.5 to test on, much to her chagrin (At least she wasn't in the middle of composing an email):


Note that the Eris, which is significantly slower CPU than the Droid was still achieving 59 FPS consistently while running other apps such as email and weather, etc.

Anyway, if you want to check this out for yourself you can get the source code (as an Eclipse project ZIP) for the test application here.

If you just want to run the test on your phone, you can download the APK here.

If anyone has suggestions for a way around this, I'm all ears.