XNA 3.0 compatibility

Discuss any questions about BEPUphysics or problems encountered.
Post Reply
nindim
Posts: 10
Joined: Thu Nov 06, 2008 1:40 pm

XNA 3.0 compatibility

Post by nindim »

Hi there, I was using BEPUphysics with a combination of XNA 2.0 and 3.0 beta installed on my system, I was able to deploy to 360 and everything was fine. Since XNA 3.0 went final though, I decided to remove XNA 2.0 and move development to XNA 3.0.

Everything seems to work fine except for when I try to use a scene that uses BEPUphysics. I assume the reason for this is that the assembly is referencing XNA 2.0 which doesn’t exist on my system anymore. Visual Studio did give me a warning about different versions of assemblies being used and asked if i would like to remap in my app.config file. Ignoring the warning and NOT re-mapping gives the following error:

ON PC:
Could not load file or assembly 'Microsoft.Xna.Framework, Version=2.0.0.0, Culture=neutral, PublicKeyToken=6d5c3888ef60e27d' or one of its dependencies. The system cannot find the file specified.
ON 360:
Black screen and it seems to hang.

After remapping, my BEPUphysics scene works on my PC, however I now get a different error message from the VS sdebugger when running on 360 (after sitting at a black screen on 360 for about 5 minutes):
An unhandled exception of type 'System.MissingMethodException' occurred in Microsoft.Xna.Framework.Game.dll

Additional information: File or assembly name 'Microsoft.Xna.Framework, Version=2.0.0.0, Culture=neutral, PublicKeyToken=51C3BFB2DB46012C', or one of its dependencies, was not found.
As a side note, running my other scenes and even just putting a breakpoint inside my BEPUphysics scene causes my other scenes not to run. On forcing the debugger to stop (by switching off 360) I get errors for each of the breakpoints in the BEPUphysics scene saying it cannot add the breakpoint for an unknown reason.

I assume that what i need is an updated .dll for BEPUphysics designed for use with XNA 3.0, is this planned?

From the above information I think it's pretty safe to say that the problem is localised to BEPUphysics, any help would be much appreciated!
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: XNA 3.0 compatibility

Post by Norbo »

I'm working on finalizing the 0.7.0 release which will have both an XNA 2.0 (at least for the library itself) and an XNA 3.0 version. It will be released before November 19th. Right now I'm trying to fix a few bugs and add in one last feature (a new broadphase); if I cut the broadphase, it will be out in the next week (probably).
nindim
Posts: 10
Joined: Thu Nov 06, 2008 1:40 pm

Re: XNA 3.0 compatibility

Post by nindim »

Ah, that sounds great, just in time for Community games as well, not that I have anything to put on it,I'm still in the testing stage and haven't even really gotten my feet wet with the physics side of things, just a little moist so far!

A new broadphase? That sounds cool, can we look forward to any speed improvements, or is it a new algorithm suited for different situations than the one already implemented?
Norbo
Site Admin
Posts: 4929
Joined: Tue Jul 04, 2006 4:45 am

Re: XNA 3.0 compatibility

Post by Norbo »

0.7.0 overall is a pretty massive speed boost in almost every respect, even without the new broadphase. I went through every time-consuming part with a fine toothed comb and added in some new collision detection systems to boot.

Sweep and prune (the broadphase I was hoping to implement) should never be really slower than the grid system currently used, and will deal with clustering/nonuniform distributions of entities far better than the grid system. Its raycast will be about as fast as the grid method (since it operates on a grid developed from the sweep axes). For these and other reasons, the sweep and prune broadphase would probably be on the order of twice as fast as the current broadphase in most situations.

Edit: I should mention that the insertion/deletion will be a bit slower with SAP compared to a grid (the more objects, the slower it will be). This may be a concern on large simulations with static triangle groups and terrains, though the problem can be reduced by distributing the removal of triangles by having a high resolution removal interval in the static triangle group or terrain.
Post Reply