RE: [Flightgear-devel] Duplicate properties?
Andy Ross writes: > >Christian Mayer wrote: >> Andy Ross wrote: >> > Problem is, I don't know anything about the glut font format, and a >> > cursory look around the web didn't turn up any pointers. Does >> > anyone know this stuff well enough to write up a quick format >> > document? >> >> You don't need to create a GLUT font. You only need to create a *.rgb >> texture file with the renderd letters for PLIB. Just have a look at >> those that are already distributed with PLIB and the PLIB >source code. > >But the font metrics have to be stored somewhere, right? That was my >point: creating a texture file is really easy. But actually rendering >an arbitrary font to the screen requires more info, and I don't know >how or where to put it. I was under the impression that plib used the >glut ".txf" font format, but maybe I'm mistaken? umh < sollowing snipped from http://plib.sourceforge.net/fnt/index.html > Making New TXF Fonts. The '.txf' font format was designed by Mark Kilgard - who also produced some tools for dealing with them. Check Marks's document about Textured Fonts for further information. Of particular interest is Mark's "gentexfont" program that can create a TXF format font from an X-windows font. You can find out which X-fonts are stored on your machine using the /usr/X11/bin/xlsfonts program. There are over a dozen sample TXF fonts stored in examples/src/fnt/data. http://www.opengl.org/developers/code/mjktips/TexFont/TexFont.html ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Buffer overflow in auto_gui.cxx
Andy Ross writes: > >I got bitten by some static data corruption problems > > sprintf(buffer, "%05.2f", value); > >In my copy, I fixed this with snprintf, but something nags at me that >this isn't portable to some platform we care about. #include should take care of snprintf portability problems BTW - good catch Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Buffer overflow in auto_gui.cxx
Andy Ross writes:
>
>I got bitten by some static data corruption problems while working on
>the panel stuff this afternoon (which I have almost working, by the
>way -- expect a big code drop tomorrow morning). I tracked it down to
>a buffer overflow in auto_gui.cxx. In the string formatting code for
>the labels, there are some sprintf calls that look like this:
>
> sprintf(buffer, "%05.2f", value);
>
>Where the buffer is a static variable with a length of 8. It turned
>out that one of the values was a huge garbage value -- something like
>1e223.
>
>This code looked correct to me, with the field width being less than
>8. But it turns out that that C standard allows for the buffer to
>overflow anyway. What happens is that the exponential form of the
>number can't fit for whatever reason, so the glibc sprintf tries to
>print it in (gack!) decimal. You can verify this with the following
>tiny program:
>
> int main() { printf("%05.2f\n", 1.1235e223); }
>
>...which gives the following output on my machine:
>
>112349938334961411652071671375046294557913868158949
>710939984497662240591346122273061179485597644285927045638100633
>964451473617213497232495048750461561268721092853979309330110426
>16316938278030005998645453598490624.00
>
Note that getting a value outside of what is representable with %05.2f is
probably an indication of a bug elsewhere in the program as these represent
angular measurements only, where this construct is used in auto_gui.cxx
This could also be related to recent changes in the auto_pilot code to
run every thing through the 'properties' instead of accessing these values
directly where I believe they were always clamped to a +- 360 degree range
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Multiplayer Engine project started
In my previous mail ("Multplayer efforts ?") We asked
for the status on multiplayer-capabilities. We
received responses that suggested that such an engine
was not maintained for a while.
We ourselves could use the engine for adding NPC to
the project, but thats still a far goal.
My friend and I got permission from our school to
build such an engine as a school project. We got 100
dedicated work days to make this happen, so wish us
luck !
Our part of the engine will be handling the
network-traffic and status of the connection. Easy to
use hooks to draw the plaines in the game should be
developed by the core team, if they don't exist yet.
If there are such hooks, plz mail them, so that we can
tweak data-packets to them.
Today we started brainstorming about what data would
be interresting for multiplayer. As soon as this is
finished I'll post the result for request for comment.
The first prototype to be capable of hooking into the
game should be ready within 2 months. This will be a
kind of software "switch", wherein the clients to the
heavy work of collision detection and such.
Test-releases to test network performance and
incompatibilities should be out by next month.
Comments are highly appriciated,
Lion O
Jeroen
__
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] ANN: C172P Hi-Res Panel Photos
Ryan Larson writes: > I have put some pictures up at the following address. > > http://64.81.150.106/planes/ I've looked at some of the 182 pics and they're excellent -- thanks. Some of the older instruments, like the Turn and Bank (rather than Turn Coordinator) are especially nice to have. Any chance of giving the pics descriptive names so that people can find things faster? 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] Buffer overflow in auto_gui.cxx
Andy Ross <[EMAIL PROTECTED]> said: > Needless to say, the static data area wasn't happy with 200+ bytes of > overflow. :) > Hmmm...I wonder if this relates to some of the effects I've seen recently with the delta time and fdms. If you could put up a separate patch for this (before the "massive checkin" :-)), I'd like to run some tests to confirm. BTW, thanks for tracking this down. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Engine project started
ace project wrote:
> In my previous mail ("Multplayer efforts ?") We asked
> for the status on multiplayer-capabilities. We
> received responses that suggested that such an engine
> was not maintained for a while.
True.
>
> We ourselves could use the engine for adding NPC to
> the project, but thats still a far goal.
>
> My friend and I got permission from our school to
> build such an engine as a school project. We got 100
> dedicated work days to make this happen, so wish us
> luck !
Good luck, Guys .. :-)
> Our part of the engine will be handling the
> network-traffic and status of the connection. Easy to
> use hooks to draw the plaines in the game should be
> developed by the core team, if they don't exist yet.
> If there are such hooks, plz mail them, so that we can
> tweak data-packets to them.
I must say I don't have experience in this part of the code, but to my
knowledge the OLK code was able to do it, so there must be some code to
do it (I guess the OLK code could give you some clues).
>
> Today we started brainstorming about what data would
> be interresting for multiplayer. As soon as this is
> finished I'll post the result for request for comment.
One thing to think about also is the way you want to implement this.
There are several ways (FlightGear connecting to all other players, or
connecting FlightGear to a daemon (which could run on another computer).
The basic idea I like best is to have a 'network' server which serves
all clients of a local network (LAN). This server the could handle
connections to other LAN servers then.
If I'm not mistaken PLIB already supports some kind of a LAN host.
>
> The first prototype to be capable of hooking into the
> game should be ready within 2 months. This will be a
> kind of software "switch", wherein the clients to the
> heavy work of collision detection and such.
That's another part of the discision, will you be using a guaranreed
protocol (TCP) or is a fire-and-forget protocol (like UDP) good enough.
You should take into account that the latter requires less from the
client, but it _is* possible you would lose data once in a while.
So it takes some care to decide the right type of connection (for
whatever data you want to sent).
>
> Test-releases to test network performance and
> incompatibilities should be out by next month.
>
> Comments are highly appriciated,
It would definately be nice to have such an option for FlightGear.
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Glut font format
Norman Vine wrote: > Check Marks's document about Textured Fonts for further information. > Of particular interest is Mark's "gentexfont" program that can create > a TXF format font from an X-windows font. This is how far I got. Unfortunately, Mark's documentation is all about how to use the font library. He doesn't say squat about what the file format it. I even started looking at the code, but there's no format documentation to be found there either. Reverse engineering the format based on the parser source code isn't my idea of a fun hack. I'd submit that this lack of documentation has a lot to do with why all of the existing glut fonts look so terrible. The only software that generates them works with X11 bitmap fonts. 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
Re: [Flightgear-devel] Buffer overflow in auto_gui.cxx
Jim Wilson wrote: > Hmmm...I wonder if this relates to some of the effects I've seen > recently with the delta time and fdms. If you could put up a > separate patch for this (before the "massive checkin" :-)), I'd like > to run some tests to confirm. BTW, thanks for tracking this down. This is what I did last night. It works for the bug I was seeing, but I didn't go through the code looking for other printf's that might blow up with the same values. The hard-coded "8" should be unified with the static definition of SliderText, of course. As Norman and I pointed out, though, a better solution would probably be to sanify the values before use if possible. Sometimes, if they come from arbitrary user input, you can't and have to resort to buffer size checking with snprintf and the like. But since these are angles, it should be possible. Andy RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Autopilot/auto_gui.cxx,v retrieving revision 1.29 diff -u -r1.29 auto_gui.cxx --- auto_gui.cxx26 Mar 2002 01:38:11 - 1.29 +++ auto_gui.cxx24 Jun 2002 17:04:59 - @@ -510,7 +510,7 @@ APAdjustHS0-> setCBMode ( PUSLIDER_DELTA ) ; APAdjustHS0-> setCallback ( maxroll_adj ) ; - sprintf( SliderText[ 0 ], "%05.2f", globals->get_autopilot()->get_MaxRoll() ); + snprintf( SliderText[ 0 ], 8, "%05.2f", globals->get_autopilot()->get_MaxRoll() ); APAdjustMaxRollTitle = new puText ( slider_title_x, slider_y ) ; APAdjustMaxRollTitle-> setDefaultValue ( "MaxRoll" ) ; APAdjustMaxRollTitle-> getDefaultValue ( &s ) ; @@ -527,7 +527,7 @@ APAdjustHS1-> setCBMode ( PUSLIDER_DELTA ) ; APAdjustHS1-> setCallback ( rollout_adj ) ; - sprintf( SliderText[ 1 ], "%05.2f", globals->get_autopilot()->get_RollOut() ); + snprintf( SliderText[ 1 ], 8, "%05.2f", globals->get_autopilot()->get_RollOut() ); APAdjustRollOutTitle = new puText ( slider_title_x, slider_y ) ; APAdjustRollOutTitle-> setDefaultValue ( "AdjustRollOut" ) ; APAdjustRollOutTitle-> getDefaultValue ( &s ) ; @@ -544,7 +544,7 @@ APAdjustHS2-> setCBMode ( PUSLIDER_DELTA ) ; APAdjustHS2-> setCallback ( rolloutsmooth_adj ) ; - sprintf( SliderText[ 2 ], "%5.2f", + snprintf( SliderText[ 2 ], 8, "%5.2f", globals->get_autopilot()->get_RollOutSmooth() ); APAdjustRollOutSmoothTitle = new puText ( slider_title_x, slider_y ) ; APAdjustRollOutSmoothTitle-> setDefaultValue ( "RollOutSmooth" ) ; @@ -562,7 +562,7 @@ APAdjustHS3-> setCBMode ( PUSLIDER_DELTA ) ; APAdjustHS3-> setCallback ( maxaileron_adj ) ; - sprintf( SliderText[ 3 ], "%05.2f", + snprintf( SliderText[ 3 ], 8, "%05.2f", globals->get_autopilot()->get_MaxAileron() ); APAdjustMaxAileronTitle = new puText ( slider_title_x, slider_y ) ; APAdjustMaxAileronTitle-> setDefaultValue ( "MaxAileron" ) ; -- 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
Re: [Flightgear-devel] Multiplayer Engine project started
--- Erik Hofman <[EMAIL PROTECTED]> wrote: > I must say I don't have experience in this part of > the code, but to my > knowledge the OLK code was able to do it, so there > must be some code to > do it (I guess the OLK code could give you some > clues). > > One thing to think about also is the way you want to > implement this. > There are several ways (FlightGear connecting to all > other players, or > connecting FlightGear to a daemon (which could run > on another computer). > > The basic idea I like best is to have a 'network' > server which serves > all clients of a local network (LAN). This server > the could handle > connections to other LAN servers then. > > If I'm not mistaken PLIB already supports some kind > of a LAN host. > That's another part of the discision, will you be > using a guaranreed > protocol (TCP) or is a fire-and-forget protocol > (like UDP) good enough. > You should take into account that the latter > requires less from the > client, but it _is* possible you would lose data > once in a while. > > So it takes some care to decide the right type of > connection (for > whatever data you want to sent). > > Erik Some decisions were already made. UDP is the way to go. Just look at all other multiplayer games out there and say that they use TCP. (NOPE) They use UDP or IPX (where IPX is the non-stream version of a Novell network protocol called SPX (well not exactly... but you might get the idea)) With TCP, if a packet gets lost, then it will retransmit after a given timeout, for example 3 secs. The data would be obsolete by then. With UDP, if it was a important message, we would confirm it. When it was position data, we would just wait for the next one (which would arive within 0.5 secs) Because we have to(?) support 56k modem users I think of using 512byte UDP-packets, that way modem users can sent about 5 updates p/sec and receive 7 p/sec. With a flight sim packets per second doesn't really matter, we are well capable of predicting where a plane is for about 3 seconds. I never seen a plane strafing or flying backwards all of a sudden :) Client-server model is chosen. Simply because you can run the server deamon at the same machine as the client and we don't have to recompile the entire game too much. Another advantage is the fact that we can introduce new IA-players by creating a 'fake' client. Also we don't know the connection speed of every PC and 56k users should be forced to runn a server. The first important decision now is, do we multi-threading or multiplexing-IO ? For multiplexing, PLIB can be used. For multi-threading, we got a problem. Another issue is how to get the code to compile on other platforms, because threading and sockets aren't 100% portable, to say the least. Far Future: The most interesting feature would be a distributed server architecture (world wide coverage with multiple servers), but we won't start on that until the simple server is 110% stable and all interface are completed. So this will not be implemented in this round. Leon __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Buffer overflow in auto_gui.cxx
Andy Ross <[EMAIL PROTECTED]> said: > This is what I did last night. It works for the bug I was seeing, but > I didn't go through the code looking for other printf's that might > blow up with the same values. The hard-coded "8" should be unified > with the static definition of SliderText, of course. > > As Norman and I pointed out, though, a better solution would probably > be to sanify the values before use if possible. Sometimes, if they > come from arbitrary user input, you can't and have to resort to buffer > size checking with snprintf and the like. But since these are angles, > it should be possible. > That's basically what I did to get YASim models to load reliably on my system. I changed the FGInterface::_calc_timespan() (? guessing name from memory) so that it is sanifying delta_time to non-negative and under 10 seconds. But there's a bug somewhere that is causing these wild values to show up occasionally in the first place. I'm convinced that a couple of the reports we've had lately of trouble that miraculously goes away when some applies a seemingly unrelated CVS update are due to data corruption. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Mag compass
The mag compass seems to have lost its turning and acceleration errors, or else they've been reduced by a magnitude or two. Has anyone touched the steam code recently? Perhaps one of the values it needs has changed units. 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] Capturing warnings
Making all in Main
c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
-I/usr/local/include -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O1 -finline-limit-6
-finline-functions -Wall -pedantic -Wpointer-arith -c main.cxx
main.cxx: In function `void fgUpdateTimeDepCalcs()':
main.cxx:766: warning: unused variable `int i'
main.cxx: In function `void fgLoadDCS()':
main.cxx:1742: warning: unused variable `class ssgVertexArray * lights'
main.cxx:1746: warning: `int light_type' might be used uninitialized in this function
... and there are many others in other files.
I have realised that in order for warnings to be useful, it is no good for them just
to scroll past and then be lost until after the next "make clean". At work, I capture
the compiler output for each file and then display all the warnings and errors at the
end of the build. Not just those from the files that were compiled during the last
run of "make", but for all source files. I don't want to force everyone to see the
warnings if they don't want to, but I think we should provide a set-up that makes it
easy to do so.
Three things are needed:
1. Enable warnings. e.g.
GCCFLAGS="-g -O1 -Wall -pedantic -Wpointer-arith"
CFLAGS="$GCCFLAGS" CXXFLAGS="$GCCFLAGS" ./configure
2. Save the error output for each C file as (e.g.) ".deps/*.err". E.g. in each
Makefile.in:
%.o: %.cxx
@echo '$(CXXCOMPILE) -c $<'; \
- $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $< 2> .deps/$(*F).err
+ $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $< 2> .deps/$(*F).err
@-cp .deps/$(*F).pp .deps/$(*F).P; \
tr ' ' '\012' < .deps/$(*F).pp \
| sed -e 's/^\\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \
>> .deps/$(*F).P; \
- rm .deps/$(*F).pp
+ rm .deps/$(*F).pp; \
+ cat .deps/$(*F).err
3. Display the results (when?). e.g.
find . -type d -name .deps -exec cat {}/*.err \;
So, can anyone suggest good ways of doing each of these steps, especially step 2: how
do I get that change into every Makefile.in, or what would be a better way?
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New panel code
OK, as promised, I have the "fixed" 3D panel support ready for testing (http://plausible.org/andy/vpanel-20020624.tar.gz). Changes include: + The panel(s) are now an first-class SSG node inside the aircraft scene graph. There's a little code added to model.cxx to handle the parsing, but most of the changes are inside the new FGPanelNode class (Model/panelnode.[ch]xx). + The old FGPanel source changed a lot, but mostly cosmetically. The virtual-cockpit code moved out into FGPanelNode, and the core rendering has been abstracted into a draw() method that doesn't try to set any OpenGL state. I also replaced the old inter-layer offset code with glPolygonOffset, as calculating the right Z values is hard across the funky modelview matrix I need to use. The older virtual panel code got away with it by disabling depth test, thus the "panel draws on top of yoke" bug. PolygonOffset is really the appropriate solution for this sort of task anyway. + The /sim/virtual-cockpit property is no more. The 2D panels are still specified in the -set.xml file, but 3D panels are part of the model file. + You can have as many 3D panels as you like. So grab the source and unpack it into your FlightGear source directory. The first thing you will notice is that the old virtual cockpits aren't virtual anymore. You will need to put them into the aircraft model file. This is the syntax I added to the a4-blue.xml model files to get a panel that matches Jim's current work (I haven't done any of the other planes yet): Aircraft/a4/a4-panel.xml -3.21 -0.24 0.44 -3.21 0.24 0.44 -3.21 -0.24 0.69 That is, you tell the model to include a given 2D panel file, and map it to the quadrilateral defined by the three points. The "nominal" size of the panel is still specified in the panel XML file, as the and properties; these values are used for the mapping. Note that the coordinates are "plib" or "JSBSim" coordinates, and *not* the numbers you find in the .ac file. The plib AC3D loader swaps the Y and -Z axes at load time. We should probably pick one convention (the view offsets use yet another, as does YASim) and make everything conform. Problems: + The mouse support isn't ready yet, so the 3D panels still aren't interactive. Soon to come. + Being part of the same scene graph as the model, the 3D panels now "jitter" in exactly the same way. While this makes the jitter of the attitude gyro less noticeable, it's still *very* noticeable and annoying. I looked hard for this, and am at this point convinced that the problem is with the two orientation computations. We have one in FGLocation that is used by the model code, and one in FGViewer that is used at the top of the scene graph. My suspicion is that they don't agree exactly, so the final orientation matrix is the right answer plus the difference. I did rule out the FDMs though. None of them show more than about 0.0001 degree of orientation change between frames for a stopped aircraft. That's within an order of magnitude of what you'd expect for the orientation change due to the rotation of the earth (which we don't model -- I cite it only as evidence of how small this is); far, far less than one pixel on the screen. 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
Re: [Flightgear-devel] Capturing warnings
I cannot redirect stderr via 'command 2> file' on my Mac, so the easy
solution was out. I did find that the following command works:
(make > /dev/null) >& make.txt
The reason for this can be found at:
http://www.faqs.org/faqs/unix-faq/faq/part2/section-9.html
I don't know if this will work on bash or other shells, but it might be
worth a try.
Jonathan Polley
On Monday, June 24, 2002, at 06:27 PM, Julian Foad wrote:
> Making all in Main
> c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
> -I/usr/local/include -DPKGLIBDIR=\"/usr/local/lib/FlightGear\" -g -O1
> -finline-limit-6 -finline-functions -Wall -pedantic -Wpointer-arith -c
> main.cxx
> main.cxx: In function `void fgUpdateTimeDepCalcs()':
> main.cxx:766: warning: unused variable `int i'
> main.cxx: In function `void fgLoadDCS()':
> main.cxx:1742: warning: unused variable `class ssgVertexArray * lights'
> main.cxx:1746: warning: `int light_type' might be used uninitialized in
> this function
>
> ... and there are many others in other files.
>
> I have realised that in order for warnings to be useful, it is no good
> for them just to scroll past and then be lost until after the next "make
> clean". At work, I capture the compiler output for each file and then
> display all the warnings and errors at the end of the build. Not just
> those from the files that were compiled during the last run of "make",
> but for all source files. I don't want to force everyone to see the
> warnings if they don't want to, but I think we should provide a set-up
> that makes it easy to do so.
>
> Three things are needed:
>
> 1. Enable warnings. e.g.
>
> GCCFLAGS="-g -O1 -Wall -pedantic -Wpointer-arith"
> CFLAGS="$GCCFLAGS" CXXFLAGS="$GCCFLAGS" ./configure
>
> 2. Save the error output for each C file as (e.g.) ".deps/*.err". E.g.
> in each Makefile.in:
>
> %.o: %.cxx
> @echo '$(CXXCOMPILE) -c $<'; \
> - $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $< 2> .deps/$(*F).err
> + $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $< 2> .deps/$(*F).err
> @-cp .deps/$(*F).pp .deps/$(*F).P; \
> tr ' ' '\012' < .deps/$(*F).pp \
> | sed -e 's/^\\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/'
> \
>>> .deps/$(*F).P; \
> - rm .deps/$(*F).pp
> + rm .deps/$(*F).pp; \
> + cat .deps/$(*F).err
>
> 3. Display the results (when?). e.g.
>
> find . -type d -name .deps -exec cat {}/*.err \;
>
> So, can anyone suggest good ways of doing each of these steps, especially
> step 2: how do I get that change into every Makefile.in, or what would be
> a better way?
>
> - Julian
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Glut font format
Andy Ross writes:
>
>Norman Vine wrote:
>> Check Marks's document about Textured Fonts for further information.
>> Of particular interest is Mark's "gentexfont" program that can create
>> a TXF format font from an X-windows font.
>
>This is how far I got. Unfortunately, Mark's documentation is all
>about how to use the font library. He doesn't say squat about what
>the file format it. I even started looking at the code, but there's
>no format documentation to be found there either. Reverse engineering
>the format based on the parser source code isn't my idea of a fun
>hack.
>
>I'd submit that this lack of documentation has a lot to do with why
>all of the existing glut fonts look so terrible. The only software
>that generates them works with X11 bitmap fonts.
Andy
Have you tried using the Font generator
http://www.opengl.org/developers/code/mjktips/TexFont/gentexfont.c
I have used this successfully with Cygwin and is in how ALL of the
PLib fonts were created.
Here's Mark's example of the command used to generate the sorority.txf file:
Just change the Font name and the 'glist' to be what you want
gentexfont \
-fn '-sgi-sorority-medium-r-normal--40-*-*-*-p-*--ascii' \
-file sorority.txf \
-glist \
'`"abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMN\
OPQRSTUVWXYZ01234567890 \!@#$$%^&*()-=+/,.<>;:~{}[]' \
-bitmap \
-w 256 \
-h 256 \
-gap 3
Norman
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Capturing warnings
Jonathan Polley wrote: > I cannot redirect stderr via 'command 2> file' on my Mac, so the easy > solution was out. I did find that the following command works: Rubbish. Sure you can. You just have to run a real shell. :) Basically, this is a long-standing misfeature of csh, which never existed in the original bourne shell and which happily has never been emulated. There is no syntax for redirecting stderr any differently from stdout. Bill Joy apparently never needed it, and no one else (over 20 years!) ever bothered to add it. I have no idea -- none whatsoever -- why Unix vendors insist on shipping this dinosaur as the default shell when there are *so* many better options available as free software. I guess Apple decided not to buck the trend and try to fix the command line they were trying so hard to hide. :) Seriously, I'd be shocked beyond measure if bash didn't build and install just fine on OS X. Use it, it's vastly better than csh. 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
Re: [Flightgear-devel] Multiplayer Engine project started
On Mon, 24 Jun 2002 12:21:46 -0700 ace project <[EMAIL PROTECTED]> wrote: [snip] The first important decision now is, do we > multi-threading or multiplexing-IO ? For multiplexing, > PLIB can be used. For multi-threading, we got a > problem. > Another issue is how to get the code to compile on > other platforms, because threading and sockets aren't > 100% portable, to say the least. PLIB's socket library is reasonably portable. It runs on every platform that FlightGear runs on. There are many "portable" open source threading libraries available, Boost.Thread, ZThread and CommonC++ to mention just a few. Bernie ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Glut font format
Norman Vine wrote:
> Here's Mark's example of the command used to generate the sorority.txf
> file: Just change the Font name and the 'glist' to be what you want
>
> gentexfont \
> -fn '-sgi-sorority-medium-r-normal--40-*-*-*-p-*--ascii' \
Right, but this only gets you a copy of the X11 bitmap font, which is
ugly and aliased. My original point was that with only a little work,
you could use ghostscript/FreeType to render a very high (16x)
resolution bitmap of each character and downsample to get a very
nicely antialiased texture to use with the font. Which would be
great, except for the fact that there are no tools available to do
this, nor documentation to write such tools.
Mark's program generates bitmapped textures from X11 bitmapped fonts.
So, because the X11 bitmap fonts are ugly as sin, the existing plib
fonts leave a lot to be desired*. But there's nothing in the software
engine that requires that -- it's just a tools issue.
All that being said, I did look through the source code a bit and
think I've puzzled out the format. Attached is a perl script that
parses a .txf font, prints the metrics information to stdout, and
generates a .pgm file containing the texture. (Actually, I got the
texture order wrong, so the image is flipped vertically).
I'll see if I can leverage this into some prettier fonts at some point
in the future.
Andy
* There are some other problems, too. Mark leaves almost no padding
between the characters in the bitmap, so mipmapping causes the
characters to "bleed" or "run together" when displayed at small
sizes. And some of the metrics are funny -- witness the alignment
of the characters in the button labels of the property picker, for
example.
--
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)
#!/usr/bin/perl -w
use strict;
my $file = shift or die;
open TXF, $file or die;
sub getbyte { my $val; read TXF, $val, 1 or die; return ord $val; }
sub getshort { my $val; read TXF, $val, 2 or die; return unpack "v", $val; }
sub getint { my $val; read TXF, $val, 4 or die; return unpack "V", $val; }
my $ENDIAN = 0x12345678;
my $magic = sprintf "0x%8.8x", getint();
my $endian = sprintf "0x%8.8x", getint();
my $format = getint();
my $texwid = getint();
my $texhgt = getint();
my $linehgt = getint();
my $unk = getint();
my $nglyph = getint();
printf "Magic $magic Endian $endian Format $format\n", $magic, $endian;
print "Texture: ${texwid}x$texhgt Line: $linehgt Glyphs: $nglyph Unk: $unk\n";
die "Bad magic number ($magic)" if $magic ne "0x667874ff";
die "Bad endianness tag ($endian)" if $endian ne "0x12345678";
for(my $i=0; $i<$nglyph; $i++) {
print "Glyph $i\n";
print " char: ", getshort(), "\n";
print " width: ", getbyte(), "\n";
print " height: ", getbyte(), "\n";
print " X: ", getbyte(), "\n";
print " Y: ", getbyte(), "\n";
print " step: ", getbyte(), "\n";
print "unk: ", getbyte(), "\n";
print " xoff: ", getshort(), "\n";
print " yoff: ", getshort(), "\n";
}
$file =~ s/\.txf$/.pgm/;
open PGM, ">$file" or die;
print PGM "P2\n$texwid $texhgt\n255\n";
if($format == 0) {
for(my $i=0; $i<($texwid*$texhgt); $i++) { print PGM getbyte(), " "; }
} else {
for(my $i=0; $i<($texwid*$texhgt/8); $i++) {
my $byte = getbyte();
for(my $j=0; $j<8; $j++) {
print PGM ($byte & (1<<$j)) ? "255 " : "0 ";
}
}
}
Re: [Flightgear-devel] New panel code
Andy Ross <[EMAIL PROTECTED]> said: > + Being part of the same scene graph as the model, the 3D panels now > "jitter" in exactly the same way. While this makes the jitter of > the attitude gyro less noticeable, it's still *very* noticeable and > annoying. I looked hard for this, and am at this point convinced > that the problem is with the two orientation computations. We have > one in FGLocation that is used by the model code, and one in > FGViewer that is used at the top of the scene graph. My suspicion > is that they don't agree exactly, so the final orientation matrix is > the right answer plus the difference. I did rule out the FDMs > though. None of them show more than about 0.0001 degree of > orientation change between frames for a stopped aircraft. That's > within an order of magnitude of what you'd expect for the > orientation change due to the rotation of the earth (which we don't > model -- I cite it only as evidence of how small this is); far, far > less than one pixel on the screen. Actually both the model code and the viewer use the FGLocation class, so the data should be the same. The major difference is in the application of the various view offsets which are applied to the FGLocation data in the Viewer and not the model. Note that in cockpit view, the viewer actually accesses the same exact instance of FGLocation that the model uses, so it has to be the same orientation data going in. If there is, as it appears, a variance between the two matrices as they get applied to the view and model, it would have to be attributable to a mathematical error that varies in its effect depending on the specific values involved. Remember the viewer code does apply offsets. Otherwise, it would have to be an issue related to the copying of data that also varies in its effect depending on the specific values. At some point this week I should have time to trace these values and see what is going on. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A-4C attitude indicator
Just finished adding quite a bit of detail to the a-4c attitude indicator. A few things to bring up: 1) The flags. There are four of them in the photos I've seen but so far I haven't found any information on which is which. One has the word "Off" on it, and I assume that it means the entire assembly is unpowered. 2) The calibration of the turn-rate indicator is just a wild guess. If anyone knows how it should respond please let me know. 3) The GS indicator is not enabled yet. Also note that there is an aircraft sillohette behind the cross hairs. I'm not sure how to animate it (maybe it stays with the gs arrow)? 4) The size of this thing is somewhat difficult to judge from the photos, but comparing it to other items on the panel, my guess is the ball is about 4" in diameter and the outer bezel is about 5 or 6". It looks bigger in the one A4-C cockpit photo that I have, but I believe that the A4-C panel is narrower than later models. AFAIK the A4-C is the first in the A4 series to have this "all attitude" instrument. 5) The X15 (see http://www.sierrafoot.org/x-15/panel_large.jpg ) used what appears to be the exact same instrument (with the exception of the glide slope scale in this diagram). So, I'm bringing up the issue of where to locate 3D instruments in our tree. Currently this one is in the Aircraft/A4/Models directory, and I'm not sure where we ultimately want these to end up. I'd prefer not to mix them up with the 2D models. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A-4C attitude indicator
This looks fantastic. I think this may be the first working gyro ball in a PC simulator cockpit. At least, I haven't seen one anywhere else. :) On question, unrelated to the ball actually, is exactly what we're trying to simulate. You seem to be aiming at an A-4C cockpit, but the aero model is for an A-4E which has a bigger engine. The 3D model claims to be a C, but it's dolled up in Blue Angels paint, and they flew the A-4F. To nit further: the slats are down, but the Blue Angels planes had their slats bolted shut*. And the refueling probe is the cranked shape that wasn't introduced until the A-4M. :) Maybe this is more detail than we should worry about. A foolish consistency being the hobgoblin of little minds and all that, but we should probably just pick something to aim for. My vote, so long as the blue paint is on the thing, is to model the A-4F. I'm cool with the C, though. The difference to the YASim file is basically engine thrust and performance numbers; pretty simple. * For safety. The A-4 had automatic slats that were retracted by aerodynamic force -- they dropped automatically at low airspeeds and high AoA's. On the ground, they just hung open. This was a great idea for maintenance purposes, but left open the possibility that they might get stuck and deploy asymmetrically. That's a recoverable situation normally, but not when there's another plane a few feet under or above your wing tip. :) > 1) The flags. There are four of them in the photos I've seen but so > far I haven't found any information on which is which. One has the > word "Off" on it, and I assume that it means the entire assembly is > unpowered. I'm clueless here. Obvious warning flags for the instrument would be the same as for a normal AI or HSI -- vacuum failure (or maybe electrical failure or low gyro RPM), lack of radio signal (VOR/TACAN/LOC/GS). > 2) The calibration of the turn-rate indicator is just a wild guess. > If anyone knows how it should respond please let me know. My book has some shots that show the turn indicator marked with "4 minute" markings to the left and right of the top of the display, perhaps 30-40 degrees apart. A four minute turn corresponds to 1.5 degrees per second. Dunno why they picked four minutes instead of two. > 3) The GS indicator is not enabled yet. Also note that there is an > aircraft sillohette behind the cross hairs. I'm not sure how to > animate it (maybe it stays with the gs arrow)? This one's easy -- leave it out. The A-4F was the first version to have an ILS receiver. This was around 1965 or so, which probably corresponded to the initial installation of ILS equipment at Navy installations and on carriers. For late model aircraft, the horizontal bar probably also doubled as a flight director indicator. > 4) The size of this thing is somewhat difficult to judge from the > photos, but comparing it to other items on the panel, my guess is the > ball is about 4" in diameter and the outer bezel is about 5 or 6". It > looks bigger in the one A4-C cockpit photo that I have, but I believe > that the A4-C panel is narrower than later models. I'm pretty sure it's the same size -- there were no significant changes (other than to the radome in the nose) to the forward fuselage during the Skyhawk's lifespan. I know they used the same ejection seat until the marines replaced it in their A-4Ms. > AFAIK the A4-C is the first in the A4 series to have this "all > attitude" instrument. I think that's right. I have a cockpit photo of one of the original A4D's delivered in 1956, and it shows a WWII-looking flat card gyro. > 5) The X15 (see http://www.sierrafoot.org/x-15/panel_large.jpg ) > used what appears to be the exact same instrument (with the > exception of the glide slope scale in this diagram). I've seen a photo of an AV-8A cockpit with the ball, too. I agree, we need to decide on placement for these things. Anywhere is fine with me. 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] FGInterface initialisation bug
Hello,
wondering why my A4 stay steady on the ground with gear retracted, I
made a little debug session to find that 'remaining' value in
FGInterface::_calc_multiloop had a very huge value (about 1e+66)
that result in 0 iterations made by the FDM.
Applying the patch below solve the problem.
Cheers,
-Fred
C:\FlightGear\cvs\FlightGear\src\FDM>cvs -nq diff -u flight.cxx
Index: flight.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/FDM/flight.cxx,v
retrieving revision 1.60
diff -u -r1.60 flight.cxx
--- flight.cxx 17 May 2002 15:25:28 - 1.60
+++ flight.cxx 25 Jun 2002 06:28:49 -
@@ -53,6 +53,7 @@
// Constructor
FGInterface::FGInterface() {
_setup();
+remainder = 0;
}
FGInterface::FGInterface( double dt ) {
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
