John Denker wrote:
> On 08/17/2008 10:01 AM, Ron Jensen wrote:
> 
>>> This particular patch was greatly discussed 
> 
> Yes, it was greatly discussed.
> 
>>> and the decision was made
>>> not to include it in the main code base. 
> 
> There was no consensus on that point.
> 
That's my reading of the discussion, but in any event, I didn't mean to imply 
that this was a patch I would be committing straight away, just that it 
wouldn't 
merge with current CVS because the texture animation code has changed to use 
expressions.

Tim

>>> The <bias> tag was added as
>>> the fix for this "problem".  
> 
> There was no consensus that the <bias> tag made much sense.  Here is
> a good summary of the discussion:
> 
> 
> On 03/09/2007 01:18 PM, Jim Wilson wrote:
>> Hi Everybody,
>>
>>
>> Just to clarify, I wrote the textranslate and texrotate animations
>> (they are animations) while doing the displays for the 747.  They are
>> for sliding and rotating texture mappings on an 3D object, and have
>> nothing per se to do with digits.  The first problem I was trying to
>> solve was sliding the ASI and Altitude tapes on the PFD.  Then it was
>> the rose animation.
>>
>> The problem of producing the alpha and digital displays (it was never
>> about "numbers") had been dogging me, and in the end I never got
>> around to really solving the issue.  It just so happend that I was
>> able to use the texture translation for placing numeric values by
>> creating a texture that had a bunch of digits and sliding it around.
>> By adding the step parameter I was able to make it either scroll
>> smoothly like the altitude value or just snap the digit in place as
>> on most digital displays.  IIRC the IAS display also has a sort of
>> odometer "drum" behavior even though it is a flat electronic display.
>> Note that the animations were also used for displaying some
>> alphanumeric NAV data.
>>
>> Essentially, I'm saying that Andy was right.  Also, there really was
>> no intention to handle fractional numeric values or digits for that
>> matter.  It just happened that other modelers picked up on the
>> technique, as there was no other method available,  and it went quite
>> a bit farther than was ever intended.
>>
>> In that context, the addition of the bias tag doesn't really make a
>> whole lot of sense, but if it helps someone out, that's fine.  These
>> functions are a useful way to do all kinds of things with sliding and
>> rotating textures,  but they are a very cumbersome way of doing
>> alphanumeric data displays.
> 
> I agree with Jim Wilson and Andy Ross that the <bias> tag doesn't
> make a whole lot of sense.  If you want to use it, go ahead, but 
> don't pretend it "fixes" the problem ... and don't use it as a 
> pretext for derailing efforts to really fix the problem.
> 
> The only thing that really makes sense is to implement a set of 
> formatting directives that is actually suitable for digits. 
>  *) This will make the code for digit displays much much more
>   compact.  Writing the code will be less laborious and less
>   error-prone.
>  *) Then textranslate can be restricted to its intended purpose,
>   namely tapes and drums.
>  *) Beware that real instruments /round/ some things and then
>   /truncate/ other things, so a one-size-fits-all approach will
>   not work, as I pointed out a year and a half ago.  The formatting
>   directives will need to include some things that are documented
>   to do rounding (such as sprintf) and some things that are documented
>   to do truncation (such as substr).
> 
> 
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
> 


-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel

Reply via email to