Re: [Flightgear-devel] JavaScript!
David Megginson wrote: > Erik Hofman writes: > > > or do you mean: > > > > fgfs.set > > fgfs.setBoolean > > fgfs.get > > fgfs.getBoolean > > Yes, that stuff. It looks reasonable. Reasonable??? It's the same syntax you used for the Java library! :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Norman Vine wrote: > > Have you looked at SWIG ??? No, I dont know the package. > > The reason I ask is this looks nearly identical to the code SWIG > would output for JavaScript from a SWIG interface file for > > fgSetString(char * , char *) > > The beauty of using SWIG is that the same interface file would support > JavaScript, Perl, Python, TCL-Tk, Mzscheme, guile ... giving a choice > of which Interpreter was compiled in. Is this a scripting engine, or a code generator? If it is a scripting engine wouldn't that mean the scripts would actually be one of: javascript, python, etc. That looks like it would make things difficult for script writers. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Antialiased GLUT fonts
> FlightGear folks: how do you want to handle this? We can [1] use the > new fonts, which won't render well (very W I D E spacing) in unpatched > versions of plib, [2] use a slightly hacked new-style font that chops > off a few characters but renders with appropriate spacing in all > versions of plib, or [3] wait for a new plib release before making a > decision. Since we're currently tracking plib CVS pretty closely > anyway (the AC3D shading issue), I'd argue for #1. We can always > provide a property-based fallback to typewriter.txf for releases. I think the next version of FlightGear will require plib-1.5 anyway (I had an outstanding issue with the menuBar code also), so I opt for #1. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
Norman Vine wrote: > Have you looked at SWIG ??? > > The reason I ask is this looks nearly identical to the code SWIG > would output for JavaScript from a SWIG interface file for > > fgSetString(char * , char *) Hmm, there is no mention of JavaScript support. They do support Java. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Javascript source
Hi, I've placed the javascript code on my website at: http://www.a1.nl/~ehofman/fgfs/download/avascript-20020628.tar.gz http://www.a1.nl/~ehofman/fgfs/download/fgfs_base_script-20020628.tar.gz This is very preliminary code, but should give you a hunch. BTW, this needs the javascript library installed on you system. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Javascript source
Erik Hofman wrote: > > > Hi, > > I've placed the javascript code on my website at: No I haven't. Can find the location of my homepages on my ISP's webserver ... :-( Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
A couple of comments on the scripting issue: JavaScript is a really nice language, but you aren't going to get a very small runtime without losing useful things (like regular expressions). However, the sources are readily available, as has already been noted. My day job is working with Mozilla based products, and more than 1/2 our application logic is written in JS (pretty much all the UI and glue logic) JS is very effective and manageable, orders of magnitude moreso than Perl. Python is equally good as the code size grows, but the syntax puts people off and the common library is huge as Norman (I think?) already pointed out.. JS doesn't have a common library in the same way. Anyway, you can't (easily) leverage the JS runtime that ships with Mozilla, it's been subtly tweaked for Mozilla integration, and is often a not-quite-release version. It is technically possible to use the runtime, but I would strongly recommend not bothering to try, since it will introduce many complications. For one thing, it's sitting in a strange place: the Mozilla non-XPCOM shared object directory, which will be something like /usr/lib/mozilla, /opt/mozilla or possibly /opt/gnome/lib/mozilla (under Ximian). Should the user have a static Mozilla build (I don't know if this is ever going to happen in practice, but it keeps getting talked about) there won't even be a shared object to link to. In terms of embedding a really small interpreter, I know various people who've used Lua with great success (it seems designed to be inlined into a 'host' source tree and modified, not kept distinct), and it's really, really small. Never used it personally, but worth investigation if disk size is the primary consideration. Also, the dependency issues go away (in the projects I know that have added Lua, there has never been a support issue related to it) One final point : everything I've heard about SWIG indicates that it handles OO systems badly: it maps straight C to Perl/Tcl/etc well, but when you want to map classes to Java / Python / JS, it falls down pretty quickly. When I embedded Python in some of my own code, I tried using SWIG briefly, gave up, and was able to use the native Python API far more effectively. Sorry this drifted rather far OT, all just my 2 pence, of course. James
Re: [Flightgear-devel] JavaScript!
Erik Hofman writes: > > Yes, that stuff. It looks reasonable. > > Reasonable??? > It's the same syntax you used for the Java library! I'm (well) over 18, so from me "reasonable" is higher praise than "cool". All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] JavaScript!
David Megginson wrote: > Erik Hofman writes: > > > > Yes, that stuff. It looks reasonable. > > > > Reasonable??? > > It's the same syntax you used for the Java library! > > I'm (well) over 18, so from me "reasonable" is higher praise than > "cool". Ah, I almost forgot, you're Canadion aren't you? :-) Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] autopilot engage bindings
As I mentioned before the changes to the autopilot code will involve an "engage" function. Rather than turning on autopilot automatically by selecting a mode (as it does now) the pilot will need to engage it. I'm proposing that the key for engage/disengage be CTRL+E. The current key bindings for autopilot (the ones I know about) will work as follows: CTRL+A - turn off/on ALT-ARM (ALT-HLD or PITCH-HLD would be the default on CTRL+E) depending on XML configuration. CTRL+H - turn off/on HDG-ARM (HDG-HLD or WL would be the default on CTRL-E depending on XML configuration. CTRL+N - turn off/on HDG-NAV1-ARM (or HDG-NAV1 if active mode) returns to default lateral mode (HDG-HLD or WL) depending on XML configuration. CTRL+G - turn off/on GS-NAV1-ARM (or GS-NAV1 if active mode) if off, returns to default verticle mode (ALT-HLD or PITCH-HLD) depending on XML configuration. Note that the only way to disengage and take over the controls will be CTRL+E. This might actually make things a little easier, not sure about anyone else but on more than one occaision I've gotten messed up by hitting CTRL+H instead of CTRL+N to disengage the lateral axis while on approach :-) Also note that as far as I know a two (or three) axis autopilot always operates on the two primary axiis. In other words, there is no such thing as engaging the multi-axis autopilot on just one axis, or ap on one and fd on another. Anyone know of specific configurations that do not do this? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] autopilot engage bindings
On Fri, 2002-06-28 at 05:12, Jim Wilson wrote: > As I mentioned before the changes to the autopilot code will involve an > "engage" function. Rather than turning on autopilot automatically by selecting > a mode (as it does now) the pilot will need to engage it. > > I'm proposing that the key for engage/disengage be CTRL+E. > > The current key bindings for autopilot (the ones I know about) will work as > follows: > > CTRL+A - turn off/on ALT-ARM (ALT-HLD or PITCH-HLD would be the default on > CTRL+E) depending on XML configuration. > CTRL+H - turn off/on HDG-ARM (HDG-HLD or WL would be the default on CTRL-E > depending on XML configuration. > > CTRL+N - turn off/on HDG-NAV1-ARM (or HDG-NAV1 if active mode) returns to > default lateral mode (HDG-HLD or WL) depending on XML configuration. > CTRL+G - turn off/on GS-NAV1-ARM (or GS-NAV1 if active mode) if off, returns to > default verticle mode (ALT-HLD or PITCH-HLD) depending on XML configuration. > > Note that the only way to disengage and take over the controls will be > CTRL+E. This might actually make things a little easier, not sure about > anyone else but on more than one occaision I've gotten messed up by hitting > CTRL+H instead of CTRL+N to disengage the lateral axis while on approach :-) > > Also note that as far as I know a two (or three) axis autopilot always > operates on the two primary axiis. In other words, there is no such thing as > engaging the multi-axis autopilot on just one axis, or ap on one and fd on > another. Anyone know of specific configurations that do not do this? You mean engage a pitch mode without engaging a lateral mode? Yes, that's very doable. > > Best, > > Jim > > ___ > Flightgear-devel mailing list > [EMAIL PROTECTED] > http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A Curiosity ...
In the past 36 hours, almost all of the subject lines I've seen come through fg-devel have started with the letter "a" or "j". Something must be done about this. I much prefer topics that begin with an "f" or an "x-". Studies have shown I am not alone. ;-) ;-) P.S. Dh! My own post's subject line here starts with "a". smime.p7s Description: application/pkcs7-signature
RE: [Flightgear-devel] JavaScript!
James Turner writes: > A couple of comments on the scripting issue: > JS is very effective and> manageable, orders of magnitude moreso than Perl. This is good to hear. > Python is equally> good as the code size grows, but the syntax puts people off a simple matter of taste, for example the other 'P' language syntax makes me cringe, similarly to what Python's 'whitespace' does for some :-) > the common library is hugeThis is true, however IMHO this is a plus in that thereis a large body of well TESTED code that can just be usedas is, FYI it is also quite fine grained and is 'cross-platform'. > In terms of embedding a really small interpreter, I know various> people who've used Lua with great success Yes, I have heard the same > One final point : everything I've heard about SWIG indicates that it> handles OO systems badly: it maps straight C to Perl/Tcl/etc well,> but when you want to map classes to Java / Python / JS, it falls down> pretty quickly. This use to be a problem however the latest version of SWIG is much more OO friendly, it even has a 'reasonably' complete C++ parser builtin !! > When I embedded Python in some of my own code, I> tried using SWIG briefly, gave up, and was able to use the native> Python API far more effectively. SWIG does take a 'bit' of work to get used to BUTonce over the hurdle it is MUCH easier to keep in'sync' with the 'C' code base in that it 'usually' just uses the project header files or a subset of them to generate the 'wrappers' from. Plus with a little more thought you can get Multi-Language support too ! Norman
[Flightgear-devel] 3D Panel and LOD
Am I right in assuming that the 3D panel is now always drawn, even in external view? In that case, we might want to consider either hard-coding it under an LOD node so that it's skipped when the viewing distance is (say) >3m, or allowing the user to specify a name for each panel node so that the animations can specify an LOD. Andy, any preference? All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Plib-devel] Antialiased GLUT fonts #2
On Fri, 28 Jun 2002, [EMAIL PROTECTED] (Steve Baker) wrote: > Date: Fri, 28 Jun 2002 05:53:15 -0500 > To: [EMAIL PROTECTED] > From: [EMAIL PROTECTED] (Steve Baker) > CC: [EMAIL PROTECTED], [EMAIL PROTECTED] > Reply-To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Re: [Plib-devel] Antialiased GLUT fonts #2 [...] > Can we add this tool into PLIB in the 'tools' area? It would be a > marvelous addition. Sure it would ! - Sebastian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Antialiased GLUT fonts
On Thu, 27 Jun 2002, [EMAIL PROTECTED] (Andy Ross) wrote:
> Date: Thu, 27 Jun 2002 21:01:09 -0700
> To: [EMAIL PROTECTED], [EMAIL PROTECTED]
> From: [EMAIL PROTECTED] (Andy Ross)
> Reply-To: [EMAIL PROTECTED]
> Subject: [Flightgear-devel] Re: Antialiased GLUT fonts
>
> 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.
Very nice - well done, again !
[...]
> Anyway, it seems to work. One thing to worry about (and for which I
> did not test) is the effect this patch will have on older fonts. The
> code now interprets a value ("step"), which it used to ignore. If
> older fonts don't set this correctly, they will be misrendered by
> plib. I did a spot check of the fonts distributed with FlightGear,
> and they look OK. Hopefully all fonts generated by Mark's tool will
> be equally fine.
I think so.
> I've generated a new set of font files with proper padding and put
> them back up on my web site (http://plausible.org/glut-fonts -- no, I
> didn't change the URL to remove the reference to glut).
Okay; I updated my mirror:
http://www.ude.handshake.de/txffonts/
Again, if you want to download the entire set of fonts, I recommend to use
that link in order to keep the load off Andy's cable modem.
> These look much nicer after the patch -- no chopped characters, and
> proper font metrics for all.
Yes.
- Sebastian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: 3d Panel problem
Jim Wilson wrote: > One thing I'm wondering is if we can do away with the background > texture in the 3-D panel. Do we need it or can the "backplane" always > be part of the model? Not sure if this would fix the problem with the > 3-D model/instrument or not. There's no real need for the "panel" to have a background in a 3D environment. It makes more sense, IMHO, for the background texture to be part of the model geometry. I think that right now the background (multi-)texture is required, but that'll be easy to fix. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New font / updated patch
FlightGear folks: I just checked in a nice Helvetica.txf into the base
package. Before you can use this, you need two things. The first is
a trivial patch to gui.cxx that allows for setting the default font
via properties (while leaving the original default in place). In
src/GUI/gui.cxx, line 995, replace this:
fntpath.append( "typewriter.txf" );
With this:
fntpath.append(fgGetString("/sim/font", "typewriter.txf"));
The second thing you need is a patched plib. There is a patch
attached to the current plib CVS that fixes a bug that this font file
needs. If you don't apply it, you will see the new font rendered with
far too much space between characters.
Plib folks: this patch supersedes the one I sent yesterday. My first
one missed a spot. The calculation of string width needs to use the
new width metrics too, otherwise the strings themselves will print
acceptably, but be laid out with too much space.
Andy
--
Andrew J. RossNextBus Information Systems
Senior Software Engineer Emeryville, CA
[EMAIL PROTECTED] http://www.nextbus.com
"Men go crazy in conflagrations. They only get better one by one."
- Sting (misquoted)
Index: src/fnt/fnt.cxx
===
RCS file: /cvsroot/plib/plib/src/fnt/fnt.cxx,v
retrieving revision 1.7
diff -u -r1.7 fnt.cxx
--- src/fnt/fnt.cxx 12 Dec 2001 23:49:36 - 1.7
+++ src/fnt/fnt.cxx 29 Jun 2002 06:05:33 -
@@ -102,14 +102,14 @@
curpos[2] ) ;
glEnd () ;
- float ww = ( gap + ( fixed_pitch ? width : v_right[cc] ) ) * pointsize ;
+ float ww = ( gap + ( fixed_pitch ? width : widths[cc] ) ) * pointsize ;
curpos[0] += ww ;
return ww ;
}
-void fntTexFont::setGlyph ( char c,
+void fntTexFont::setGlyph ( char c, float wid,
float tex_left, float tex_right,
float tex_bot , float tex_top ,
float vtx_left, float vtx_right,
@@ -119,6 +119,8 @@
exists[cc] = FNT_TRUE ;
+ widths[cc] = wid;
+
t_left[cc] = tex_left ; t_right[cc] = tex_right ;
t_bot [cc] = tex_bot ; t_top [cc] = tex_top ;
@@ -127,7 +129,7 @@
}
-int fntTexFont::getGlyph ( char c,
+int fntTexFont::getGlyph ( char c, float* wid,
float *tex_left, float *tex_right,
float *tex_bot , float *tex_top ,
float *vtx_left, float *vtx_right,
@@ -137,6 +139,8 @@
if ( ! exists[cc] ) return FNT_FALSE ;
+ if ( wid != NULL ) *wid = widths [cc] ;
+
if ( tex_left != NULL ) *tex_left = t_left [cc] ;
if ( tex_right != NULL ) *tex_right = t_right[cc] ;
if ( tex_bot != NULL ) *tex_bot = t_bot [cc] ;
@@ -209,7 +213,7 @@
if ( b > v_pos + v_bot [cc] ) b = v_pos + v_bot [cc] ;
if ( t < v_pos + v_top [cc] ) t = v_pos + v_top [cc] ;
-h_pos += gap + ( fixed_pitch ? width : v_right[cc] ) ;
+h_pos += gap + ( fixed_pitch ? width : widths[cc] ) ;
}
if ( left != NULL ) *left = l * pointsize ;
Index: src/fnt/fnt.h
===
RCS file: /cvsroot/plib/plib/src/fnt/fnt.h,v
retrieving revision 1.5
diff -u -r1.5 fnt.h
--- src/fnt/fnt.h 7 Nov 2001 23:51:09 - 1.5
+++ src/fnt/fnt.h 29 Jun 2002 06:05:33 -
@@ -90,6 +90,10 @@
v_bot==0.0 and v_top==1.0.
*/
+ /* Nominal baseline widths */
+
+ float widths [ FNTMAX_CHAR ] ;
+
/* Texture coordinates */
float t_top [ FNTMAX_CHAR ] ; /* Topedge of each character [0..1] */
@@ -171,19 +175,19 @@
float getGap () const { return gap ; }
- void setGlyph ( char c,
+ void setGlyph ( char c, float wid,
float tex_left, float tex_right,
float tex_bot , float tex_top ,
float vtx_left, float vtx_right,
float vtx_bot , float vtx_top ) ;
- int getGlyph ( char c,
+ int getGlyph ( char c, float* wid,
float *tex_left = NULL, float *tex_right = NULL,
float *tex_bot = NULL, float *tex_top = NULL,
float *vtx_left = NULL, float *vtx_right = NULL,
float *vtx_bot = NULL, float *vtx_top = NULL) ;
- int hasGlyph ( char c ) { return getGlyph ( c ) ; }
+ int hasGlyph ( char c ) { return exists[ c ] ; }
void getBBox ( const char *s, float pointsize, float italic,
float *left, float *right,
Index: src/fnt/fntTXF.cxx
===
RCS file: /cvsroot/plib/plib/src/fnt/fntTXF.cxx,v
retrieving revision 1.14
diff -u -r1.14 fntTXF.cxx
--- src/fnt/fntTXF.cxx 21 Apr 2002 03:53:15 - 1.14
+++ src/fnt/fntTXF.cxx 29 Jun 2002 06:05:34 -
@@ -246,6 +246,7 @@
glyph . y = _fnt_readShort () ;
setGlyph ( (char) glyph.ch,
+ (float) glyph.step / (float) max_height,
(float) glyph.x / (float) w + xstep,
(float)
