Re: [Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
On Freitag 02 Dezember 2005 12:48, Melchior FRANZ wrote:
* Mathias Fröhlich -- Friday 02 December 2005 07:35:
float
XDR_decode_float ( const xdr_data_t f_Val )
{
union {
float f;
xdr_data_t x;
} tmp;
tmp.x = XDR_decode_int32 (f_Val);
return tmp.f;
}
This works.
Aliasing rules roughtly tell that pointers to different types not contained in
each other are assumed to point at different locations.
The original way gcc identifies that int store on the stack as a dead store as
it will never be read again - a float is read that cannot point to the same
address.
That it worked with making that variable static is propably that gcc did not
see that nowhere in the range of visibility of that static variable, this
variable ever read. If it would be smart enough to see that it would also
optimize that store away may be including the static variable itself.
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
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)
* Melchior FRANZ -- Friday 02 December 2005 18:44: I will present a patch after that which restores the original, pre-ObjectsTerrain behavior. Committed. If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/ subdir, then FGGlobals::set_fg_scenery() will expanded this to a list [A/Terrain, A/Objects, , B/Terrain, B/Objects, ]. The empty sting is inserted as a marker for FGTileEntry so that it can stop scanning this set of Terrain/Objects twins. If one doesn't let FGGlobals::set_fg_scenery expand A/ to A/Terrain and A/Objects, but lists these explicitly: FG_SCENERY=A/Terrain:A/Objects then those are *not* seen as twin dirs. A/Objects will then not be scanned if a terrain tile was found in A/Terrain. That's a feature. Only implicit twins make a group. Hope this wasn't too confusing. It's well tested and seems to work as expected. This does, of course, not generally prevent doubled objects. If a windsock is in both A/Terrain/123456.stg *and* in A/Objects/123456.stg, then both will still be shown. So, if you see doubled windocks in KHAF (like I do), that's not a bug but the consequence of fgdb merging. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Melchior FRANZ schrieb: If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/ does the seperator have to be a double colon :? Or, more precisely, is it a ; under Windos? A double colon would cause real trouble under Windos... (imagine FG_SCENERY=D:\Scenery) CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDkYL7lhWtxOxWNFcRAvayAJ4jczgJ/V1eXcO1bM0fpfOFbBhJegCgp02i dDKvV99NJ+hF8YMOio4NU9w= =wG9n -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)
* Christian Mayer -- Saturday 03 December 2005 12:35: Melchior FRANZ schrieb: If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/ does the seperator have to be a double colon :? Or, more precisely, is it a ; under Windos? A double colon would cause real trouble under Windos... (imagine FG_SCENERY=D:\Scenery) It uses the OS-specific separator, as it always did. Colon on Unix/Linux, and semicolon on Windows: Unix OSX: FG_SCENERY=$FG_ROOT/Scenery:$FG_ROOT/WorldScenery Windows: FG_SCENERY=A:\foo\Scenery;B:\bar\Scenery Same for --fg-scenery. I'm using this: FG_SCENERY=$FG_HOME/Scenery:$FG_ROOT/Scenery:$FG_ROOT/WorldScenery |-- 1 --|-- 2 ---|- 3 | (1) contains only a few objects such as hangars in LOXL, or a windsock on the gree hangar in KSFO and a helipad next to it. For this have a file $FG_HOME/Scenery/w130n30/w123n37/942050.stg with only these lines: OBJECT_STATIC helipad.xml -122.37931 37.626 1.45 60 OBJECT_SHARED Models/Airport/windsock.xml -122.37839 37.62622 28.00 0 OBJECT_TAXI_SIGN AAA -122.357357 37.613917 0 150 OBJECT_RUNWAY_SIGN Town -122.357367 37.613927 2 150 No Terrain/ and Objects/ subdirs in $FG_HOME/Scenery for now. $FG_HOME is set to $HOME/.fgfs/ (2) is the default scenery from CVS (3) is scenery for the whole world. This is also my TerraSync target directory. (Most of the scenery here is quite old, though.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)
Melchior FRANZ wrote: * Melchior FRANZ -- Friday 02 December 2005 18:44: I will present a patch after that which restores the original, pre-ObjectsTerrain behavior. Committed. If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/ subdir, then FGGlobals::set_fg_scenery() will expanded this to a list [A/Terrain, A/Objects, , B/Terrain, B/Objects, ]. The empty sting is inserted as a marker for FGTileEntry so that it can stop scanning this set of Terrain/Objects twins. If one doesn't let FGGlobals::set_fg_scenery expand A/ to A/Terrain and A/Objects, but lists these explicitly: FG_SCENERY=A/Terrain:A/Objects then those are *not* seen as twin dirs. A/Objects will then not be scanned if a terrain tile was found in A/Terrain. That's a feature. Only implicit twins make a group. Hope this wasn't too confusing. It's well tested and seems to work as expected. This does, of course, not generally prevent doubled objects. If a windsock is in both A/Terrain/123456.stg *and* in A/Objects/123456.stg, then both will still be shown. So, if you see doubled windocks in KHAF (like I do), that's not a bug but the consequence of fgdb merging. :-) m. Now the question are : - where must I put the objects I download from fgdb on my disk - where can I put some other objects I want to add - and finaly the only important question : what do my FG_scenary env var must look like ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] yasim vs jsbsim c310
I've just tried out the c310 @KSFO, current metar conditions. The Yasim one develops 38PSI of manifold pressure, ~2700RPM at props and throttle full forward on the ground, brakes applied. The JSBsim gives a (more realistic-?) 29PSI. No surprise the ground roll at the Yasim one's is much shorter. 25 squared in Yasim means the throttle around halfway in at 500agl. I've never been in a c310 myself, passenger or pilot, but one of these aircraft simulations seems wrong. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] yasim vs jsbsim c310
I've just tried out the c310 @KSFO, current metar conditions. The Yasim one develops 38PSI of manifold pressure, ~2700RPM at props and throttle full forward on the ground, brakes applied. The JSBsim gives a (more realistic-?) 29PSI. No surprise the ground roll at the Yasim one's is much shorter. 25 squared in Yasim means the throttle around halfway in at 500agl. I've never been in a c310 myself, passenger or pilot, but one of these aircraft simulations seems wrong. It may be a case of input data being different. There may be several slightly different engines that could be used. I've got bigger fish to fry at the moment, but if you come upon some good specification data, post it here. Some tweaking might be in order. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)
* Harald JOHNSEN -- Saturday 03 December 2005 13:12: Now the question are : I guess this is mostly answered in my reply to Christian. People seem to be unaware of the FG_SCENERY path list. This is not a new feature. It exists since at least two years (or something). Only the behavior changed a bit over time. - where must I put the objects I download from fgdb on my disk fgdb contains only objects, no terrain. So it can be in the default Scenery/ dir (Terrain and/or Objects subdir, although the latter makes more sense :-), but it can also be in any other dir from the FG_SCENERY as long as it comes before the first terrain is found. (e.g. an OBJECT_BASE 123456.btg entry in the 123456.stg file.) - where can I put some other objects I want to add Same as above. Can be a different dir, though. You can use as many path elements in FG_SCENERY/--fg-scenery as you like. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
On Saturday 03 December 2005 01:26 am, Vassilii Khachaturov wrote: 2) when I hit the F3 to generate the above snapshot, I got an unusual attitude, from which it was very difficult to recover Are you flying using the mouse? Affirmative. When you hit F3 the cursor is slewed to the bottom left corner of the screen. If you are using the mouse for control at the time then you get full up elevator and full left aileron. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Yasim wing incidence
If this is just flipping the sign why not just grep and fix all the aircraft in CVS that specify incidence? I guess I don't understand the ritual. Maybe there was more to this change that I'm just not aware of? Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim wing incidence
Jim Wilson wrote: If this is just flipping the sign why not just grep and fix all the aircraft in CVS that specify incidence? I guess I don't understand the ritual. Maybe there was more to this change that I'm just not aware of? Most modelers (if not all) were unaware of this problem. Some of them changed the sign aft the problem was found. So it's best done in a case by case check. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim wing incidence
On Sat, 3 Dec 2005, Erik Hofman wrote: Jim Wilson wrote: If this is just flipping the sign why not just grep and fix all the aircraft in CVS that specify incidence? I guess I don't understand the ritual. Maybe there was more to this change that I'm just not aware of? Most modelers (if not all) were unaware of this problem. Some of them changed the sign aft the problem was found. So it's best done in a case by case check. And others seem to have tweaked other parameters to get a flyable aircraft at all, not knowing they had been delivered a plane with negative incidence and positive twist. Reverting the sign of incidence and twist is a QD fix which yields the same plane as before, but the models should rather be looked over more thoroughly imho. (which is a lot of work, no doubt) Some models may even fly better without modifications in the specs... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
2) when I hit the F3 to generate the above snapshot, I got an unusual attitude, from which it was very difficult to recover Are you flying using the mouse? Affirmative. When you hit F3 the cursor is slewed to the bottom left corner of the screen. If you are using the mouse for control at the time then you get full up elevator and full left aileron. LOL! Maybe I'll post a patch to switch off the mouse control mode temporarily during the snapshot on F3, if I find time for it... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim wing incidence
Jim Wilson wrote: If this is just flipping the sign why not just grep and fix all the aircraft in CVS that specify incidence? I guess I don't understand the ritual. Maybe there was more to this change that I'm just not aware of? The big issue is that developers were actually specifying negative wing incidence when they thought they were giving positive. So we could flip all the signs in all the config files so they flew the same as before, however, now all our airplanes would have negative wing incidence which clearly isn't right. So we really should go back and tweak all the models so they perform correctly with positive incidence. Regards, 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] Yasim wing incidence
Jim Wilwon wrote: If this is just flipping the sign why not just grep and fix all the aircraft in CVS that specify incidence? The files in CVS (most of them -- the ones that weren't pre-fixed for the 0.9.9 release) specify incidence as documented, not as it was actually implemented in code. So in principle none of them have to be modified. In practice, changing parameters in a FDM file can have unintended consequences. The old files were tuned for a broken implementation, and may need some re-tuning for the fixed one. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
* Melchior FRANZ -- Saturday 03 December 2005 16:45:
+union {
+float f;
+int i;
+} v;
Umm ... but is sizeof(float)==sizeof(int) on all supported
platforms? It's not on Atari ST, for example (IIRC). :-/
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
Melchior FRANZ wrote: Now the question is: should fgfs work around a broken gcc release, when there's hope that the next version will be fixed? Or is it not a bug, Strictly, it's not a bug. Within a single function, it is not legal to have two pointers of different types pointing to the same address. It never has been, AFAIK, but the gcc optimizer was never sophisticated enough to cause problems. It is now. :) Does adding --no-strict-aliasing to the CFLAGS fix the problem? Maybe we should consider that for the near term... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
Melchior FRANZ wrote: Umm ... but is sizeof(float)==sizeof(int) on all supported platforms? It's not on Atari ST, for example (IIRC). :-/ Really? I honestly thought all 68k platforms used a 32 bit int to match the register width. Certainly all 68k gcc variants do (gcc can't support a 16 bit int for internal reasons, apparently). But yeah -- on all useful platforms an int is a 32 bit 2's complement number and a float is a 32 bit value in IEEE format. The only types that have multiple sizes to worry about are pointers and long, each of which can be either 32 or 64 bits depending on platform. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] yasim(-test) vs fgfs
Joacim Persson wrote: I've discovered a difference between how fgfs calls the yasim solver, and how the yasim binary (aka yasim-test) does it. I have a -yasim.xml which doesn't pass yasim(-test) but which fgfs accepts... ?:-P So what is the difference? Number of iterations? That sounds like a bug. They are intended to produce identical behavior. Is it possible you have a yasim binary build from a different version of the code than your fgfs? Note specifically the recent incidence fix. Mathias Froelich wrote: I know of one difference: Ground intersection test Indeed. But the solver doesn't do any gear testing. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
On Samstag 03 Dezember 2005 16:45, Melchior FRANZ wrote: It turned indeed out to be yet another one of these ugly aliasing bugs with gcc 4.0.2 ([1] *AND* [2]!). In fastmath.hxx apparently reinterpret_cast doesn't work appropriately. Could explain why Alex' clean patch didn't work. Now the question is: should fgfs work around a broken gcc release, when there's hope that the next version will be fixed? Or is it not a bug, but something that will be in all gcc versions for the next time (I've not found any bug reports about it yet!). Anyway, attached is a patch that makes the turbines whine again, and some of us whine less. Sorry, but gcc is not broken. That is exactly like the standard tells it should behave. You are citing the standard yourselves often enough that I believe that you can read that. It is somehow hidden, but I believe that 3.10.15 contains exactly that. 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] Re: Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
On Samstag 03 Dezember 2005 17:17, Mathias Fröhlich wrote: You are citing the standard yourselves often enough that I believe that you can read that. Sorry, Melchior. I sometimes do not see that I might be insulting. That was not my intention! 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] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)
--- Harald JOHNSEN wrote: Now the question are : - where must I put the objects I download from fgdb on my disk - where can I put some other objects I want to add - and finaly the only important question : what do my FG_scenary env var must look like ? Have a look at the Getting Started Guide (PDF version is generally the most uptodate) - there's a description of the FG_SCENERY env var. If you have any problems understanding it, let me know and I'll try to correct the doc. Regards, -Stuart ___ Yahoo! Model Search 2005 - Find the next catwalk superstars - http://uk.news.yahoo.com/hot/model-search/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim wing incidence
From: Erik Hofman Jim Wilson wrote: If this is just flipping the sign why not just grep and fix all the aircraft in CVS that specify incidence? I guess I don't understand the ritual. Maybe there was more to this change that I'm just not aware of? Most modelers (if not all) were unaware of this problem. Some of them changed the sign aft the problem was found. So it's best done in a case by case check. Sure, but it still would have made sense to do a quick fix in the Aircraft data at the same moment that YASim was updated. Then before == after, no behavior change. It probably would have taken about half the time as writing an email listing the aircraft to be checked :-) Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim wing incidence
From: Andy Ross unintended consequences. The old files were tuned for a broken implementation, and may need some re-tuning for the fixed one. Ah ok. I thought it was just an inverted sign on the configuration input. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] yasim(-test) vs fgfs
On Sat, 3 Dec 2005, Andy Ross wrote: That sounds like a bug. They are intended to produce identical behavior. Is it possible you have a yasim binary build from a different version of the code than your fgfs? My first thought too. The file I used was the AN-225-yasim.xml with the only modification of negating the sign of wing incidence -- to get a view of what yasim had to say about the model as it was before the recent yasim bugfix. (Reverting the fix, so to speak: setting wing incidence to -4. No twist settings in that file) Much to my surprise, yasim spitted it out again with: Solution results: Iterations: 10002 Drag Coefficient: 0.00 Lift Ratio: 40757985280.00 Cruise AoA: 2.074975 Tail Incidence: -2.490169 Approach Elevator: 0.00 CG: -7.222, -0.000, 3.603 SOLUTION FAILURE: Solution failed to converge after 1 iterations Fgfs, however, happily accepts it. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Autopilot (and more)
On December 2, 2005 09:33 am, Josh Babcock wrote: Perhaps it would be easy to write a null autopilot. Put that in the base package, and anyone who wants no autopilot in their aircraft could select that. I know nothing of autopilots though. Josh How about disabling avionic functions by default unless the aircraft-set.xml specifically demands them? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Autopilot
On November 30, 2005 12:25 pm, Melchior FRANZ wrote: Could be added to the list of admitted features for 1.0, next to landing lights ... :-) m. Just so people don't pull their hair out trying to come up with a solution to the landing lights: http://mail.flightgear.org/pipermail/flightgear-devel/2005-June/037572.html Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
