John Denker wrote:
> On 08/16/2008 03:32 PM, Tim Moore wrote:
> Sport Model was last updated to CVS FlightGear over a year ago. Do you
> have any
> plans to update it to current CVS?
>
> On 08/16/2008 06:13 PM, I replied:
>
I could be persuaded.
Do you think it would
On 08/16/2008 03:32 PM, Tim Moore wrote:
Sport Model was last updated to CVS FlightGear over a year ago. Do you
have any
plans to update it to current CVS?
On 08/16/2008 06:13 PM, I replied:
>>> I could be persuaded.
>>>
>>> Do you think it would be helpful?
On 08/17/2008 08:28
On 19 Aug 2008, at 08:15, Erik Hofman wrote:
I just checked and both the led font and lcd font are already
available
indeed.
Here is an image showing the Data Entry Display in action:
http://home.telfort.nl/sp004798/emh/ded.jpg
Side note - this is interesting, I'm still musing on the best
Erik Hofman wrote:
> If I understand this correctly I think FlightGear already provides a way
> to do that. I've recently attached a 2d-panel text animation to a 3d
> model to display all sorts of text information in an Data Entry Display
> (DED).
>
> See FlightGear/data/Aircraft/f16/Models/de
John Denker wrote:
> 5) Using textranslate to implement the frequency digits on a digital radio is
> still a
> kludge. The xml required to do this is long-winded, to say the least. The
> patches
> presented here do not remove the pressure for a nicer api. Some sort of
> sprintf and
> subs
On 08/17/2008 08:13 AM, Timothy Moore wrote:
> the stepping
> code has been moved to an SGStepExpression in
> simgear/structure/SGExpression.hxx, but it should be easy to apply the same
> change there.
Easy indeed. Cut and paste. See patches below.
But before we discuss the code in det
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 tag was a
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 th
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.
>> The tag was added as
>> the fix for this "problem".
Th
On Fri, 2007-03-09 at 15:18 -0500, 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 nothi
om: Ron Jensen <[EMAIL PROTECTED]>
> Sent: Friday, 9. Feb 2007 21:34 -0500
> To: FlightGear developers discussions
> Subject: Re: [Flightgear-devel] Textranslate Step and Scroll
>
> On Fri, 2007-02-09 at 14:00 -0500, John Denker wrote:
>
> > I come to slightly different
On Saturday 10 February 2007 05:06, John Denker wrote:
> On 02/09/2007 09:34 PM, Ron Jensen wrote:
>
> [250 lines of stuff we agree about]
:)
Me too.
I am still working on the osg 2d cockpit stuff to get that fast and reliable.
But we have definitely stuff in the 2d panel code that should be facto
On 02/09/2007 09:34 PM, Ron Jensen wrote:
[250 lines of stuff we agree about]
> Except in your algorithm '0' can never be used as a scroll value.
Well, I fixed that just now. New version:
http://www.av8n.com/fly/fgfs/animation.diff
Anybody who wants to set 0 is now free to do
exactly that.
On Fri, 2007-02-09 at 14:00 -0500, John Denker wrote:
> I come to slightly different conclusions. The main point of
> difference is that I think it would be better to change the
> code to establish a reasonable default value, rather
> than rampaging through all the existing instruments to add
>
On 02/09/2007 11:08 AM, Ron Jensen wrote:
> I stripped the apply_mod() function out into its own small program for
> analysis.
The experimental analysis confirms that the code is numerically
unstable.
I don't think there is any way to make it numerically stable.
The instability can be swept un
On Thu, 2007-02-08 at 18:55 -0500, John Denker wrote:
> On 02/07/2007 02:14 PM, Andy Ross wrote:
>
> > So if there's a design flaw here, it's at a higher level. Maybe
> > what's really needed is a "digit extractor" animation instead.
>
> Good news: The /design/ is not as flawed as it looks.
On 02/07/2007 02:14 PM, Andy Ross wrote:
> So if there's a design flaw here, it's at a higher level. Maybe
> what's really needed is a "digit extractor" animation instead.
Good news: The /design/ is not as flawed as it looks.
All evidence indicates that the primary problem with the
step-and
I wrote:
> The patch itself looks sane and easy. But I think I agree with
> John, this is a workaround for a design flaw in the step animation
> that we should just fix.
Nope, it turns out we really do want truncation. The reason is that
the input property to the animation, at least in Ron's
John Denker wrote:
> Ron Jensen wrote:
> > The tag effectively truncates the property, 29.9199
> > becomes 29.91, so a (3D) readout reads off one number.
> >
> > I am proposing an new tag, , that will act like but be
> > applied before and
>
> While the tag seems reasonable eno
On Wed, 2007-02-07 at 11:32 -0500, John Denker wrote:
> On 02/07/2007 09:47 AM, Ron Jensen wrote:
> > While working on 3D cockpit instruments I keep hitting into issues with
> > internal floating point representation and the tag.
> >
> > The tag effectively truncates the property, 29.919
On 02/07/2007 09:47 AM, Ron Jensen wrote:
> While working on 3D cockpit instruments I keep hitting into issues with
> internal floating point representation and the tag.
>
> The tag effectively truncates the property, 29.9199
> becomes 29.91, so a (3D) readout reads off one number.
> I
While working on 3D cockpit instruments I keep hitting into issues with
internal floating point representation and the tag.
The tag effectively truncates the property, 29.9199
becomes 29.91, so a (3D) readout reads off one number. The electronics
technician in me says, "but digital read
22 matches
Mail list logo
