Add a hack to work around path change problems

The path timing code is crap overall; it uses rounded floats for time
calculations that really should be exact, and path parts can change in
the middle of a time step. The latter causes visible problems on the
centrifuge test map; probably similar problems would be reproducible
for linear movement on a suitable map (perhaps a platform that quickly
descends at a constant speed over multiple path parts). Add a hack to
work around this by splitting movements if they'd continue over path
part changes.

From: Uoti Urpala

git-svn-id: https://s.snth.net/svn/neverball/trunk@3323 78b8d119-cf0a-0410-b17c-f493084dd1d7

diff --git a/share/solid_sim_sol.c b/share/solid_sim_sol.c
index 0d212fa..b4f2f6c 100644 (file)
--- a/share/solid_sim_sol.c
+++ b/share/solid_sim_sol.c
@@ -694,7 +694,29 @@ float sol_step(struct s_file *fp, const float *g, float dt, int ui, int *m)
 
         while (c-- > 0 && tt > 0)
         {
-            nt = sol_test_file(tt, P, V, up, fp);
+            float st;
+            int bi;
+
+            /* HACK: avoid stepping across path changes. */
+
+            st = tt;
+
+            for (bi = 0; bi < fp->bc; bi++)
+            {
+                struct s_body *bp = fp->bv + bi;
+                struct s_path *pp = fp->pv + bp->pi;
+
+                if (bp->pi < 0)
+                    continue;
+
+                if (!pp->f)
+                    continue;
+
+                if (bp->t + st > pp->t)
+                    st = pp->t - bp->t;
+            }
+
+            nt = sol_test_file(st, P, V, up, fp);
 
             cmd.type       = CMD_STEP_SIMULATION;
             cmd.stepsim.dt = nt;
@@ -704,7 +726,7 @@ float sol_step(struct s_file *fp, const float *g, float dt, int ui, int *m)
             sol_swch_step(fp, nt);
             sol_ball_step(fp, nt);
 
-            if (nt < tt)
+            if (nt < st)
                 if (b < (d = sol_bounce(up, P, V, nt)))
                     b = d;