XBOX

[BoltonBeedz]

I'm still finding it hard to get smooth play on the XBOX. Any tips?

[Norbo]

More information is needed to make any specific recommendations, but in general, just make sure the multithreading is running. What kind of simulation are you running? Is it a 'jiggy' lag (like those caused by garbage collection and compaction), or is it a generally slow framerate?

The Xbox will always run quite a bit slower than the PC, unfortunately.

[BoltonBeedz]

Hi Norbo. Thanks for replying again.
You know. it might not actually be slow. I mean it is dropping to 2fps (15 boxes, 5 cylinders, 1 terrain, 4 simpleton bad guys) but the numbers show 4/1 CPU is used by my draw relative to physics (at 30fps) and when i start mixing it up with the gun it looks more like 4/2.5 and this is when it gets bad. draw is hogging i bet. I read somewhere you said that lowering solver quality would help. Is this still a thing? dont worry about it im off to optimize the draw. Ta

[Norbo]

You can indeed drop the number of iterations used by the solver using the (Space).simulationSettings.collisionResponse.iterations field. 15 is the default. It probably won't help noticeably in this situation, since as you suspect, that amount of physics should run very quickly even on the Xbox.

[BoltonBeedz]

It's incredible how long it takes to set effect parameters.
I can easily get it down to 4fps still - if i jostle 30 random shapes with my man - but its mostly 60fps One last thing though, how do i check if multithread is enabled please?
I just randomly did this:

Code: Select all

                g.broadphase = new BEPUphysics.BroadPhases.DynamicBinaryHierarchy();
                g.space = new Space(g.broadphase);
                g.space.allowMultithreadedSolver = true;
                g.space.useMultithreadedUpdate = true;
                g.space.useBatchedMultithreadingSolver = true;

Thanks

[Norbo]

Check the multithreading demo for some example source, you can get it on the documentation page at http://www.bepu-games.com/BEPUphysics/documentation.htm.

Basically, you need to give the engine some threads to work with using (Space).threadManager.add(). After that, all you have to do is set (Space).useMultithreadedUpdate = true.

You don't need to set allowMultithreadedSolver or useBatchedMultithreadingSolver to true. allowMultithreadedSolver is true by default, and useBatchedMultithreadingSolver is a very specific feature which should generally remain false unless determinism is a serious issue.

Edit: I just noticed an error with the XML comment associated with the useBatchedMultithreadingSolver. It should say "This version of solving is deterministic," not the opposite. The overhead it mentions can be quite significant depending on the simulation, which is why the non-batched version is preferred.

[BoltonBeedz]

that kicks ass by the way thanks. am i able now to free up the draw thread from doing physics by commenting the line here?

Code: Select all

                //g.space.threadManager.add(delegate(object information) { Thread.CurrentThread.SetProcessorAffinity(new int[] { 1 }); }, null);
                space.threadManager.add(delegate(object information) { Thread.CurrentThread.SetProcessorAffinity(new int[] { 3 }); }, null);
                space.threadManager.add(delegate(object information) { Thread.CurrentThread.SetProcessorAffinity(new int[] { 5 }); }, null);

                space.useMultithreadedUpdate = true;

[Norbo]

The internal multithreading will use the threads only within the (Space).update call. After that call, you don't need to worry about it hogging any more resources. That means if you're calling update from your game's update method, you don't need to worry about using fewer processors.

If you are running the engine asynchronously and your rendering takes place on the first processor, then yes, commenting out that line would prevent the engine from tying up that particular hardware thread/processor.