* [EMAIL PROTECTED] (Andy Ross) [2002.06.27 23:11]:
> I wrote:
> > FlightGear folks: how do you want to handle this?
>
> Obligatory screenshot: http://www.plausible.org/andy/newfont.png
Obligatory exclamation: woohoo! Nice!
--
Cameron Moore
/ I asked the librarian where the self-help section
Steve Baker wrote:
> Can we add this tool into PLIB in the 'tools' area? It would be a
> marvelous addition.
All yours. As I pointed out, though, it's definitely a tool of the
"duct tape and fishing line" variety. :) It expects to find a
ghostscript interpreter and ImageMagick's "mogrify" prog
Andy Ross wrote:
> Sebastian Ude wrote:
>
>>What you generated are neither GLUT bitmap nor GLUT stroke fonts (the
>>only place where you usually find *these* fonts is the GLUT sourcecode
>>!), but TXF fonts / textured fonts / font textures. These fonts have
>>hardly anything to do with *GLUT*.
Sebastian Ude wrote:
> One more thing - why are you talking about GLUT fonts all the time ?
>
> What you generated are neither GLUT bitmap nor GLUT stroke fonts (the only
> place where you usually find *these* fonts is the GLUT sourcecode !), but
> TXF fonts / textured fonts / font textures. T
I wrote:
> FlightGear folks: how do you want to handle this?
Obligatory screenshot: http://www.plausible.org/andy/newfont.png
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"M
OK, the attached patch adds character width support to the fnt
library, allowing it to handle glyphs whose logical width (distance
along the baseline to the next character) differs from their physical
width. Characters like the slash have this property, as do many
italic glyphs.
The current anti
I wrote:
> David Megginson wrote:
> > Speaking of taunting, do you have any ideas about the problem I
> > mentioned earlier -- that no text shows up on the radios in your new
> > 3D panel patch? It's the only thing stopping me from committing it.
>
> None yet, I need to get home and try it. Noth
On Thu, 27 Jun 2002, [EMAIL PROTECTED] (Andy Ross) wrote:
> Date: Thu, 27 Jun 2002 17:40:58 -0700
> To: [EMAIL PROTECTED]
> From: [EMAIL PROTECTED] (Andy Ross)
> CC: [EMAIL PROTECTED]
> Subject: Re: [Flightgear-devel] Re: [Plib-devel] Antialiased GLUT fonts
> #2
[...]
> Clearly I'm ignorant of
Sebastian Ude wrote:
> What you generated are neither GLUT bitmap nor GLUT stroke fonts (the
> only place where you usually find *these* fonts is the GLUT sourcecode
> !), but TXF fonts / textured fonts / font textures. These fonts have
> hardly anything to do with *GLUT*.
Clearly I'm ignorant of
On Thu, 27 Jun 2002, [EMAIL PROTECTED] (Andy Ross) wrote:
> Date: Thu, 27 Jun 2002 16:29:57 -0700
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> From: [EMAIL PROTECTED] (Andy Ross)
> Subject: [Plib-devel] Antialiased GLUT fonts
>
> [Cross-posted to the plib list, as this isn't entirely FlightGear
On Thu, 27 Jun 2002, [EMAIL PROTECTED] (Andy Ross) wrote:
> Date: Thu, 27 Jun 2002 16:29:57 -0700
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> From: [EMAIL PROTECTED] (Andy Ross)
> Subject: [Plib-devel] Antialiased GLUT fonts
[...]
> The recent discussion about fonts got me interested in actua
Erik Hofman writes:
> or do you mean:
>
> fgfs.set
> fgfs.setBoolean
> fgfs.get
> fgfs.getBoolean
Yes, that stuff. It looks reasonable.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-d
[Cross-posted to the plib list, as this isn't entirely FlightGear
specific. Dunno if that list allows posts from non-subscribers or
not.]
The recent discussion about fonts got me interested in actually trying
something, so I put together a perl utility that generates an
antialiased Glut .txf f
Erik Hofman writes:
>
>David Megginson wrote:
>>
>> Erik -- what do your bindings look like?
>
>You mean the code to bind a JavaScript function to a C function:
>
>static JSBool
>_fgs_set(JSContext *cx, JSObject *obj, uintN argc, jsval
>*argv, jsval *rval)
>{
>const char *node, *str;
>
>
Andy Ross writes:
> Curtis L. Olson wrote:
> > I should mention before we get too far that glPolygonOffset is not
> > always consistantly implimented across cards/drivers.
>
> Is that really true anymore? I know it used to be true ~5 years ago
> in the era of "QuakeGL", but today things are real
Curtis L. Olson wrote:
> I should mention before we get too far that glPolygonOffset is not
> always consistantly implimented across cards/drivers.
Is that really true anymore? I know it used to be true ~5 years ago
in the era of "QuakeGL", but today things are really quite stable.
The glPolygon
David Megginson <[EMAIL PROTECTED]> said:
> Curtis L. Olson writes:
>
> > For what it's worth, I believe I can see the model jittering by a
> > small amount from the chase view (zoomed way in.)
>
> That surprises me more. In interior view, the model is in a separate
> scene graph with a diff
Andy Ross <[EMAIL PROTECTED]> said:
> Yes, but even between iterations, the FPU error introduces a random
> 3mm value to the positions you are using. It doesn't matter whether
> the FDM is right or wrong -- even the tiniest different in input
> values will result in a 3mm jitter. If the FDM say
Erik Hofman writes:
> Curtis L. Olson wrote:
>
> > It would be interesting to see if the current differences in the
> > values amount to a single bit difference or something larger. If they
> > are just a "bit" (literally) different from each other, then doing the
> > math in double precision mi
Curtis L. Olson wrote:
> It would be interesting to see if the current differences in the
> values amount to a single bit difference or something larger. If they
> are just a "bit" (literally) different from each other, then doing the
> math in double precision might not help ... if the double p
David Megginson wrote:
> Erik Hofman writes:
>
> > We might want to go for js-1.3 then:
> > -rw-rw-r-- 1 22 22481442 Sep 1 1998 js-1.3-1.tar.gz
>
> Could we trim that down by another 75% or so?
A quck look reveiled:
-rw-r--r--1 erik user 338033 Jun 27 21:03 src.
Andy Ross writes:
> David Megginson wrote:
> > Speaking of taunting, do you have any ideas about the problem I
> > mentioned earlier -- that no text shows up on the radios in your new
> > 3D panel patch? It's the only thing stopping me from committing it.
>
> None yet, I need to get home and try
Andy Ross <[EMAIL PROTECTED]> said:
> That's true for position jitter, but not for orientation. But even if
> it's position, the jitter should still cause a change in position of
> the scenery, not the cockpit. Remember that the cockpit *is* the
> aircraft -- no matter what the position is, it
David Megginson wrote:
> Erik Hofman writes:
>
> > -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz
> > -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz
>
> What does everyone else think? Should this be bundled unpacked in the
> SimGear source t
David Megginson wrote:
> Speaking of taunting, do you have any ideas about the problem I
> mentioned earlier -- that no text shows up on the radios in your new
> 3D panel patch? It's the only thing stopping me from committing it.
None yet, I need to get home and try it. Nothing looks suspicious
Jim Wilson wrote:
> Those are from two different iterations. I was just proving that the
> viewer and model were running on the same data, as it had been
> suggested they were not earlier. The pairs within a single iteration
> match (this is the same data I posted earlier):
Yes, but even betwee
That sounds like a reasonable change to include.
Thanks,
Curt.
Melchior FRANZ writes:
> The 'if' condition is based on a value that was not initialised, which
> might cause random jumps.
>
> kr_87.cxx:170:
> if ( adf_valid ) {
>
> m.
>
>
> PS: CC to the list, because debugging with val
The 'if' condition is based on a value that was not initialised, which
might cause random jumps.
kr_87.cxx:170:
if ( adf_valid ) {
m.
PS: CC to the list, because debugging with valgrind can be quite time
consuming and other people shouldn't debug the same bugs during the
phase of p
Andy Ross writes:
> > I can no longer repeat it.
>
> Sigh. I think it's taunting us.
Speaking of taunting, do you have any ideas about the problem I
mentioned earlier -- that no text shows up on the radios in your new
3D panel patch? It's the only thing stopping me from committing it.
Th
Andy Ross <[EMAIL PROTECTED]> said:
> Jim Wilson wrote:
>
> Oooh, but they're not! Take a really close look at the two position
> vectors (the last row):
>
> > 5064.624023 590.030945 -1211.297729 1.00
> > 5064.621582 590.031433 -1211.296509 1.00
>
Those are from two different iteratio
Curtis L. Olson writes:
> For what it's worth, I believe I can see the model jittering by a
> small amount from the chase view (zoomed way in.)
That surprises me more. In interior view, the model is in a separate
scene graph with a different clip plane, but in exterior view, it's
just another
David Megginson wrote:
> Andy Ross writes:
> > David, if you're getting this repeatably, would you mind tracing
> > the bad values in gdb with a watchpoint?
>
> I can no longer repeat it.
Sigh. I think it's taunting us.
Andy
--
Andrew J. RossNextBus Information Systems
Senior
Erik Hofman writes:
> We might want to go for js-1.3 then:
> -rw-rw-r-- 1 22 22481442 Sep 1 1998 js-1.3-1.tar.gz
Could we trim that down by another 75% or so?
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
_
Andy Ross writes:
> I saw it once, but unfortunately didn't track it far enough. It's
> since stopped happening to me. David, if you're getting this
> repeatably, would you mind tracing the bad values in gdb with a
> watchpoint?
I can no longer repeat it.
All the best,
David
--
David
Curtis L. Olson writes:
> I would argue that if we do embed a script interpreter it should be
> really small, tight, and light weight. 1Mb of compressed source seems
> excessive ... this is almost exactly the same size as the entire
> flightgear source, so we'd be roughly doubling the size o
Andy Ross writes:
> Oooh, but they're not! Take a really close look at the two position
> vectors (the last row):
>
> > 5064.624023 590.030945 -1211.297729 1.00
> > 5064.621582 590.031433 -1211.296509 1.00
Ahh, good catch ...
> These are the same up to 6 significant figures, but they d
Andy Ross writes:
> Really, I don't see any other options -- whatever is causing the
> jitter is inside the model's scene graph, and not under the scenery.
> Since the FDM output goes into both, you have to rule it out (or you
> can put printf's in the update routines and verify that inter-frame
>
Jim Wilson wrote:
> Setting all the view offsets to 0 I was able to prove that the
> position/rotation matrices generated on the model and the camera are
> numerically identical. Here's a sample from the dump:
Oooh, but they're not! Take a really close look at the two position
vectors (the last
David Megginson wrote:
> Erik Hofman writes:
>
> > -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz
> > -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz
> Does anyone know of a smaller ECMAScript implementation?
We might want to go for js-1.3 th
Andy Ross wrote:
> David Megginson wrote:
>
>>Erik Hofman writes:
>>
>>>-rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz
>>>-rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz
>>
>>What does everyone else think?
>
>
> I dunno. That's awfully big. J
Curtis L. Olson wrote:
> I would argue that if we do embed a script interpreter it should be
> really small, tight, and light weight.
Amen. :)
It's possible that the source for the actual interpreter is much
smaller than the full package, though. JavaScript implementations are
likely to be aime
Norman Vine wrote:
> Erik Hofman writes:
>
>
>>Isn't there any trick with the puObject member either (I just need to
>>know which menu entry is causing the callback)?
>
>
> why not just use use the puObject pointer
>
> /* print the 'menu text' of calling menu entry on stdout */
> void t
David Megginson wrote:
> Erik Hofman writes:
> > -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz
> > -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz
>
> What does everyone else think?
I dunno. That's awfully big. JavaScript isn't a terribly big
Jim Wilson wrote:
> David Megginson <[EMAIL PROTECTED]> said:
> > On that point, I've tried your patch and it works, but the YASim FDM
> > is then (inexplicably) frozen. Is it working for anyone else?
>
> This is a bug that seems to be related to some sort of memory
> corruption. I've seen it of
David Megginson wrote:
>
> What does everyone else think? Should this be bundled unpacked in the
> SimGear source tree and built automatically (as with expat, our XML
> parser), bundled as an archive so that users can build it if they
> don't already have it installed (as with metakit and zlib),
Jim Wilson wrote:
> Andy Ross said:
> > If the FDM points left, the cockpit will point left by the same
> > amount. Jitter from the FDM would cause the *scenery* to jitter,
> > not the cockpit.
>
> No it would not. The scenery is too far away. Further pixels require
> bigger values to shift. D
David Megginson writes:
> Erik Hofman writes:
>
> > -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz
> > -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz
>
> What does everyone else think? Should this be bundled unpacked in the
> SimGear source
Erik Hofman writes:
> -rw-r--r--1 erik user 648823 May 12 2001 js-1.4-2.tar.gz
> -rw-r--r--1 erik user 1046117 Mar 13 19:12 js-1.5-rc4.tar.gz
What does everyone else think? Should this be bundled unpacked in the
SimGear source tree and built automatically (as with
Erik Hofman writes:
>Isn't there any trick with the puObject member either (I just need to
>know which menu entry is causing the callback)?
why not just use use the puObject pointer
/* print the 'menu text' of calling menu entry on stdout */
void tattle_tale_cb( puObject *me)
{
printf("
Jim Wilson <[EMAIL PROTECTED]> said:
> Erik Hofman <[EMAIL PROTECTED]> said:
>
> > Well, I am dynamically generating the menu structure. That means I can't
> > use a per entry callback function. I need just one number/pointer/hint
> > in the callback to get it working.
> >
> Make a child cl
Erik Hofman <[EMAIL PROTECTED]> said:
> Well, I am dynamically generating the menu structure. That means I can't
> use a per entry callback function. I need just one number/pointer/hint
> in the callback to get it working.
>
Make a child class that has all the necessary data in it. And make
On Thu 27. June 2002 13:25, you wrote:
> Curtis L. Olson writes:
> > Admittedly this is for somewhat selfish reasons (I'm working on a side
> > project where the primary instruments will fill an entire display and
> > the out-the-window visuals will be on a second display.) So I vote
> > for
Gene Buckle <[EMAIL PROTECTED]> said:
> > extended position. Part
> > of the walk-around is to push up on the slats and note free and easy
> > movement. Air pressure against the wing moves them to the retracted
> > position. As airpseed is increased/reduced they extend or retract in
> > response
[EMAIL PROTECTED] said:
> Well, _position_ jitter would hardly affect the scenery, but orientation
jitter (if it is orientation about the eye-point) would show up in equal
amounts on everything that is affected by it.
>
That is correct, if your screen resolution was extremely high or the image
a
Norman Vine <[EMAIL PROTECTED]> said:
> I have to admit that I DON'T know how FGFS draws things anymore but
> Is this due to the calling of global_tile_mgr.update() twice in the Main
> Loop and causing 'confusion' as to what is the 'current' and the 'next'
> scenery center
>
No and IIRC th
David Megginson wrote:
> Erik Hofman writes:
>
> > > and (2) small? We can already do scripting, of course, though
> >
> > -rwxr-xr-x1 erik user 826244 Mar 13 14:19 libjs.so
>
> I'm actually more concerned about the source tree size.
-rw-r--r--1 erik user 648823
> extended position. Part
> of the walk-around is to push up on the slats and note free and easy
> movement. Air pressure against the wing moves them to the retracted
> position. As airpseed is increased/reduced they extend or retract in
> response to the
> corresponding force of the relative wind
Erik Hofman writes:
> > and (2) small? We can already do scripting, of course, though
>
> -rwxr-xr-x1 erik user 826244 Mar 13 14:19 libjs.so
I'm actually more concerned about the source tree size.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.meggi
David Megginson wrote:
> Erik Hofman writes:
>
> > Good news (if you ask me)! I have an ECMA (Java)Script running in
> > FlightGear, accessable true the menu (actually dynamically controllable
> > trough a scripts.cml file). I now can toggle the sound on and of using
> > JavaScript!
>
> W
Norman Vine wrote:
>>>There is a small problem though, is there any way to pass an
>>>argument to
>>>a PLIB menuBar Callback function?
>>
>>NO
>>
>>use class data members, global variables or functions to get
>>the 'arguments' within the callback()
>
>
> PLIB questions should really be asked
Erik Hofman writes:
> Good news (if you ask me)! I have an ECMA (Java)Script running in
> FlightGear, accessable true the menu (actually dynamically controllable
> trough a scripts.cml file). I now can toggle the sound on and of using
> JavaScript!
Wow -- excellent news. Is the interpret
[EMAIL PROTECTED] writes:
> It's not something silly like the /sim/panel/jitter property being
> non-zero, is it? Nah... that would be too silly.
That would have no effect on the aircraft model.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
__
Norman Vine writes:
>
>Erik Hofman writes:
>>
>>There is a small proble though, is there any way to pass an
>>argument to
>>a PLIB menuBar Callback function?
>
>NO
>
>use class data members, global variables or functions to get
>the 'arguments' within the callback()
PLIB questions should reall
Erik Hofman writes:
>
>There is a small proble though, is there any way to pass an
>argument to
>a PLIB menuBar Callback function?
NO
use class data members, global variables or functions to get
the 'arguments' within the callback()
Norman
___
Jim Wilson writes:
>
>Andy Ross <[EMAIL PROTECTED]> said:
>
>> Jim Wilson wrote:
>> > On further investigation, it appears that this is almost certainly due
to
>> > normal variation in fdm position and orientation output.
>>
>> This theory doesn't work though. Think about it: in cockpit mode, the
Hi,
Good news (if you ask me)! I have an ECMA (Java)Script running in
FlightGear, accessable true the menu (actually dynamically controllable
trough a scripts.cml file). I now can toggle the sound on and of using
JavaScript!
There is a small proble though, is there any way to pass an argumen
Jim Wilson wrote:
>
> Andy Ross <[EMAIL PROTECTED]> said:
>
> > Jim Wilson wrote:
> > > On further investigation, it appears that this is almost certainly due to
> > > normal variation in fdm position and orientation output.
> >
> > This theory doesn't work though. Think about it: in cockpit m
This can be caused by the value of remaining in
FG interface not initialized as I wrote earlier.
It makes _calc_multiloop return 0 and freeze FDM
and animations
Cheers,
-Fred
>Messsage du 27/06/2002 13:30
>De : <[EMAIL PROTECTED]>
>A : <[EMAIL PROTECTED]>
>Copie à :
>Objet : Re: [Flightgear-
David Megginson <[EMAIL PROTECTED]> said:
> On that point, I've tried your patch and it works, but the YASim FDM
> is then (inexplicably) frozen. Is it working for anyone else?
>
This is a bug that seems to be related to some sort of memory corruption.
I've seen it off and on over the last cou
Andy Ross <[EMAIL PROTECTED]> said:
> Jim Wilson wrote:
> > On further investigation, it appears that this is almost certainly due to
> > normal variation in fdm position and orientation output.
>
> This theory doesn't work though. Think about it: in cockpit mode, the
> orientation of the aircr
David Megginson writes:
> On that point, I've tried your patch and it works, but the YASim FDM
> is then (inexplicably) frozen. Is it working for anyone else?
OK, it's working for me now with the files Andy sent, with one
exception -- none of the text on the radio displays on the C172 panel
s
Andy Ross writes:
> The panel doesn't (er, didn't) jitter because it's drawn via an
> entirely different code path that doesn't look at aircraft orientation
> at all -- only viewing offsets. If you apply my current 3D panel
> code, you'll see the whole cockpit assembly wiggle in exactly the
Curtis L. Olson writes:
> It seems strange that everything else in the cockpit and 3d model of
> the aircraft is perfectly stable and only this one instrument is
> jittery.
On the contrary, the instrument and the 3D cockpit jitter. It's the
2D panel overlaid that appears to be stable.
All
Jim Wilson writes:
> Maybe anti-aliasing would fix the problem, but it seems that the
> only reasonable way to get rid of this is to make the cockpit a
> special case model and overlay it after all the scenery, etc. is
> rendered (without the position/orientation transformations). On
> the
Curtis L. Olson writes:
> Admittedly this is for somewhat selfish reasons (I'm working on a side
> project where the primary instruments will fill an entire display and
> the out-the-window visuals will be on a second display.) So I vote
> for someone to create instruments where each instrum
75 matches
Mail list logo
