Camera not scrolling properly

I am just getting started using Physics Helper and have a question regarding the camera. I have created a simple ball that has a force applied to it when keys are pressed to get it to fly around the screen. When I attach a camera to the ball
and run the program the screen does not scroll to the ball (it moves in the direction of the ball but not far enough to keep it within the screen). Am I doing something wrong?

I had a similar problem when I was first trying to use the CameraControllerMain class supplied with the library. After a bit of debugging, I noticed the problem arose from the following two statements:

I'm messing about with the same thing and having trouble. Mccabela, there are no properties on the camera at all, so there is nothing there to change. I would have to import the source and rebuild it. Which brings me to a different question:
where the good golly gosh (excuse my foul language) is the source code installed to?! I cannot find a separate download for the latest version either so I am assuming it is copied somewhere for me as well.

Thank you for the pointers, both of you!

*Edit* Found it, literally seconds after the post. Feel rather stupid...

There are definetly properties on the camera, but I'm deving in visual studio silverlight so your tool may be different. Examples of these properties are below as well as the properties in my post above.

Ah I see, you aren't using the camera behaviour at all, just the CameraControllerMain object? I wasn't aware we could just plug one of those in and get real control of it. Is the implementation of that just as you have stated above - create
the object and set it's target? If I do use this would I then no longer need the behaviour attached as well?

Lots of questions, sorry! Hehehe. I tried working around the camera by building my own method using canvases. The performance on the phone was unacceptable, sadly.

Yes you can just use the CameraControllerMain object and not use the Behavior. The only way I could get it to work, however, is to use the code posted above by mccabela in the first loop of your application. So when the first loop runs you can
then initialize and set the target of the CameraControllerMain.

The bad news is that it runs at too poor a performance level on my HTC HD7 (which is poor performing anyway). My scene is 4 rectangles and one isosceles triangle falling under gravity. If I take the camera off, everything performs smoothly.
I've tried to do the camera myself through moving canvases but this performs poorly too. I'm now going to try this in XNA and pray it performs better.

I'm building a prototype that will be using the camera as well. I have a samsung focus. Now I'm worried because of your last post. I don't want to get so far ahead and publish a game only to find out I get tons of reviews
from those with the HTC HD7 about perf issues. I would love to give what you have a shot on my focus (your basic scene etc) and get back to you with what I find and maybe tweak it so the perf is good on both of our phones. If we start just with
basic shapes etc like you mentioned and get all the perf issues sorted then we can go our own ways after that. I would love to help! FYI - I'm also working on animations within elements that have the physics object behavior as detailed in this
post http://physicshelper.codeplex.com/Thread/View.aspx?ThreadId=244918

I did some testing with the camera working/tracking properly as well. When you set Application.Current.Host.Settings.EnableRedrawRegions = true; you can see what is being redrawn every frame. For every frame that the camera moves it redraws
all elements that have a physicsbehavior on them, even static ones. For the most part that can be ok, but, once you start to have non static elements collide and bounce around on the screen then perf gets bad quickly. Simply turn on the redraw
regions and you will see whats going on. Where it can bee good perf is if your elements dont touch each other, once they touch eachother they combine to create a much larger rectangle that gets drawn to the screen. You can see this by putting three
rects on a canvas and have the middle one (with the camera) fall in between the other two, the only thing being drawn is the elements themselves.

I'm assuming how things get drawn in XNA would perform much better but maybe not for 2d sprites.

Andy, that worked a treat. It's now performing exactly as I would expect it to even with the camera.

I'm still amazed at what something small like this can do to the performance. When I tried my canvas method (moving an inner game canvas around in an outer "view-port" canvas using left and top) the performance was awful, yet the calculations for it
were trivial. I'm from a web/silverlight development background and so graphics have never really come into it before. I feel I need a good book to catch up!

Again, thanks for the advice. Intrawebs, you mentioned wanting to test my scene - I may as well post the xaml, its so small. With the bitmapcahces on though it works fine, even on my HD7.

I've tried the suggestions posted on this thread and have managed to get my camera to focus on my character. The problem comes about when I move the character (ApplyImpulse). The camera barely moves (it does slightly), yet the player moves off screen. Is
there a way to keep the camera stuck to the player so that the player remains in the middle of the screen? I'm using this in the timer loop (from the example above)