From 14f233f83bd513d9707097316b407c5a8a42a659 Mon Sep 17 00:00:00 2001 From: Ichthyostega Date: Sat, 22 Jan 2011 02:35:58 +0100 Subject: [PATCH] WIP: some more test coverage ... unveiling yet more bugs --- src/lib/time/timecode.cpp | 4 ++-- src/lib/time/timevalue.hpp | 1 + tests/lib/time/time-formats-test.cpp | 26 +++++++++++++++++++++++++- tests/lib/time/time-value-test.cpp | 1 + wiki/renderengine.html | 4 +++- 5 files changed, 32 insertions(+), 4 deletions(-) diff --git a/src/lib/time/timecode.cpp b/src/lib/time/timecode.cpp index 9a0ff6f27..7b33f6521 100644 --- a/src/lib/time/timecode.cpp +++ b/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; } diff --git a/src/lib/time/timevalue.hpp b/src/lib/time/timevalue.hpp index 0778022a7..f8407717f 100644 --- a/src/lib/time/timevalue.hpp +++ b/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); } }; diff --git a/tests/lib/time/time-formats-test.cpp b/tests/lib/time/time-formats-test.cpp index b56fac95e..79f5293d2 100644 --- a/tests/lib/time/time-formats-test.cpp +++ b/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); diff --git a/tests/lib/time/time-value-test.cpp b/tests/lib/time/time-value-test.cpp index a1533ca67..9a1383e8b 100644 --- a/tests/lib/time/time-value-test.cpp +++ b/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)); diff --git a/wiki/renderengine.html b/wiki/renderengine.html index 9bfb2a429..10923eb49 100644 --- a/wiki/renderengine.html +++ b/wiki/renderengine.html @@ -6746,7 +6746,7 @@ Question is: how fine grained and configurable needs this to be? -
+
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