Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Garbage from subscribing to collision events
#9
(17-12-2017, 08:37 PM)writer51 Wrote: Hrm, I don't understand the discrepancy between your tests and mine, unless I am missing something.
I started in a fresh project and bench marked it before any changes using the sample collision script provided (just the commented out part that does the material color change). With no profiler enabled at all I was hitting 125-140 fps with 7-8 ms. Adding the changes I dropped down to 60-80 fps or so. Would it be possible to send me a test project (zip or whatever) so I can benchmark the new code in it, then change it back and benchmark it after?

I'd love to help and test in anyway I can because my current game requires heavy dependence on Obi Fluid so anything I can do to help improve it would be my pleasure. This is Tigrero btw, been working with Obi for a while Sonrisa
Hi Tigrero! didn't recognize you Sonrisa

We test all sample scenes in an empty project before and after making a performance critical change. I just tested the FluidFoam scene, with the old method I get 75-80 fps, with the new one I get 84-90. Tomorrow I will take a deeper look at it, and maybe send you a test scene with an easy switch to toggle between the two methods, but I see no reason why the new method would be slower.


Edit: Off the top of my head: in the CollisionEventHandler, make sure you iterate to contacts.Count, not contacts.Data.Length. contacts.Data.Length refers to the internal backing array size (similar to List<>'s Capacity), which can be much larger than the actual amount of contacts. That would leave the event handler iterating over an enormous, mostly empty, array. Can this be the cause?

cheers,
Reply


Messages In This Thread
RE: Garbage from subscribing to collision events - by josemendez - 17-12-2017, 08:47 PM