WIP: some more test coverage ... unveiling yet more bugs

src/lib/time/timecode.cpp

@@ -339,14 +339,14 @@ namespace time {
   SmpteTC&
   SmpteTC::operator++ ()
   {
-    ++frames;
+    frames += sgn;
     return *this;
   }
   
   SmpteTC&
   SmpteTC::operator-- ()
   {
-    --frames;
+    frames -= sgn;
     return *this;
   }
   

src/lib/time/timevalue.hpp

@@ -273,6 +273,7 @@ namespace time {
       /** convenience start for time calculations */
       TimeVar operator+ (TimeValue const& tval)  const { return TimeVar(*this) + tval; }
       TimeVar operator- (TimeValue const& tval)  const { return TimeVar(*this) - tval; }
+      TimeVar operator- ()                       const { return -TimeVar(*this); }
     };
   
   

tests/lib/time/time-formats-test.cpp

@@ -137,9 +137,33 @@ namespace test{
           smpte.hours -= 6;
           CHECK ("- 0:21:59:24"== string(smpte));         // representation is symmetrical to origin
           CHECK (tx - Time(6*60*60) == smpte.getTime());  // Continuous time axis
-          CHECK (-1 == smpte.sgn);
+          
+          CHECK (-1 == smpte.sgn);                        // Note: for these negative (extended) SMPTE...
+          CHECK (smpte.mins > 0);                         // ...the representation is really flipped around zero
+          CHECK (smpte.secs > 0);
+          CHECK (smpte.frames > 0);
+          tx = smpte.getTime();
+          ++smpte.frames;                                 // now *increasing* the frame value
+          CHECK ("- 0:22:00:00"== string(smpte));         // means decreasing the resulting time
+          CHECK (tx - Time(1000/25,0,0,0) == smpte.getTime());
+          ++smpte;                                        // but the orientation of the increment on the *whole* TC values is unaltered
+          CHECK ("- 0:21:59:24"== string(smpte));         // so this actually *advanced* time by one frame 
+          CHECK (tx == smpte.getTime());
+          CHECK (tx <  Time(0));
+          
+          smpte.mins -= 2*60;                             // now lets flip it again...
+          CHECK ("  1:38:00:01"== string(smpte));
+          CHECK (+1 == smpte.sgn);
+          CHECK (smpte.getTime() > 0);
+          CHECK (tx + Time(2*60*60) == smpte.getTime());
+          smpte.secs -= 2*60*60;                          // and again...
+          CHECK (tx == smpte.getTime());
+          CHECK ("- 0:21:59:24"== string(smpte));
+
           smpte.sgn += 123;                               // just flip the sign
           CHECK ("  0:21:59:24"== string(smpte));
+          CHECK (tx == -smpte.getTime());
+          CHECK (+1 == smpte.sgn);                        // sign value is limited to +1 / -1
           
           smpte.secs.setValueRaw(61);                     // set "wrong" value, bypassing normalisation
           CHECK (smpte.secs == 61);

tests/lib/time/time-value-test.cpp

@@ -190,6 +190,7 @@ namespace test{
           CHECK (th+th == t1);
           CHECK (t1-th == th);
           CHECK (((t1-th)*=2) == t1);
+          CHECK (th-th == Time(0));
           
           // that was indeed a temporary and didn't affect the originals
           CHECK (t1 == TimeValue(GAVL_TIME_SCALE));

wiki/renderengine.html

@@ -6746,7 +6746,7 @@ Question is: how fine grained and configurable needs this to be?
 
 </pre>
 </div>
-<div title="TimecodeFormat" modifier="Ichthyostega" modified="201101211920" created="201101100308" tags="Player spec discuss draft" changecount="24">
+<div title="TimecodeFormat" modifier="Ichthyostega" modified="201101220135" created="201101100308" tags="Player spec discuss draft" changecount="25">
 <pre>The handling of [[Timecode]] is closely related to [[time representation and quantisation|TimeQuant]]. In fact, these two topics blend into one another. Time will be quantised into a //grid,// but this grid only makes sense when linked to a externally relevant meaning and representation, which is the Timecode. But a timecode value also denotes a specific point in time -- performing operations on a timecode is equivalent to manipulating a quantised time value.
 
 !Problem of dependencies
@@ -6791,6 +6791,8 @@ But because for Lumiera the SMPTE format is just a presentation rule applied to
 # by a representation symmetrical to the zero point (0:0:0:0 - 1sec = -0:0:1:0) -- but beware: //the underlying frame quantisation won't flip//
 Because this decision is considered arbitrary and any reasoning will be context dependant, the decision is to provide a hook for a //strategy// --
 Currently (1/11), the strategy is implemented according to (1) and (4) above, leaving the actual configuration of a strategy for later.
+!!{{red{WIP 1/11}}}BUG
+Implementation of this strategy is still broken: it doesn't work properly when actually the change passing over the zero point happens by propagation from lower digits. Because then -- given the way the mutators are implemented -- the //new value of the wrapping digit hasn't been stored.// It seems the only sensible solution is to change the definition of the functors, so that any value will be changed by side-effect
 </pre>
 </div>
 <div title="Timeline" modifier="Ichthyostega" modified="201011220126" created="200706250721" tags="def" changecount="21">