Possible memory leak in farseer port

#1 I think i found insight into this.... I'll be sure to update the svn if i can improve the situation.

#2 Today I just updated to the Farseer version of the CEV. I noticed that my game, which uses the original Torque X physics system (NOT Farseer), stopped working right. Objects given a single velocity would not move at a uniform speed and collision detection was not working properly. It completely broke the Platformer Starter Kit. I had to revert to a revision before Farseer was added to get my game to work again.

So, is your problem the same as mine? IE, Farseer broke the normal physics engine?

#3 So far no... but I can see how that would be possible. They did not do what they said they would, and keep the component adding non-invasive. Instead they did alot of stuff like this...

public virtual Vector2 Position
        {
            get { return _position; }
            set
            {
                _position = value;
                _postTick.pos = _position;
                IsSpatialDirty = true;
                UpdateSpatialData();

                // Update the Farseer simulation if this is a Farseer body
                if (_fsBodyComponent != null)
                {
                    _fsBodyComponent.Position = value;
                }
            }
        }

Which is clearly invading the T2DSceneObject, to give functionality to a component they wrote. Kind of selfish if you ask me, and not very well thought out.

I can easily see how in some instances your game is totally ruined by farseer, but I can not find the bug directly yet. I'll look into it though.

#4 looks like geometry isn't being disposed, leaving a giant stack in the distance grid list.... but that fix was EASY.

Heres what I'm seeing, I can't seem to see whats going on looking at the CLR, everything looks "OK"?

But just creating a bucket load of stuff and destroying it, keeping about 25 items on the stack, is creating a state of instability after about 1 minute of sustained collisions...

video..

#5 I think this might just be a general memory leak, and not a farseer bug.

#6 @will: that particular piece of code isn't really invasive, other than being embedded in the scene object code. It will only activate if you are using farseer and therefore actually intend to use that functionality. If you don't use farseer it will be just like it was never there (except for the one or two cpu ticks that the null check will take).

Althought I must say it would be nice to have a '#define' so you can compile completely without farseer if you really really need to :)