enigma-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Enigma-devel] CVS update and mouse controls


From: Jeremy Sawicki
Subject: Re: [Enigma-devel] CVS update and mouse controls
Date: Sun, 05 Jan 2003 14:49:04 -0500

At 12:26 AM 1/4/03 +0100, Daniel Heck wrote:
>You're right, friction is the main issue.  But making the force
>proportional to the speed of the marble isn't perfect either (at least
>in my opinion).  I did a few experiments and found a v^0.8 dependence to
>be a fairly good compromise--the changes are in CVS, in case anyone
>wants to give them a try.

I find that v^0.8 works fairly well too.  I still think I slightly prefer
v^1.0, though that may be largely because it seems closer to the behavior of
oxyd.  (It is easier to try to objectively match a known good behavior than
to subjectively decide what behavior is best.)  But it does seem like the
marble comes to a stop a little abruptly still.  Either way, it is a vast
improvement over the earlier behavior.

A few more things:

When you changed the default mouse speed and mouse damping in options.cc,
you left the old values in enigma_conf.lua.  I assume they should match.

Experimenting with mouse damping is difficult because of the way it is
defined.  I think that once a mouse speed has been chosen, a given mouse
movement should always result in the same total change in velocity, and
mouse damping should only control how that change is spread out over time.
As it is currently defined, damping alters the total change in velocity, so
any change to the damping requires a corresponding change to the mouse speed.

Here is one way to fix the problem:

########
--- world.cc    3 Jan 2003 23:00:53 -0000       1.33
+++ world.cc    5 Jan 2003 15:06:56 -0000
@@ -133,8 +133,8 @@
     public:
        MouseForce() {maxforce = 150;}

-       void set_force(V3 f) { force=f; limit_force(); }
-       void add_force(V3 f) { force+=f; limit_force(); }
+       void set_force(V3 f) { force=f*options::MouseDamping/25.0;
limit_force(); }
+       void add_force(V3 f) { force+=f*options::MouseDamping/25.0;
limit_force(); }

        V3 get_force(Actor *a, V3 x, V3 v, double time)
         {
########

The extra factor of 25 keeps the existing mouse speed settings of 1-10 in
the right range -- otherwise, even a mouse speed of 1 is too high.

Once this change is made, I find that I prefer to set the damping as high as
possible.  (But if you set it too high, the size of the integration step
becomes an issue, and the interaction with mouse speed comes back.)  In
fact, I would be happy to do away with the concept of damping altogether,
and simply apply the entire change of velocity in the first integration
step.  Regardless, the above change makes it easier to experiment and
determine whether it is desirable to spread the acceleration out over time,
without being confused by the effect on the overall amount of acceleration.

Petr is right that gravity and gradient forces need to be increased.  The
exact amount depends on what friction value we settle on.  The factor of 2.5
that he proposes seems about right for the friction value of 1.0 that he is
using.  With a higher friction value, a higher factor is needed.

Jeremy




reply via email to

[Prev in Thread] Current Thread [Next in Thread]