Particle friction with variable timestep in XNA

Alright, so I'm working on an engine of sorts in XNA (yes, it's deprecated, I know) and I'm implementing my own particle system. I've defined a "ParticleEffect" such that when it's supplied a GameTime and an IEnumerable<T:IParticle>, it applies an "effect" to every particle in that collection.

For example, my Friction effect:

public sealed class Particle2D_Friction : ParticleEffectBase<Particle2D>
{
public float Magnitude { get; set; }
public float StopThreshold { get; set; }

public override void Apply(GameTime time, IEnumerable<Particle2D> particles)
{
if (Enabled)
{
if (particles != null)
{
float delta = time.GetDelta();
float magnitude = MathHelper.Clamp(Magnitude, 0.00f, 1.00f);
Vector2 result = Vector2.Zero;

foreach (var particle in particles)
if (particle != null && particle.Alive)
{
result = particle.Velocity - (delta * (1.00f - magnitude) * particle.Velocity);
if (Math.Abs(result.X) <= StopThreshold) result.X = 0.00f;
if (Math.Abs(result.Y) <= StopThreshold) result.Y = 0.00f;
particle.Velocity = result;
}
}
}
}
}

Unfortunately, it isn't behaving quite as well as I'd like it to, and I know the issue is linked to the delta time. I should mention that time.GetDelta() is an extension method that returns (float)time.ElapsedGameTime.TotalSeconds; as a shortcut.

Anyways, when I remove the delta, the effect is a rather strong, but it comes to an immediate stop when Magnitude is equal to 0.00f (retains 0% of velocity), while it moves indefinitely when equal to 1.00f (retains 100% of velocity). That's fine and that's how it should work.

When I add the delta to smooth it out, I encounter a problem. When Magnitude is equal to 1.00f, it retains 100% velocity as it should. However, when Magnitude is equal to 0.00f, it retains 1/60th of it's velocity instead of stopping. Of course, 1/60 is equal to 0.01666, which is the frames per second on the delta. But it's wrong.

I'm not sure how to fix this behavior. Any suggestions?

• The delta isn't supposed to "smooth it out". It's theoretically supposed to account for a variable unexpected framerate. If the framerate is stable, delta is not needed normally. I don't understand why magnitude 0.0 is supposed to stop it. In the code it does 1.00f - magnitude which will return 1.00f if magnitude is 0 and then multiply that by delta and you get 0.0166... The result is larger me thinks when magni is 0. – wolfdawn Jun 21 '14 at 6:41
• Oh, sorry. I had it set so that it was "retention". So like, 0.98f would mean it keeps 98% of its speed, 0.00f means it would stop entirely. That was the point of magnitude (and clamped between 0 and 1). But still, removing the delta results in a full stop when I give it 0, but adding the delta doesn't stop the particle entirely, which makes me wonder why I even need delta in the first place (aside from being "proper") – Kyle Baran Jun 21 '14 at 20:51
• My answer was incorrect, your math appears to be right. :) I am wondering why decreasing the speed in an exponential rate does not to work to accomplish what you expected (It does not make sense to me). – wolfdawn Jun 23 '14 at 12:30
• The idea was that if Magnitude was set to 0.00f, then it would retain 0% of its movement when it updates, thus stopping the particle entirely, but because of delta, it was messing up the number. To get around it, the only solution I could find was hardcoding specific behavior to 0.00f manually, or else multiplying the amount by 60f (since delta was equal to 1/60th, or 0.01667). – Kyle Baran Jun 25 '14 at 12:12
• But if you multiply then there is no use in using delta in the first place.. If you use delta than you are saying I want this process to take one second or x seconds depending on the coefficient you use with delta. – wolfdawn Jun 25 '14 at 20:32