On Sun, 2008-08-17 at 12:11 -0700, John Denker wrote: > On 08/17/2008 10:01 AM, Ron Jensen wrote:
> >> and the decision was made > >> not to include it in the main code base. > > There was no consensus on that point. > The fact that the code is not there speaks for itself. > >> 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. I have never disagreed that we are overloading the textranslate function into an area it wasn't designed for. That is why I implemented a tag as opposed to hard-coding a similar solution which is what is currently done in the _Sport Model_. Jim above gives his approval of it and Andy committed it. Even if they couldn't see a need, we now have functional 3D radio displays using this tag in several aircraft, and textranslate functions that worked with out it continue to work without it. > 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. If this code is in the _Sport Model_ I am in favor of pulling it into CVS head. > *) 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). Thank you for another lesson in avionics and computer science 101. ------------------------------------------------------------------------- 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
