# 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. Commented Jun 21, 2014 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") Commented Jun 21, 2014 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). Commented Jun 23, 2014 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). Commented Jun 25, 2014 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. Commented Jun 25, 2014 at 20:32