1
\$\begingroup\$

So I thought my issue was relating to the difference between a Debug and a Release build as per this question: What's the difference between a "Release" Xbox 360 build and a "Debug" one? but I've since found that if I go ahead and build a Creators Club version of the game using a Debug build and deploy to the XBOX, I get the same experience I had with the Release version of my game.

However if I run the game from Visual Studio using F5 and having set the XBOX as the default platform, then the game runs as expected. If I change from Debug to Release and run with CTRL+F5 then the game also works as expected.

How would running the game with the debugger attached change the results I am getting in game? Is there any way that I can use the same approach or change the default compilation of the game so that I can use this approach to release my game?

\$\endgroup\$
2
  • 1
    \$\begingroup\$ Can you explain what you're expecting vs what's actually happing? Is it just running slower? Is there an FPS drop? Are some things not loading? \$\endgroup\$
    – Richard Marskell - Drackir
    May 27, 2012 at 7:06
  • \$\begingroup\$ I have collision mesh's which aren't lining up with the actual game objects but for only some of the objects. The rest of the physics is working fine. I have a way of drawing the collision mesh at run time to see the issue and it only shows up when the game is deployed on the XBOX and has not been run from VS. \$\endgroup\$
    – Sebastian Gray
    May 27, 2012 at 7:40

1 Answer 1

Reset to default
1
\$\begingroup\$

On Windows there is actually a way to change the behaviour of the JIT - it's clear that you can't create such an INI on the XBOX: so this is unavailable.

Remember that a compiler is not allowed to change the behaviour of a piece of code. You have either found an XBOX runtime bug, or the library you are using is sensitive to delays introduced by debugging (somehow, the antithesis of a heisenbug): and it's very likely the latter.

Remember, it's Microsoft's job to ensure that the JITter does not change the behaviour of a piece of code: and they do a very good job at it (if I remember correctly the XBOX interprets MSIL - so the chances of it doing it incorrectly are next-to-none). Expecting DEBUG/RELEASE to change the behaviour of your application is the wrong mindset to begin with: debug your DEBUG build, and test your RELEASE build without the debugger attached.

From your comments it sounds like they have heisenbug in BEPU: made apparent by the fact that they are using multi-threading. I would recommend attempting to disable the multi-threading (not sure how, but it's clear that you can) and seeing if the behaviour persists: if it doesn't there is a problem with the threading in BEPU and you should report it to them.

\$\endgroup\$
4
  • \$\begingroup\$ So I've gone through a process of changing the game timing, removing Fixed time steps and v-sync to increase the FPS and have exactly the same issue. I've also tested by introducing a significant time delay and reducing the FPS and again have exactly the same issue as described. If run from Visual Studio to the XBOX it's fine. If deployed to the XBOX and run it doesn't work correctly and exhibits different behaviour. \$\endgroup\$
    – Sebastian Gray
    May 27, 2012 at 7:43
  • \$\begingroup\$ @SebastianGray which physics library are you using exactly? \$\endgroup\$
    – Jonathan Dickinson
    May 27, 2012 at 8:24
  • \$\begingroup\$ An implementation of BEPU \$\endgroup\$
    – Sebastian Gray
    May 27, 2012 at 8:57
  • \$\begingroup\$ @SebastianGray see update (last paragraph). \$\endgroup\$
    – Jonathan Dickinson
    May 27, 2012 at 10:03

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .