BEPUphysics

Hi,

I have big performance problems on wp7, but none in windows versions of the same game. Actually, the sample available in this website for WP7 goes very slow in my machine.

I asked about this in Creators forums, and all the people says that the emulator doesn't work very well. But I'm affraid, I'm investing resources (time) trying to create a game for WP7 that I don't know if it will be able tu run fluently...

Does this sample work smoothly in your machines at least? If so, wich hardware do you have?

I run the sample with a Centrino 2, 4GB Ram, and a graphiscs card with 512MB.

Thanks

Without the real hardware, it's hard to know exactly how fast the games will really run. The emulator is not suitable for performance profiling. Additionally, even on an 'empty' game it can look less smooth given the refresh rate and emulator drawing system.

That said, on my Q6600/8800 GTS 512 (running the engine on only a single thread of course), the emulator can stack up 30-50 blocks with what appears to be reasonable fps. It doesn't dip substantially lower than the baseline drawing speed, at least.

Keep in mind that the BEPUphysicsPhoneDemo uses internal timestepping to reach an internal timestep duration of 1/60 seconds, which requires two updates per draw. This helps out with accuracy and stability, but if you can handle some instability, try using 1/30f for a timestep duration instead. This will do almost half as much work.

With a timestep of 1/30f and IsFixedTimeStep = false, you can also disable the engine's internal time stepping. It will run as fast as it can, but when things get computationally hard, the game will smoothly slow down.

I wouldn't expect a phone to be able to come anywhere close to the performance of even an old desktop computer, so you do have to be a little careful about how much work is required.

Well, I heard in a XNA for WP7 conference that the performance would be better that XNA has in XBOX 360 (that is actually worst than in PC)... it is all a mistery...

Hi all. Great engine. I've downloaded it and run it on a Windows Phone 7 device (the LG) and it runs really badly I'm afraid

Fortuantely you can get an amazing speedup (and make it run really well) by forcing the game to use a lower resolution display:

// Pre-autoscale settings.
graphics.PreferredBackBufferWidth = 240;
graphics.PreferredBackBufferHeight = 400;

You still get the full screen, because the phone upscales the picture, but the rendering takes a lot less time and the performance now looks wonderful. The only problem with doing this is that all your buttons are absolutely positioned so you can't press them. So, I've added a horrible kludge to your Button constructor:

rectangle.X = rectangle.X / 2;
rectangle.Y = rectangle.Y / 2;
rectangle.Width = rectangle.Width / 2;
rectangle.Height = rectangle.Height / 2;

- and halved the size of your button font. This makes the buttons mostly work on the lower resolution screen.

This looks a tad blurry, but the performance is awesome.

Thought you might like to know. I'll blog this at www.robmiles.com as well.

Rob Miles

Very interesting! I previously heard a report of low performance in the demos on the device, but unfortunately, I haven't had the opportunity to test it on an actual device yet so I wasn't sure what the cause was. I'm glad to hear that it's not a fundamental performance problem with the physics side of things, thanks for the information

It is good to know but.. If I follow your recomendations, this is what happens in my emulator (see attached pictures)

Before appling what you said: After doing it: Something else is it needed? Do I need to re-scale ALL my graphics?

In terms of positioning/scale, you don't technically have to rescale your graphics- just make sure they are drawn in the right spot with the right size. It looks like your application is using some absolute coordinates like the phone demos were. If they're switched to resolution-independent coordinates (like screen percent), they should look right.

There might be some performance difference between rescaling your graphics content beforehand versus just drawing a high-res image smaller to fit the screen, but I'm not sure how much. It would probably be a good idea to go with resolution independent positioning/scaling as a first step, which in turn lets you quickly try different setups to see what works best.

resolution independent? what do you mean? is a builtin functionality or you referre to it as something more abstract?

There might be something in the new API's that helps out with it (other than just the hardware scaler) though honestly I haven't poked around much yet. You could implement it very simply just by using fractions of screen size as opposed to absolute coordinates.

For example, instead of using 400 (240) as the middle of the screen on a 800x480, you could multiply the current width (height) by 0.5. That way, it doesn't matter what the screen width (height) is in pixels, you always get the middle. Similarly, you can scale things such that they take "80%" of the screen, as opposed to "384 pixels."