Re: [Flightgear-devel] RFC: Eliminating jitter
Paul Kahler wrote: What's wrong with just using double precision? If it's because this math is done on the video card then fine. In ray tracing I switched to doubles over 5 years ago and measured only a tiny penalty which was more than made up for by the reduction of artifacts. Single precision is so 20th century. By definition, opengl *only* does floating point. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
Hi Jim, On Freitag 29 April 2005 02:16, Jim Wilson wrote: This sounds great. In a few days I should be able to get this and test it. In the meanwhile, please double check that you can do resets and multiple teleports. I think your changes will improve the situation, but those have historically been issues when working with the viewer code. Also check to make sure taxing accross tile boundries works (coast most of the way down the default runway at KSFO). Ok, I can rerset. I can taxi across tile boundaries. All with JSBSim (non groundcache) and YASim (groundcache) aircraft I can still take off and land on the carrier. With YASim aircraft. With teleporting I am not shure what you mean. Switching between views far away? I can take of from KSFO fly straight away for several minues (about 350 kts) and happily cycle through all views including the tower view. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
Hi, On Freitag 29 April 2005 01:33, Paul Kahler wrote: What's wrong with just using double precision? If it's because this math is done on the video card then fine. In ray tracing I switched to doubles over 5 years ago and measured only a tiny penalty which was more than made up for by the reduction of artifacts. Single precision is so 20th century. :) I think the most important thing now is that plibs scenegraph is only available in single precision. I assume that your raytracing program timings runs on an i*86 type cpu without using mmx/sse extensions and not using the gpu to do computations? If so, this timings are not meaningful. An i*86 just uses the same registers and the same precision for all computations. This precision is by default even more than 64 bit double (which makes the i386 in some sense a non ieee machine and could be the reason for really strange bugs). Shure you can switch the precision to a lower datatype, but this switch is much more costly than executing one flop. As a result most programs will just leave that at the default (96 bit extendend precision) for performance reasons. The time to execute one multiplication/addision/subtraction is exactly the same for each precision (throughput is at about 1 flop per cycle), so even if you swiched the precision down to single precision at the beginning of your program, the operations which are mostly used performe exactly the same. Only divisions, sqrt, sin/cos and such more complicated assembly instructions take less computation time iff you changed the fpu control word to single precision. This situation improoves a with the vector valued fpu extensioins like sse et al ... (like mesa uses inside and very most propably are used in the closed source drivers from nvidia/ati for non gpu operations too). You can execute operations on one smid register at a clock cycle. That means either 2 doubles or 4 floats at a time, that is twice the throughput with floats. Also different cpu's like virtually nearly all non x86 (at least I know sparc, alpha and ia64 for shure) have extra assembler instructions for single and double precision floatingpoint oprerations and they perform different. Apart from that I am not shure if any of those gpu's can really compute with floats or doubles like we know them from cpu's. I expect that they support some internal format with some precision. May be a fixed point format, may be an other one. Even if the OpenGL interface will take floats and doubles, there is no guarantee that it does not use singles for all computations internally (True? Or is there a paragaph in the OpenGL standard?). That means that you might have jitter, even if all your transforms stored in the client application are in double precision. And if there are different gpu floatingpoint/fixedpoint formats available, I do not know if they will perform better or worse with different precision, which is not that unlikely. Does anybody have better knowledge about the internals of gpus? Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] (no subject)
Mostyn Gale asked Just two quick questions. What effect do gauges have on the frame rates of virtual cockpits. i.e. is there as strong effect after 10 or 20 gauges? 3d gauges - yes the vertex count is significant, but not the number of gauges per se. Also is it possible to configure the views so that a virtual cockpit is only visible when actually in the cockpit? Yes - see the Hunter or Spitfire for an example of how it can be done. Regards Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Eliminating jitter
Mathias Fröhlich wrote: With teleporting I am not shure what you mean. By teleporting I think Jim means selecting different airports across the world (one after another), i.e. KSFO, CYYR, EHAM, etc. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RFC: Eliminating jitter
* Erik Hofman -- Friday 29 April 2005 09:38: By teleporting I think Jim means selecting different airports across the world (one after another), i.e. KSFO, CYYR, EHAM, etc. Yes, probably. Works without the least problems. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: Eliminating jitter
Melchior FRANZ wrote: * Erik Hofman -- Friday 29 April 2005 09:38: By teleporting I think Jim means selecting different airports across the world (one after another), i.e. KSFO, CYYR, EHAM, etc. Yes, probably. Works without the least problems. Ok, I tried it and liked it. Can we agree this should be committed? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: Eliminating jitter
Erik Hofman wrote : Melchior FRANZ wrote: * Erik Hofman -- Friday 29 April 2005 09:38: By teleporting I think Jim means selecting different airports across the world (one after another), i.e. KSFO, CYYR, EHAM, etc. Yes, probably. Works without the least problems. Ok, I tried it and liked it. Can we agree this should be committed? It compiles and works for me -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: Eliminating jitter
From: Erik Hofman Melchior FRANZ wrote: * Erik Hofman -- Friday 29 April 2005 09:38: By teleporting I think Jim means selecting different airports across the world (one after another), i.e. KSFO, CYYR, EHAM, etc. Yes, probably. Works without the least problems. Ok, I tried it and liked it. Can we agree this should be committed? As the last writer/rewriter of the viewer (and therefore partly responsible for the bug being there) I probably should look at it, but it will be a few days yet. This is too good to wait on and it sounds like it passes the acid tests, so yeah go for it! Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] MSVC 7.1 Runtime Error
I have downloaded the following source code files: FlightGear 9.8, SimGear 3.8, plib 1.8.4, and zlib 1.1.4. I was able to get this to compile in Visual Studio 2003 but when I try to run flight gear with the following command: fgfs fg-root=c:\\GS_PTT\\Flightgear\\data airport=KSFO aircraft=A-10cl disable-sound and I get the following runtime error almost immediately: Debug assertion failed! Program: fgfs.exe File: isctype.c Line: 68 _expression_: (unsigned)(c+1) = 256 Has anyone ever encountered this error? Is it possible to set breakpoints in Flightgear and debug it that way? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC 7.1 Runtime Error
Ben Morrison wrote:
I have downloaded the following source code files: FlightGear 9.8,
SimGear 3.8, plib 1.8.4, and zlib 1.1.4. I was able to get this to
compile in Visual Studio 2003 but when I try to run flight gear with
the following command: fgfs fg-root=c:\\GS_PTT\\Flightgear\\data
airport=KSFO aircraft=A-10cl disable-sound and I get the
following runtime error almost immediately:
Debug assertion failed!
Program: fgfs.exe
File: isctype.c
Line: 68
Expression: (unsigned)(c+1) = 256
Has anyone ever encountered this error? Is it possible to set
breakpoints in Flightgear and debug it that way?
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
You can debug, no problem.
The assert is a known problem, it happens with a debug build under VS,
you have to change a view lines in simgear, patch attached.
Harald.
Index: strutils.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/misc/strutils.cxx,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 strutils.cxx
--- strutils.cxx7 Sep 2002 02:58:19 - 1.1.1.1
+++ strutils.cxx26 Apr 2005 17:01:34 -
@@ -41,14 +41,14 @@
while (i len)
{
- while (i len isspace(str[i]))
+ while (i len isspace((unsigned char)str[i]))
{
++i;
}
j = i;
- while (i len !isspace(str[i]))
+ while (i len !isspace((unsigned char)str[i]))
{
++i;
}
@@ -57,7 +57,7 @@
{
result.push_back( str.substr(j, i-j) );
++countsplit;
- while (i len isspace(str[i]))
+ while (i len isspace((unsigned char)str[i]))
{
++i;
}
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC 7.1 Runtime Error
Harald JOHNSEN wrote : Ben Morrison wrote: I have downloaded the following source code files: FlightGear 9.8, SimGear 3.8, plib 1.8.4, and zlib 1.1.4. I was able to get this to compile in Visual Studio 2003 but when I try to run flight gear with the following command: fgfs fg-root=c:\\GS_PTT\\Flightgear\\data airport=KSFO aircraft=A-10cl disable-sound and I get the following runtime error almost immediately: Debug assertion failed! Program: fgfs.exe File: isctype.c Line: 68 Expression: (unsigned)(c+1) = 256 Has anyone ever encountered this error? Is it possible to set breakpoints in Flightgear and debug it that way? You can debug, no problem. The assert is a known problem, it happens with a debug build under VS, you have to change a view lines in simgear, patch attached. BTW: you will get a 2x to 3x framerate improvement if you compile flightgear in release mode, and you will not be annoyed by this assertion failure. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] MSVC 7.1 Runtime Error
Thanks, guys. This is my first time posting to the board and I am impressed with the response times. I am compiling in debug mode because I am going to be modifying flightgear later. Ok, Harald's solution fixed the runtime error but now flightgear just sits there and doesn't start. What could be causing this? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: RFC: Eliminating jitter
Jim Wilson wrote: From: Erik Hofman As the last writer/rewriter of the viewer (and therefore partly responsible for the bug being there) I probably should look at it, but it will be a few days yet. This is too good to wait on and it sounds like it passes the acid tests, so yeah go for it! Done. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC 7.1 Runtime Error
Ben Morrison wrote: Thanks, guys. This is my first time posting to the board and I am impressed with the response times. I am compiling in debug mode because I am going to be modifying flightgear later. Ok, Harald's solution fixed the runtime error but now flightgear just sits there and doesn't start. What could be causing this? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d It's not very clear. Check that you added the '--fg-root=x:\flightgear\data' parameter to the debugger, not finding the airports/runway data can lead FG to an infinite loop for example. Or just press break and look where he is in the code ;) Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] nimitz ai model : solid material, versus yasim jsb
G-ROBIN [EMAIL PROTECTED] An Aircraft with FDM YASIM does work correctly when we try to land on Nimitz: the solid material is active. An Aircraft with FDM JSB does not work the solid material is not active. I test it with SeafireIIIC (yasim) and c172r (jsb), this one go through the deck like butter (OK the c172r is not a naval aircraft) This is only on AI model. With static model and the same Nimitz everything works correctly. Does anybody could explain that problem. thanks ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nimitz ai model : solid material, versus yasim jsb
ghours wrote: G-ROBIN [EMAIL PROTECTED] An Aircraft with FDM YASIM does work correctly when we try to land on Nimitz: the solid material is active. An Aircraft with FDM JSB does not work the solid material is not active. I test it with SeafireIIIC (yasim) and c172r (jsb), this one go through the deck like butter (OK the c172r is not a naval aircraft) This is only on AI model. With static model and the same Nimitz everything works correctly. Does anybody could explain that problem. The code to get JSBSim working with the Nimitz is not yet committed to CVS. This is because JSBSim has had a major overhaul recently and it was easier to develop that code against the new version of JSBSim directly. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: nimitz ai model : solid material, versus yasim jsb
* ghours -- Friday 29 April 2005 19:04: An Aircraft with FDM YASIM does work correctly when we try to land on Nimitz: the solid material is active. An Aircraft with FDM JSB does not work the solid material is not active. [...] Does anybody could explain that problem. That's simple: Mathias is still working on JSBSim's groundcache() support (which is necessary for landing on the carrier), while that for YASim is already in CVS (and the last release?). If you are very impatient: there are patches available to add the feature to JSBSim already now.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nimitz ai model : solid material, versus yasim jsb
Erik Hofman a écrit : ghours wrote: G-ROBIN [EMAIL PROTECTED] An Aircraft with FDM YASIM does work correctly when we try to land on Nimitz: the solid material is active. An Aircraft with FDM JSB does not work the solid material is not active. I test it with SeafireIIIC (yasim) and c172r (jsb), this one go through the deck like butter (OK the c172r is not a naval aircraft) This is only on AI model. With static model and the same Nimitz everything works correctly. Does anybody could explain that problem. The code to get JSBSim working with the Nimitz is not yet committed to CVS. This is because JSBSim has had a major overhaul recently and it was easier to develop that code against the new version of JSBSim directly. Erik OK thanks for the quick answer. I like better to use JSBSIM, because of the technical flexibility in modeling an Aircraft ,in spite of the existing limitations of integration in FGFS ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] MSVC 7.1 Runtime Error
It's not very clear. Check that you added the '--fg-root=x:\flightgear\data' parameter to the debugger, not finding the airports/runway data can lead FG to an infinite loop for example. Or just press break and look where he is in the code ;) Harald. Ok, it turns out it was initializing it just wasn't echoing the information to the command window so I thought it was stuck. Thanks for your help. Ben. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Disabling the top menu
Is it possible to hide the menu at the top of the screen? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Disabling the top menu
On Friday 29 April 2005 18:34, Ben Morrison wrote: Is it possible to hide the menu at the top of the screen? Yes, press F10. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Disabling the top menu
* Ben Morrison -- Friday 29 April 2005 20:34: Is it possible to hide the menu at the top of the screen? Sure. F10 toggles it. If you want it disabled everytime you start fgfs, you can put this into one of the xml configuration files: PropertyList ... sim menubar visibility type=boolfalse/visibility /menubar /sim ... /PropertyList or simply start fgfs with this option (or put it into ~/.fgfsrc): --prop:/sim/menubar/visibility=0 m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Disabling the top menu
Is it possible to do this from the command prompt? I don't want the user to have to press F10. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Oliver C. Sent: Friday, April 29, 2005 3:40 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Disabling the top menu On Friday 29 April 2005 18:34, Ben Morrison wrote: Is it possible to hide the menu at the top of the screen? Yes, press F10. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: Disabling the top menu
Thanks that is exactly what I needed. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Melchior FRANZ Sent: Friday, April 29, 2005 1:45 PM To: flightgear-devel@flightgear.org Subject: [Flightgear-devel] Re: Disabling the top menu * Ben Morrison -- Friday 29 April 2005 20:34: Is it possible to hide the menu at the top of the screen? Sure. F10 toggles it. If you want it disabled everytime you start fgfs, you can put this into one of the xml configuration files: PropertyList ... sim menubar visibility type=boolfalse/visibility /menubar /sim ... /PropertyList or simply start fgfs with this option (or put it into ~/.fgfsrc): --prop:/sim/menubar/visibility=0 m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: nimitz ai model : solid material, versus yasim jsb
Melchior FRANZ a écrit : * ghours -- Friday 29 April 2005 19:04: An Aircraft with FDM YASIM does work correctly when we try to land on Nimitz: the solid material is active. An Aircraft with FDM JSB does not work the solid material is not active. [...] Does anybody could explain that problem. That's simple: Mathias is still working on JSBSim's groundcache() support (which is necessary for landing on the carrier), while that for YASim is already in CVS (and the last release?). If you are very impatient: there are patches available to add the feature to JSBSim already now.) Yes the patches are welcome . from where is it possible to get these patches ? I did find anything in JSBSim CVs ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: nimitz ai model : solid material, versus yasim jsb
* ghours -- Friday 29 April 2005 22:36: [ground cache for JSBSim] Yes the patches are welcome . from where is it possible to get these patches ? ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ You only need the JSBSim diff (and the FA18, of course :-). I don't know it the diff does still apply, though. (It's Mathias' work, not mine.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: nimitz ai model : solid material, versus yasim jsb
Melchior FRANZ a écrit : * ghours -- Friday 29 April 2005 22:36: [ground cache for JSBSim] Yes the patches are welcome . from where is it possible to get these patches ? ftp://ftp.uni-duisburg.de/FlightGear/Misc_maf/carrier/ You only need the JSBSim diff (and the FA18, of course :-). I don't know it the diff does still apply, though. (It's Mathias' work, not mine.) m. Thanks the patche is OK . Compilation and FGFS running without problems. The Nimitz deck is now solid and not butter. Could not it be in the FGFS CVS ? G-ROBIN [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
