This project has moved and is read-only. For the latest updates, please go here.

Bug in FP2.1: where have all my Arbiters gone?

Topics: Developer Forum, User Forum
Jun 30, 2009 at 2:50 PM

Following on from my garbage investigations, I noticed that my Pool<Arbiter> that started with a count of 1000 was becoming empty after about 30 seconds! My game has a lot of geometries being added and removed dynamically. I tracked the gremlin down to PhysicsSimulator::ProcessRemovedItems(). It seems somebody overlooked to insert the arbiters for removed geoms back into the arbiter pool.

Jun 30, 2009 at 10:57 PM

I've not tested it yet as I'm busy at the moment at it is late here. But the code to reinsert the arbiter into the pool after use is in place in 2.1.1. I will edit the physicssimulator view to show me how many arbiters there are avaliable in the pool. Just to confirm this behavior.

Thanks for reporting it. Are you from a C++ background? I just noticed the :: between PhysicsSimulator and ProcessRemovedItems() ;)

Jul 1, 2009 at 1:48 AM

heh, I'm also from a C++ background. When writing about C#, I sometimes use the :: as shorthand to indicate that I'm talking about an instance method of a class as opposed to a static method. Which is weird because in C++ that's how you call a static method, and is used when defining both static and instance methods. In C++ you can use ClassName::MethodName to refer to a static method and ClassName.MethodName to refer to an instance method (as a convention) without ambiguity, but in C# you can't because they are both called using the . operator. So I just inverted the C++ convention. I don't know where I got it from. I used to think it was just my own little convention but I've seen it used before more than once.

Jul 1, 2009 at 3:37 AM
Edited Jul 1, 2009 at 3:38 AM

Oh! I didn't realise FP2.1.1 was out. I'll have to grab that ASAP. Good idea with the physics simulator view, I don't actually use it yet as my game is 2.5D and I don't use any FP drawing code. I should really integrate it though as it does have some invaluable information.

I just did a browse of the source code and the problem still exists in SourceFiles->FP2.1->PhysicsSimulator.cs at line 876 (arbiterList.Remove(arbiterList[j - 1]);). I'm not sure where the version for FP2.1.1 lives, but I couldn't find it. [EDIT[ It's a pity the Browse source control doesn't include line numbers - I had to copy and paste it into VS [/EDIT]

Yep, my day job is a tools programmer mostly involving C++, DX9 and unfortunately MFC  =[... My hobby, which nevertheless takes up a fair whack of time is C#, XNA & physics dabbling. I guess my day job leaked through into my hobby.

Jul 1, 2009 at 1:37 PM

FP2.1.1 lives in the 2.1 branch. I did not have the time to update the branch and online manual to say 2.1.1.

I just did a quickfix and just reinserted the arbiter back into the pool. It would be great if you could test it out for me. I would recommend that you don't remove geometries, but simply just disable them. (body.enabled = false).

Jul 1, 2009 at 5:02 PM
Edited Jul 1, 2009 at 5:05 PM

I just did a browse and the fix you made was exactly the same as the one I made yesterday. I can confirm that this resolves the problem in my local version, but I'll have to wait until I can integrate FP2.1.1 to be 100% certain. Thanks for the tip on Enabling/disabling bodies... now that I think about it it makes a lot of sense, avoiding the list removal which could be costly on large lists and also avoiding the list allocating space for new objects.