benbritten.com

Oops. In my haste to fix up the Snow Leopard issues in xTouch i neglected to notice that I had not included the OpenCV framework as part of the package. Thanks to Martin Kaltenbrunner from TUIO.org for finding that little omission.

If you already had OpenCV installed (as many of us do) then you probably would not have noticed, but it is kinda nice to have it all in one package when installing on new machines and stuff like that.

Anyhow, I update the link in the earlier post, and here it is again if you want the binary:

xTouchV1.01.zip

This seemed to work on my Snow Leopard laptop that did not already have openCV on it, so hopefully it will work for other people as well :-)

Cheers!
-B

And let me know if anyone finds anymore bugs :-)

Hey All!

Sorry this has taken so long. I had it sitting in my to-do pile forever. And I had figured out the problem, just not fixed it.

Thanks to Morgan at bluecrash.com for sending me an email to kick me in the ass and spend the ten minutes to fix it.

Anyhow,

If you are wondering what the problem was it was that I had forgotten to lock the CVPixelBaseAddress before trying to access the CV frame pixel data. (when grabbing frames off the QTCapture frame buffer)

On Leopard this worked fine (for some reason) but was wrong. Here is the proper way to go about it:

 
// Lock the base addy for the pixels
// or it will return nil
CVPixelBufferLockBaseAddress(videoFrame,0);
unsigned char * srcBytes = CVPixelBufferGetBaseAddress(videoFrame);
.
.
.
// dont forget to unlock it when you are done
CVPixelBufferUnlockBaseAddress(videoFrame,0);
 

And that seemed to be the problem on snow leopard. I know, lame and easy. So again my apologies for not just getting it done sooner.

Also, I do plan to release the code for xTouch, but it needs a refactor and a clean first, so that will have to wait. You can get the binary (works on leopard and snow leopard) here:

xTouch.zip

Cheers!
-B

Excellent! would love to have you!

Here is what I need:
Your device ID
An email address that works
Your name
The game you want to beta test for (I usually have more than one going at a time)

the last three should be easy, I don't even care if it is your real name. But the email has gotta work, or you will never get the links to the binaries.

As for the Device ID here is how you find that:

Launch iTunes.
Connect your device to your computer.
Select the device in the Devices list.
In the Summary pane, click the Serial Number label. It changes to Identifier.
Choose Edit > Copy.
Paste your Device ID into an email.
Be sure to include your name and device name in the email.
Sent that email to me, here: support@benbritten.com.

Please make the subject something like: "beta tester for Mole" or "beta tester for gamebooks" or whatever it is that you might want to be beta testing. Alternatively, subject lines like: "Ben, you are total awsomesauce" work as well.

Usually the beta builds come out every few days or so. You probably will get something back form me in a day or two and then you will get added to the big list I use to send out beta build notices.

Once you do get a build, you will need both the game binary and the provisioning profile.

Installing

You should have two files downloaded: whateverGame.app and the most recent AdHoc.mobileprovision file. (these are generally delivered together in a zipped bundle)

Unzip the bundle if you haven't already.

Open iTunes and drag the app and provision files onto the "Applications" item in the upper-left section of the sidebar named "Library". (It won't import if you drop it on the Playlists section. If the "Library" heading highlights when you drag them in, you've got the right place.) Give iTunes a few seconds to copy and process the app.
Plug-in your iPhone/iPod Touch and sync. (If you manually manage your installed applications, be sure to check the box next to the game in the Applications tab before syncing.)
If you get an error when syncing, make sure you have the newest .mobileprovision file downloaded. Copy it into your iTunes library and sync again.
Disconnect when the sync completes and fire it up!

Upgrading from a Previous Beta Version

(This is a weird process -- sorry.)
Download the newest version of the app and provisioning profile.
Unzip the app and drag the files into the Library section in the sidebar of your iTunes.
iTunes will copy app file, saying 'Processing: Snowferno.app'
Click "Replace" when told 'The application "Snowferno" already exists in your iTunes library....'.

Don't sync quite yet -- The weird part starts here:
On your device, in the home screen, tap and hold the game app icon for 2 seconds until the apps jiggle.
Tap the X to delete the game app, and tap "Delete" when prompted 'Deleting "The Game" will also delete all of its data.'

(Sorry, for now this is all part of the process. Some of our games store your progress on the server, in which case you wont actually lose anything, others dont, so you will)

Click the Home button to exit jiggle-mode.

Back in iTunes, *now* do a sync. IMPORTANT: if you manually manage your installed applications, you must visit your Applications tab before syncing and re-check the checkbox for the game. Deleting an app automatically unchecks that app's checkbox so you have to recheck it each time.
Now sync.

Sorry about that. Due to the way Unity is compiled into xcode, iTunes unfortunately doesn't recognize new versions of apps until they are official and acquired through the App Store. (or if someone can tell me how to force it to use the new one, then let me know!) For beta testing, this means we have to have you jump thru these hoops and delete and install fresh copies of the app each time.

Cheers!
-Ben

Some of you may have found your way here from my chapter on particle systems in Advanced iPhone Projects. If you have tried out that code in the simulator, and you are running in Snow Leopard, you may have noticed that the buttons have groovy patterns on them for some inexplicable reason.

This is because I made a minor error in the code, one of the most common ones that should never happen, but tend to happen in cases like these where I am writing code for a book and so it doesnt get tested nearly as well as it should. (which is my fault :-) No, it is not the dreaded one-off error, but the rookie mistake of not initializing my buffers before using them. To try and justify: when working with images, it is not generally necessary to initiaize the buffers to anything and it usually is just a wast of cycles since you often just write over the whole thing anyway (so why do it twice?). That and I borrowed heavily from Apple's sample code, and now I have learned my lesson (again :-)

In this case, because of the way I am drawing into the resulting CGContext, the old stuff not getting properly overwritten. (so it looks a bit like a multi texture, or an overlay)

The Badness can be seen here:

The buttons on the right are not supposed to have snowflakes in them.

Luckily, this render bug doesn't really effect the actual functioning of the code, just the look of it, and just in the simulator. However, the fix is good to have in there even on your device, so.. here it is:

 
		memset(spriteData, 0, (width * height * 4));
 

It needs to go in the BBMaterialController.m file, in the loadTextureImage: materialKey: method, right after we malloc the buffer for the sprite image.

 
-(CGSize)loadTextureImage:(NSString*)imageName materialKey:(NSString*)materialKey
{
	.
	.
	.
 
	// you'll want to add code that checks the dimensions and takes appropriate action if they are not a power of 2.
 
	if(spriteImage) {
		// Allocated memory needed for the bitmap context
		spriteData = (GLubyte *) malloc(width * height * 4);
 
		// clear the memory
		memset(spriteData, 0, (width * height * 4)); // <----------- ADD THIS!
 
		// Uses the bitmatp creation function provided by the Core Graphics framework.
		spriteContext = CGBitmapContextCreate(spriteData, width, height, 8, width * 4, CGImageGetColorSpace(spriteImage), kCGImageAlphaPremultipliedLast);
		// After you create the context, you can draw the sprite image to the context.
	.
	.
	.
}
 

Anyhow, there you go. Always initialize your variables :-) Once you have made this fix, you will be rewarded with a slightly less interesting, but correctly rendering app:

The Goodness:

This will also make the numbers on the bottom of the screen render properly as well, they were similarly being corrupted with bad starting data, so they were sometimes hard to read.

Cheers!
-B

It is xmas morning here in oz, so for those of you who celebrate that sort of thing, I hope you are having a fun one! For everyone else, I hope that the wintery holiday season is similarly lovely for you as well.

In any case, I managed to stay up very very late a few nights ago and went through the Molecules codebase and extracted the essence into what we are calling the uniTUIO community edition.

If you have not heard of this before, the basic idea behind uniTUIO is to have a nice set of scripts to allow you to easily implement TUIO based multi touch input into any Unity3d application.

If you dont have Unity3d or dont know what it is, then you really should go to www.unity3d.com and get a copy. It is crossplatform and the basic version is free (and it really isn't very basic, I built a couple complete games using that version (back when it was called the indie version)).

Anyhow, the home of uniTUIO is at the xTUIO.com website. Ultimately I will be publishing posts like this one up there, but for now, since it is still early days and not that many people know about xTUIO.com I will post this here and have sandor crosspost it there.

Currently the uniTUIO CE is comprised of a unity project which has a couple basic scenes and a couple dozen scripts. Also, I made a couple videos showing how to use the various scenes.

There are two basic methods to get at the TUIO event information.

The first one, which is used by the BBCrosshairController and BB3dCrosshairController scripts, is a simple polling method. These scripts have access to all of the touch information for the entire surface and can act accordingly.

These scripts call up to a singleton script: BBTouchEventManager. It is the touch event manager that actually takes the TUIO information and converts it into a BBEvent object, which basically means that it converts the information from TUIO form into a Unity friendly format.

If you are building a 'traditional' sort of unity game where you have a central character that you are controlling, then using this polling method makes sense. This is basically the same thing as using the Input class in unity or the iPhoneInput class in Unity iPhone.

One example of this is the particles scene which uses a script called the BB3dCrosshairController which polls for all available events and spawns a particle system under any touch events. using this method you can replicate all the fun 'fire from the fingertips' sort of MT demos in about 3 minutes. (or longer if you are like me and love to just tweak the particle systems for ever and ever to get them 'just right'. Note: the particle system that I did for the examples is not 'just right', i just threw some values at it so that you would have an idea of how to do it yourself)

However, in many multi-touch applications you tend to have dozens and dozens of objects in the scene that all need to be aware of any touch events that are interacting with them. In this case it does not make good design sense to have each and every object grab a copy of all the events and try to figure out if any of them apply to that specific object. Instead we have a central distribution point that checks the incoming events against the scene full of objects and sends out event messages as appropriate.

This is where the BBTouchable scripts come in. The BBTouchEventManager takes the raw TUIO events and raycasts through the scene looking for any objects that are both in a special 'touchableObjects' layer and have a BBTouchable script attached to them.

The BBTouchable script provides some overrideable abstract touch input handling methods. For the most part, when doing MT apps that deal with lots and lots of different objects that need touch inputs, you will be subclassing BBTouchable to get your custom functionality.

In the uniTUIO scripts I have made a few example subclasses of BBTouchable. one is called BBBasicTouchManipulation, and it provides any object with the basic single touch to drag/double touch to scale and rotate gestures that are very common in MT apps.

The second one, BBTouchableButton shows how you can make a button that lives in 3d space and reacts to touch events.

You should have everything you need to get started with Unity and TUIO now. If you have questions, dont hesitate to comment here or on the xtuio site, or email me directly, or pm me at the unity forums, or whatever.

Cheers!
-b