RE: [Flightgear-devel] HTTPD Refresh Option Suggestion
Hi, all. Please consider whether this would be a worthwhile addition. I'm using a little trick to get the HTTPD browser window to update periodically. In this case, the interval is hardcoded to 1 sec. A further _important_ step would be to have the content value be configurable. A large number, say 36000, would be a good default. This is from httpd.cxx. My change is between the comments. ... response += TITLEFlightGear - ; response += request; response += /TITLE; response += getTerminator(); // Inserted code response += META http-equiv=\refresh\ content=\1\; response += getTerminator(); // End Inserted code response += /HEAD; response += getTerminator(); ... Note that a short interval is very obnoxious, if one intends on using the browser to _change_ property values. The refresh is most useful for observation purposes. With a moderate (say 10 sec) interval, interesting things happen if one does input a change and leave that window open. :-) Best, Jim A ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] another http suggestion
snip I was thinking the other day that a huge win would be to put the update fields in the view of the parent node. Each leaf node displayed could not only show the current value, but also have its own form to update that value. It would really reduce mouse clicks, and you would never have to look at a page with only one value in it, which I consider a huge waste of screen real estate. I suppose I should try to implement that, when I get some time. Josh FWIW, I think that's a great idea. The ability to change all position values (lat/lon/alt), for example, at once with one click would be especially valuable. Thanks, Jim A ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] OpenAL for CygWin
From: Jon Berndt [mailto:[EMAIL PROTECTED] I have placed a compiled tarball of yesterdays OpenAL CVS files @ http://www.vso.cape.com/~nhv/files/cygwin/cyg_openAL.tgz you might want to test these against the current FGFS before blindly overwriting your currrent installation Is this distribution modified for use with CygWin as discussed in this thread recently? Namely, the _WIN32 - WIN32 issue, as well as the #define MVC? I grabbed Norman Vine's tarball and have finally put sound into a Cygwin build. I noticed that there are still two instances of _WIN32 in the headers: One is in alu.h, and one is in alut.h. For example, in alu.h ... #ifdef _WIN32 #define ALUAPI #define ALUAPIENTRY __cdecl ... I don't know if these are intentional or by oversight. My first success was after changing the _WIN32 to WIN32 in those places. However, I cannot conclude that change was necessary due to other oversights along the way on my part. For example, one must make sure the openal32.dll used by fgfs.exe is the one distributed in Norman's tarball! Other OpenAL versions cause a runtime error. I was stuck on that one for awhile. :-) Thanks, everyone. Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Attaching Views to Other Objects
-Original Message- From: Jim Wilson [mailto:[EMAIL PROTECTED] Hope this helps. Best regards, Jim Yes it does, Jim. Thanks. I'll see what I can make happen. Jim A. winmail.dat___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Last Driver NVIDIA 7667:==approach lightingrabbit DO NOT Conflict with Graphic Card
Gerard Robin wrote: I am Just Ending the test of the last NVIDIA driver 7667 june-22 The slowness in FG with VASI as vanished. That new driver seems right when working with existing OpenGL functionalities used by FG. I just notice a global speed a bit less than before (7664, without VASI). Good NEWS. That's great news, thanks for checking this out and reporting back. Tried latest NVidia driver for Quadro Fx 3400. Better, but still a problem with VASI/PAPI. Sitting at KFSO: 7184 8-10 fps with VASI 75 fps without VASI 7718 15-18 fps with VASI 75 fps without VASI The without VASI is with Gerard's fix that comments out one line. All cases run with enhanced lighting turned off. BTW, this is on WinXP. Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Attaching Views to Other Objects
Hi, I'm trying to track down how I can attach a view to another object in the sim, particularly for a multiplayer aircraft other than the ownship. I would like to switch to the viewpoint of each of the other guys in the virtual world. As documented at http://flightgear.org/Docs/fgfs-viewer-howto.html : Syntax for the eye position is: from-model type=booltrue or false/from-model from-model-idx type=intmodelnumber/from-model-idx Syntax for the target or at position used in views of type lookat is: at-model type=booltrue or false/at-model at-model-idx type=intmodelnumber/at-model-idx - But I can't find out where the modelnumber comes from, or what it really means. All the examples use zero, so I've assumed that was the ownship. I've looked through the code and docs, and searched many of the mailing-list archives, but haven't found any examples or explanations yet. A idea of how to use this for models in general, followed by understanding the implications and current capabilities for multiplayer otherships would be great. Any help would be appreciated, even references to archived discussions. Thanks! Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Main Airports Conflict withGraphic Card6600GT !!!
-Original Message- From: Gerard ROBIN [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 08, 2005 1:50 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Main Airports Conflict withGraphic Card6600GT !!! The hardware is able to do it, with the old driver 6229 it can. But the average performance is less, because that driver does not suit to these new GPU with GPL 2. May be a bug in the last NVIDIA driver. I could explain the problem if i was more accurate about GL and that light animation. -- Gerard For what it's worth, additional info on this thread: I saw the same bad performance on an Fx 3400 with new driver. I was not able to find any properties or run options to alleviate the problem (10 fps or less, when looking at an airfield -- running with enhanced lighting OFF). Gerard's fix (comment out the call to get_vasi_lights_root()) worked great. All is smooth now. Thanks, Gerard! Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RE: Re: Scenery size constraints
Melchior Franz wrote: I'm sure he meant boeing.com (hey, Stacie was first!). Now with Boeing and Sikorsky on board, where is EADS/Airbus? Come on! We know you are here! And Fokker!? And *cough* Diamond *cough* ... ;-) If this community keeps up the excellent work, I'm sure everyone will jump aboard sooner or later!! Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: RE: [Flightgear-devel] Scenery size constraints
Erik Hofman wrote: Harald JOHNSEN wrote: Alberico, James F wrote: Hi, I have been tracking down the cause of an FGFS access violation that occurs when attempting to use 1-arcsec scenery data for a tile generated in TerraGear to have 4 nodes. Granted, this may be extremely ambitious from a performance standpoint, and may prove to be completely infeasible. However, I am very interested in knowing the current limits and pushing hard on them. Hi Jim, It good to see some big names showing up on the list. This might give the project a boost to get to the next level. You certainly mean Harald, not me, unless you are commenting on the ugly format of my name here. :-) What I think I've learned so far from debugging: ... ... At this point Curtis is the one who is most involved in these things. He is attending the MathWorks International Aerospace and Defense Conference 2005 and will be back tomorrow. It might be best to send him a private copy of your mail also. That's a good idea. Thanks. Harald JOHNSEN wrote: I think that the only side effect will be that your new binary will be incompatible with current scenario files, perhaps that changing short to unsigned short could be enought. Erik Hofman wrote: Curtis already mentioned he wanted to change the layout of the tiles which probably breaks backward compatibility. So if it would be necessary this change could be adopted as well. Thanks, Harald and Erik. An unsigned short for that item would help me for my specific purpose. Curt and others can determine which direction to take the project. A key question will be whether 65k or even 32k nodes far exceeds any reasonable performance expectations for the foreseeable future. Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Scenery size constraints
Hi, I have been tracking down the cause of an FGFS access violation that occurs when attempting to use 1-arcsec scenery data for a tile generated in TerraGear to have 4 nodes. Granted, this may be extremely ambitious from a performance standpoint, and may prove to be completely infeasible. However, I am very interested in knowing the current limits and pushing hard on them. What I think I've learned so far from debugging: 1.) The FGFS FGBinObj reads with no errors. 2.) The access violation occurs during leaf generation. 3.) The breakage occurs shortly after the texture coordinate index exceeds the max value of a short (32767) and goes negative. 4.) The symbols (e.g., tris_tc) that carry the read-in indices are of type int 5.) Examination of the TerraGear bin writes, and the FGFS reads reveal the indices are stored as short types. 6.) So, my conclusion is the scenery of the 1-arcsec tile is limited to 32767 nodes. (or maybe polygons?) And, TerraGear will truncate any index above that when writing to the binary file. I'm a newbie to TerraGear/FGFS details, so please correct me if I'm wrong about any of this. I would appreciate any comments on what mess might result from any attempt to store/read ints, rather than shorts, to expand the scenery resolution. From a performance standpoint, the capacity of the short type may far exceed anything practical at the present time. Comments on that aspect are welcome, too. Thanks!! Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
