[Flightgear-devel] Re: [Terragear-devel] Post GIS based Scenery
Jason Cox wrote: Is there a Howto on using PostGIS to create Scenery ? No, as there is no use for PostGIS in _creating_ scenery. I'm running a PostGIS database that stores our landcover data from VMAP0 and which soon will contain manual improvements as well, but PostgreSQL/PostGIS is for data storage only. There are some shapefiles that _derive_ frmo what I'm storing in my PostGIS database. Please look here: http://web44.netzwerteserver2.de/212.0.html There's also a short instruction on how to produce errors :-) http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040838.html Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Alex Romosan -- Friday 02 December 2005 08:16: Mathias Fröhlich writes: Please use this one. And I believe, without looking into the code, that there are likely more of them ... I'll try all solutions later today. But I don't understand why any of them should be necessary. The code may not be the most elegant, but it looks right to me. Do I really have to tell the optimizer not to translate it wrongly? please apply the attached patch which uses static_cast: Looks nice. If it works (and Oliver doesn't have other plans) I'll commit that. But even if it works, why does the current code *not* work? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Alex Romosan -- Friday 02 December 2005 08:16: please apply the attached patch which uses static_cast: Haven't yet tested, but it looks good. At least it calls _Z16XDR_decode_int32RKj. :-) (gdb) disass XDR_decode_float Dump of assembler code for function _Z16XDR_decode_floatRKj: 0x0831086e _Z16XDR_decode_floatRKj+0: push %ebp 0x0831086f _Z16XDR_decode_floatRKj+1: mov%esp,%ebp 0x08310871 _Z16XDR_decode_floatRKj+3: sub$0x4,%esp 0x08310874 _Z16XDR_decode_floatRKj+6: mov0x8(%ebp),%eax 0x08310877 _Z16XDR_decode_floatRKj+9: mov%eax,(%esp) 0x0831087a _Z16XDR_decode_floatRKj+12: call 0x831083a _Z16XDR_decode_int32RKj 0x0831087f _Z16XDR_decode_floatRKj+17: push %eax 0x08310880 _Z16XDR_decode_floatRKj+18: fildl (%esp) 0x08310883 _Z16XDR_decode_floatRKj+21: add$0x4,%esp 0x08310886 _Z16XDR_decode_floatRKj+24: leave 0x08310887 _Z16XDR_decode_floatRKj+25: ret Will test and apply later. Thanks! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Melchior FRANZ -- Friday 02 December 2005 09:57: * Alex Romosan -- Friday 02 December 2005 08:16: please apply the attached patch which uses static_cast: No, this patch doesn't work. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Modular / portable cockpit design
On 2 Dec 2005, at 00:32, John Wojnaroski wrote:Just a question of time and energy. The design issue is how to keep it portable so we can haul the gear around to shows like Scale4x coming up in Feb 06. Same problem with putting everything into a shell, fantastic for a fixed installation but kind of like the old story of the fellow who builds the 30 foot sailboat in his cellar I would talk to some exhibition set / theatre set people if you can (I am slightly involved in the tech side of an amateur theatre company) - generally such people have to produce stuff which is pretty cheap, pretty durable and which can be transported, assembled and taken apart pretty fast without lots of support equipment.As far as I can tell (I haven't worked on set myself), a lot of it comes down the finding sufficiently fancy pins / hinges / bolts / locks that you can have everything be modular (eg, the pedestal, main panel, glare shield), but still be rock solid when it's all set into place. Experience is a big factor in that...James -- That which does not kill me has poor aim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
Having seen the recent request to try out a list of yasim-based aircraft from the current CVS, I've tried out the TU154. Here are 3 things I've noticed: 1) by hand-flying, I was able to get supersonic, pretty low and the aircraft flew all right, with no fluttering or reaching limits of some controls http://www.tarunz.org/~vassilii/fg/Images/tu154-supersonic.jpg 2) when I hit the F3 to generate the above snapshot, I got an unusual attitude, from which it was very difficult to recover (had to get back into realistic flying speed range to do that) (Too much CPU eaten while dumping the screen = big inter-frame time = model jolt?) 3) Throughout the flight, the in-cockpit altimeter showed the altitude in feet not meters (despite the dial marking meters in Russian). BTW, the ASI (marked speed in Russian) correctly indicated km/h. Cross-checked by the alternative HUD, see http://www.tarunz.org/~vassilii/fg/Images/tu154-altimeter-ft-not-m.jpg 4) the autopilot (even in the realistic subsonic speed range) goes berserk, starting with divergent pitch oscillations, and running out of pitch trim. Its altitude hold is usable in very low (under 200 KIAS) speed range, esp. if controlled by the AoA hold or pitch. I remember smth like this had happened to 737 and was fixed later. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Modular / portable cockpit design
James Turner wrote: On 2 Dec 2005, at 00:32, John Wojnaroski wrote: Just a question of time and energy. The design issue is how to keep it portable so we can haul the gear around to shows like Scale4x coming up in Feb 06. Same problem with putting everything into a shell, fantastic for a fixed installation but kind of like the old story of the fellow who builds the 30 foot sailboat in his cellar I would talk to some exhibition set / theatre set people if you can (I am slightly involved in the tech side of an amateur theatre company) - generally such people have to produce stuff which is pretty cheap, pretty durable and which can be transported, assembled and taken apart pretty fast without lots of support equipment. As far as I can tell (I haven't worked on set myself), a lot of it comes down the finding sufficiently fancy pins / hinges / bolts / locks that you can have everything be modular (eg, the pedestal, main panel, glare shield), but still be rock solid when it's all set into place. Experience is a big factor in that... Google for Akers Barnes Cockpit. Made from MDF, just slots together. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
Melchior FRANZ wrote:
* Melchior FRANZ -- Friday 02 December 2005 01:43:
But ... we weren't really returning the address of an auto var.
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
float
XDR_decode_float ( const xdr_data_t f_Val )
{
float* tmp;
xdr_data_t dummy;
dummy = XDR_decode_int32 (f_Val);
tmp = (float*) dummy;
return (*tmp);
}
And it turned out that when compiled with gcc 4.0.2 the return
value wasn't safe. When called three times in a row with different
values, we would get three times the same result. None of those
correct. This placed MP aircraft somewhere around the middle
of our Earth. For those understanding x86 assembler, here is
the resulting code (why does it not call _Z16XDR_decode_int32RKj?
Optimized away?):
decode_int32 is a nop on a x86 anyway
non-static dummy (-O2) -- doesn't work
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x08310816 _Z16XDR_decode_floatRKj+0: push %ebp
0x08310817 _Z16XDR_decode_floatRKj+1: mov%esp,%ebp
0x08310819 _Z16XDR_decode_floatRKj+3: sub$0x10,%esp
0x0831081c _Z16XDR_decode_floatRKj+6: flds 0xfffc(%ebp)
0x0831081f _Z16XDR_decode_floatRKj+9: leave
0x08310820 _Z16XDR_decode_floatRKj+10: ret
End of assembler dump.
This code does what it is supposed do to ie : return *((float *) arg);
except that arg == 0xfffc(%esp)
non-static dummy (-O0) -- works
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x083be33a _Z16XDR_decode_floatRKj+0: push %ebp
0x083be33b _Z16XDR_decode_floatRKj+1: mov%esp,%ebp
0x083be33d _Z16XDR_decode_floatRKj+3: sub$0x18,%esp
0x083be340 _Z16XDR_decode_floatRKj+6: mov0x8(%ebp),%eax
0x083be343 _Z16XDR_decode_floatRKj+9: mov%eax,(%esp)
0x083be346 _Z16XDR_decode_floatRKj+12: call 0x83be1b4
_Z16XDR_decode_int32RKj
arg == 0x8(%esp)
static dummy-- works
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x08310816 _Z16XDR_decode_floatRKj+0: push %ebp
0x08310817 _Z16XDR_decode_floatRKj+1: mov%esp,%ebp
0x08310819 _Z16XDR_decode_floatRKj+3: sub$0x4,%esp
0x0831081c _Z16XDR_decode_floatRKj+6: mov0x8(%ebp),%eax
0x0831081f _Z16XDR_decode_floatRKj+9: mov%eax,(%esp)
0x08310822 _Z16XDR_decode_floatRKj+12: call 0x83107e2
_Z16XDR_decode_int32RKj
arg == 0x8(%esp)
The code generated with -O2 and without static is wrong. Functions
parameters are
allways at a positive offset from sp. Perhaps adding a volatile modifier
on the tmp pointer
could do the trick (of course doing that disables optimisations).
Harald.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3Dcockpit instruments
On Thu, 2005-12-01 at 17:29, Curtis L. Olson wrote: Norman Vine wrote: FlightGear is more then just a first person sim These other uses may have reasons to want dialog box displays. Again if you don't ike the dialog boxes don't use them but please do not advocate taking them away. Norman isn't saying blindly keep dumb or broken stuff. What he is saying is entirely compatible with a discussion about fixing bugs or making the gui work better or be more intuitive or less confusing. There is ample room for this sort of thing. Whoa! I get the message! The flameproof suit is burning through in places! I back off! Scrub the idea of getting rid of the dialog boxes, as you say they often are easier to use than the simulated real instrument. Indeed, I was using the autopilot dialog partly for that reason when I tripped over the bug that started me off on this rant. See elsewhere for the object orientated instrument suggestions that should avoid repeats of the Cessna autopilot mess. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Thu, 2005-12-01 at 22:47, Josh Babcock wrote: Steve Hosgood wrote: Also, have you considered looking into OpenGC? It won't give you the MSFS like functionality of dragable sub windows, but I think it would allow you to make arbitrary windows to display instruments in cutouts. I was deliberately thinking that you **don't** want to use OpenGL for that sort of thing. The GPU has enough work to do rendering the view out of the windows, it would be a waste of its time rendering instruments for the fascia - they're always going to be displayed straight on with flat lighting. It's just a simple animation job for a normal window. I see that a cockpit building discussion has kicked off in a parallel part of this thread... Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture bug
Ampere K. Hardraade wrote: On November 30, 2005 08:22 pm, Curtis L. Olson wrote: Perhaps explain to them what our code is attempting to do, and then ask if they know of a GLX supported way to do it. I would do that if I can. However, I am not a programmer, and nothing in RenderTexture.cpp makes any sense to me. :( What exactly is our code attempting to do? Ampere The code creates a pbuffer the standard way, there is nothing special in rendertexture, the only things special is the choice of the api, using glx pre or post 1.3 - and this code won't work well for long since mesa lies on version numbers. The only standard test of pbuffers that I know is fgl_glxgears. But perhaps there is a test case somewhere in the mesa/xorg cvs, after all how do they test their code ? Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Harald JOHNSEN -- Friday 02 December 2005 11:36:
Melchior FRANZ wrote:
(why does it not call _Z16XDR_decode_int32RKj? Optimized away?):
decode_int32 is a nop on a x86 anyway
Huh? Looks like a nop for big-endian:
int32_t
XDR_decode_int32 ( const xdr_data_t n_Val )
{
return (static_castint32_t (SWAP32(n_Val)));
}
and
#define SWAP32(arg) sgIsLittleEndian() ? sg_bswap_32(arg) : arg
Perhaps adding a volatile modifier on the tmp pointer
could do the trick (of course doing that disables optimisations).
That wouldn't matter.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Steve Hosgood schrieb: I was deliberately thinking that you **don't** want to use OpenGL for that sort of thing. The GPU has enough work to do rendering the view out of the windows, it would be a waste of its time rendering instruments for the fascia - they're always going to be displayed straight on with flat lighting. It's just a simple animation job for a normal window. That's why the future of the 2D desktops will be rendered by the 3D hardware (Windows Vista, the OpenGL based X-Server, ...). A while ago 2D desktops would profit from the graphic accelerator graphic cards. They had chips that could draw very fast lines, etc. pp. But today we've got 3D accelerators that can do even more. They are even programmable. So the new OSes use that functionality for a fast visual feedback. So it doesn't make sense to pass the rendering of some instruments back to the OS. It will just give it back to the graphics adapter - with the aditional overhead of going through the OS. The only alternative to reduce the load on the GPU is to draw it with the CPU by hand (note: this is really CPU intensive!). But if the CPU idles too long (what I really doubt) we could easily increase the FDM resolution, AI traffic, ... CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFDkC5JlhWtxOxWNFcRArQ2AJ0Y9W2z2ZlrQ3615T3LVUGOv3T10QCgq1Ac Lv9HbthiUs1IqdPu6uq5ZNo= =rjDA -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* 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.
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x08310816 _Z16XDR_decode_floatRKj+0: push %ebp
0x08310817 _Z16XDR_decode_floatRKj+1: mov%esp,%ebp
0x08310819 _Z16XDR_decode_floatRKj+3: sub$0x8,%esp
0x0831081c _Z16XDR_decode_floatRKj+6: mov0x8(%ebp),%eax
0x0831081f _Z16XDR_decode_floatRKj+9: mov%eax,(%esp)
0x08310822 _Z16XDR_decode_floatRKj+12: call 0x83107e2
_Z16XDR_decode_int32RKj
0x08310827 _Z16XDR_decode_floatRKj+17: mov%eax,0xfffc(%ebp)
0x0831082a _Z16XDR_decode_floatRKj+20: flds 0xfffc(%ebp)
0x0831082d _Z16XDR_decode_floatRKj+23: leave
0x0831082e _Z16XDR_decode_floatRKj+24: ret
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Harald JOHNSEN -- Friday 02 December 2005 11:36: Perhaps adding a volatile modifier on the tmp pointer could do the trick (of course doing that disables optimisations). It doesn't. Dump of assembler code for function _Z16XDR_decode_floatRKj: 0x08310816 _Z16XDR_decode_floatRKj+0: push %ebp 0x08310817 _Z16XDR_decode_floatRKj+1: mov%esp,%ebp 0x08310819 _Z16XDR_decode_floatRKj+3: sub$0x10,%esp 0x0831081c _Z16XDR_decode_floatRKj+6: flds 0xfffc(%ebp) 0x0831081f _Z16XDR_decode_floatRKj+9: leave 0x08310820 _Z16XDR_decode_floatRKj+10: ret m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Thu, 2005-12-01 at 20:23, Curtis L. Olson wrote: This is why all those oddball home/hobby cockpit builders aren't as far off their rockers as it might first appear. They are taking a huge step towards a more realistic simulation environment. Dead right. I'd never knock them - more like admire their enthusiasm. And as you say, an open source sim like FlightGear is much more likely to be able to interface to all these home-made instruments. And I'm sure all these people have spouses who understand the importance of a realistic flying experience. Yeah, right! :-) having the flight model right exactly on, is less important than having a full scale cockpit with controls that have the right amount of force feedback at the right times. An enclosure is a huge addition... Not sure about whether FlightGear currently allows for force feedback, but of course, if anyone's flight sim could do it, FlightGear could. Does FlightGear provide output data that would allow you to tip a cockpit on hydraulic rams (or any other system) to try and model changing G forces for the pilot? I've mentioned the possibility in other mails on this thread for a revamped future FlightGear instrument model to cater for separate windows (maybe on other display heads of course) which would help implement fascias using LCD panels behind cutouts. I'd have thought that the cockpit-builder types would be clamouring for such an addition, yet no-one's apparently all that enthusiastic. Do the current crop of cockpit builders happen to use real simulated physical instruments wired to USB or something? I read elsewhere that the 747 guys were simulating a glass cockpit, so maybe they didn't have any physical instrument scenarios to cope with. Hasn't anyone tried a cockpit-build for a WWII plane with FlightGear yet? Steve. BTW, nearly unrelated - one of the Discovery channels in the UK recently ran a documentary on recreating the Dambusters raid on the Ruhr in 1943. They had a (rather crude looking) mockup of a Lancaster bomber and a crew of modern RAF types who tried to simulate reproducing the raid. Whose flightsim was that? Unlikely to be FlightGear, unless the TV people commissioned their own Lancaster FDM. Did anyone apart from me see it? It looked like the instruments panel for the Lancaster was simulated with the old lcd panel behind holes cut in plywood trick. Actually, I'm not even sure they bothered with the plywood. They certainly didn't appear to bother with putting a skin on the fuselage of the fake plane - they just ran it in a darkened warehouse. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking
Steve Hosgood wrote: Not sure about whether FlightGear currently allows for force feedback, Sure it does - if it actually works only depends on the intelligence of your actuator subsystem. All data that might have impact on the respective force is available for being written to an output channel of your choice - although, as Curt admits, the data structure changes from version to version in certain cases Now it's up to you to decide which values to pick for creating appropriate force-feedback. Does FlightGear provide output data that would allow you to tip a cockpit on hydraulic rams (or any other system) to try and model changing G forces for the pilot? http://www.de.flightgear.org/Projects/RayChair/raychair.html Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ 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 Wed, 2005-11-30 at 20:25, Steve Knoblock wrote: If an aircraft has its own autopilot, the default dialog does not come up, but if it does not specify an autopilot, the default dialog comes up. Not quite. I've just discovered that the autopilot works(*) with the Colditz Glider! Let's see: a WWII escape glider built from floorboards and bedsheets and lacking *any* instruments apart from a yaw-string, does feature a fully-functioning autopilot! You've gotta take your hat off to those POW dudes On second thoughts, just possibly there's a bug here! We seriously need an item in the 'instruments' XML where a 'plane can request the default autopilot be available if: 1) The plane actually *has* an autopilot (**) and 2) The author doesn't want to bother with writing their own (yet). In the long term we could argue that the second case above isn't required - the dialog should only be available if the plane actually has an autopilot. In the case of the Cessna (and maybe others) where a real autopilot has been modelled, the dialog should be there, but set values in the real autopilot simulation. However, I'd suggest that the two-part test above be put in to sort out the most gratuitous ill effects in the current code *before* 1.0.0 comes out. Something similar should probably also be done for things like comms and nav radios (again, the Wright Flyer and Colditz Glider don't have them), in fact the *entire* Equipment menu item ought to be grayed-out for those two planes. All the gliders would want to disable the Fuel Settings dialog in that menu item. All historic craft would want to disable GPS settings. Sheesh: there's a good bit of work to be done around here. The systems failures dialog box should only have boxes for systems that the plane in question actually has! The altimeter settings dialog should be greyed out on any plane that doesn't have an altimeter (Wright Flyer, Colditz Glider and the Hang Glider I suppose). Steve (*) Velocity control using pitch oscillates badly. Heading control is fine. (**) I suspect the FlightGear 1903 Wright Flyer has autopilot too... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Steve Hosgood wrote: On Thu, 2005-12-01 at 22:47, Josh Babcock wrote: Steve Hosgood wrote: Also, have you considered looking into OpenGC? It won't give you the MSFS like functionality of dragable sub windows, but I think it would allow you to make arbitrary windows to display instruments in cutouts. I was deliberately thinking that you **don't** want to use OpenGL for that sort of thing. The GPU has enough work to do rendering the view out of the windows, it would be a waste of its time rendering instruments for the fascia - they're always going to be displayed straight on with flat lighting. It's just a simple animation job for a normal window. I see that a cockpit building discussion has kicked off in a parallel part of this thread... Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d No, OpenGC ^ http://www.opengc.org/ Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Autopilot (and more)
Steve Hosgood wrote: On Wed, 2005-11-30 at 20:25, Steve Knoblock wrote: If an aircraft has its own autopilot, the default dialog does not come up, but if it does not specify an autopilot, the default dialog comes up. Not quite. I've just discovered that the autopilot works(*) with the Colditz Glider! Let's see: a WWII escape glider built from floorboards and bedsheets and lacking *any* instruments apart from a yaw-string, does feature a fully-functioning autopilot! You've gotta take your hat off to those POW dudes On second thoughts, just possibly there's a bug here! We seriously need an item in the 'instruments' XML where a 'plane can request the default autopilot be available if: 1) The plane actually *has* an autopilot (**) and 2) The author doesn't want to bother with writing their own (yet). In the long term we could argue that the second case above isn't required - the dialog should only be available if the plane actually has an autopilot. In the case of the Cessna (and maybe others) where a real autopilot has been modelled, the dialog should be there, but set values in the real autopilot simulation. However, I'd suggest that the two-part test above be put in to sort out the most gratuitous ill effects in the current code *before* 1.0.0 comes out. Something similar should probably also be done for things like comms and nav radios (again, the Wright Flyer and Colditz Glider don't have them), in fact the *entire* Equipment menu item ought to be grayed-out for those two planes. All the gliders would want to disable the Fuel Settings dialog in that menu item. All historic craft would want to disable GPS settings. Sheesh: there's a good bit of work to be done around here. The systems failures dialog box should only have boxes for systems that the plane in question actually has! The altimeter settings dialog should be greyed out on any plane that doesn't have an altimeter (Wright Flyer, Colditz Glider and the Hang Glider I suppose). Steve (*) Velocity control using pitch oscillates badly. Heading control is fine. (**) I suspect the FlightGear 1903 Wright Flyer has autopilot too... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d 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 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
Harald JOHNSEN wrote:
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
dummy = XDR_decode_int32 (f_Val);
tmp = (float*) dummy;
return (*tmp);
This violates the strict aliasing rules that are the default for
gcc 4.x -- I believe it issues a warning to that effect. (Although
in this case the compiler should be able to detect that the pointer
can never be incorrectly aliased and optimize the warning away). If you
want to type-pun, you need to use a union:
union { int i; float f; } dummy;
dummy.i = XDR_decode_int32(f_Val);
return dummy.f;
The union trick also tends to be a little more readable, IMHO.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)
Melchior,
One of the original intentions of the scenery path was to search until
you found something and then stop. From what you wrote, it sounds like
the entire scenery path is searched and objects pulled from anything
that is found.
The original intention was that you could have smaller updated areas in
a path ahead of your main scenery and those areas will completely
override stuff that is later in the path. Otherwise we could have a lot
of unwanted object duplication.
Regards,
Curt.
Melchior FRANZ wrote:
This patch reshuffles parts of FGTileEntry::load() to allow mere
sea tiles to contain objects (oil rigs, nav-, weather-buoys, stuff,
etc.), and to prevent fgfs from dropping objects listed in *.stg
files that were loaded before the one containing the first
terrain.btg.gz (- FG_SCENERY).
The current structure is this:
(A) set center to 0/0/0
(B) LOOP {
- check for *.stg files in all FG_SCENERY dirs, and process
them one after the other, executing all entries right away(!);
- if terrain.btg.gz entry is found, load the tile (this sets
center to a meaningful value)
}
(C) if no terrain.btg.gz entry was found in the loop, create a
sea tile and set center accordingly
This has two disadvantages:
1. objects on mere sea tiles will be placed relative to
center 0/0/0, because a meaningful center is only set
afterwards. So none of them will show up in the scenery
(oil-rigs!).
2. also, all objects from *.stg files that were loaded before the
one with the terrain.btg.gz file are dropped. One can work around
that by reordering the paths in FG_SCENERY, but this may not be
obvious for users. It wasn't for me, at least.
The suggested structure is this (see patch):
(A) LOOP {
- go through all *.stg files in all FG_SCENERY paths and collect
data (objects stored in a vector of structures, the
terrain.btg.gz path stored as string)
}
(B) if tile found:
load tile and set center;
else:
create sea tile and set center
(C) LOOP {
- go through the vector of stored objects and place them in
the landscape
}
This way all objects are placed relative to a valid tile center (and
none at the center of Earth. :-)
NOTE that:
- the patch removes RWY_LIGHTS, because this is only a dummy that
doesn't do anything else than writing a log message.
- support for OBJECT_RUNWAY_SIGN and OBJECT_TAXI_SIGN isn't only
kept, I also verified that they do still work. They are crying
for a revival. (see http://www.flightgear.org/Gallery-v0.9.8/
near bottom -- for those who don't remember)
- the storage struct is very simply. Hard-core C++ programmers
might want to see it replaced with a set of inherited classes and
all. That can be done if it buys us anything. Currently it would
be overengineered. IMHO.
- the diff looks a lot uglier than the resulting file! :-]
The patch is valgrind- and EGLL-proof. It works well since a couple
of days.I don't expect any noticable effect on the frame rate.
Please add this to the list of yet to be discussed features for
1.0. Otherwise I'll keep it warm for 1.0.1. ;-)
m.
Index: tileentry.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tileentry.cxx,v
retrieving revision 1.47
diff -u -p -r1.47 tileentry.cxx
--- tileentry.cxx 14 Oct 2005 16:25:14 - 1.47
+++ tileentry.cxx 1 Dec 2005 16:13:57 -
@@ -659,18 +659,48 @@ bool FGTileEntry::obj_load( const string
}
+typedef enum {
+OBJECT,
+OBJECT_SHARED,
+OBJECT_STATIC,
+OBJECT_TAXI_SIGN,
+OBJECT_RUNWAY_SIGN
+} object_type;
+
+
+// storage class for deferred object processing in FGTileEntry::load()
+struct Object {
+Object(object_type t, string token, const SGPath p, istream in)
+: type(t), path(p)
+{
+in name;
+if (type != OBJECT)
+in lon lat elev hdg;
+in ::skipeol;
+
+if (type == OBJECT)
+SG_LOG(SG_TERRAIN, SG_INFO, token name);
+else
+SG_LOG(SG_TERRAIN, SG_INFO, token namelon=
lon
+ lat= latelev= elevhdg=
hdg);
+}
+object_type type;
+string name;
+SGPath path;
+double lon, lat, elev, hdg;
+};
+
+
void
FGTileEntry::load( const string_list path_list, bool is_base )
{
bool found_tile_base = false;
-// obj_load() will generate ground lighting for us ...
-ssgVertexArray *light_pts = new ssgVertexArray( 100 );
-
-ssgBranch* new_tile = new ssgBranch;
+SGPath object_base;
+vectorconst Object* objects;
-unsigned int i = 0;
-while ( i path_list.size() ) {
+// scan and parse all files and store information
+for (int i = 0; i path_list.size(); i++) {
bool has_base = false;
@@ -682,243 +712,99 @@ FGTileEntry::load( const
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Andy Ross -- Friday 02 December 2005 16:36: This violates the strict aliasing rules that are the default for gcc 4.x -- I believe it issues a warning to that effect. There's is no warning (using -Wall), and info man page claim that strict aliasing is turned off by default, even if the optimize option is used. If you want to type-pun, you need to use a union: Yes. Mathias told me so already, and even sent me a patch in the morning. I'll commit that (if Oliver doesn't object, or anyone else with authority :-). m. ___ 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)
* Curtis L. Olson -- Friday 02 December 2005 16:57: One of the original intentions of the scenery path was to search until you found something and then stop. This is still the case for terrain.btg.gz files and airports, just as it was before. But objects are always set from all stg files, with or without this patch. The difference is that objects aren't set at center of Earth, especially in sea tiles. The original intention was that you could have smaller updated areas in a path ahead of your main scenery and those areas will completely override stuff that is later in the path. That isn't the case since the Terrain/ and Objects/ dirs were invented. This patch doesn't change this. m. PS: cool 26 kB full-quote! :- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
On Fri, 2005-12-02 at 14:28, Josh Babcock wrote: No, OpenGC ^ http://www.opengc.org/ Oops. Sorry. Steve ___ 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: This is still the case for terrain.btg.gz files and airports, just as it was before. But objects are always set from all stg files, with or without this patch. The difference is that objects aren't set at center of Earth, especially in sea tiles. That's too bad, originally object loading was supposed to stop after the first btg file was found. The original intention was that you could have smaller updated areas in a path ahead of your main scenery and those areas will completely override stuff that is later in the path. That isn't the case since the Terrain/ and Objects/ dirs were invented. This patch doesn't change this. Again, it's a shame that original functionality is lost when people come later and make changes to complex code without fully understanding the intent. I suppose I need to set aside a week and go through the tile loading with a fine tooth comb ... Ok, to summarize, if you can assure everyone that your patch doesn't change any original behavor (the 'good' original behavior) and is well tested, then sure go ahead and commit it. It appears though that the scenery path semantics and devolved into an ill understood mess. We should discuss how we want the pathing to work and make the code do what we want. Right now it's a bit confusing because it apparently now includes some inadvertant side effects as a result changes to it over the past year or two. 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
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles ( generally don't drop objects)
* Curtis L. Olson -- Friday 02 December 2005 18:09: Again, it's a shame that original functionality is lost when people come later and make changes to complex code without fully understanding the intent. Isn't that one of the reasons why we have flightgear-cvslogs? For code review? Like in any other F/OSS project? Ok, to summarize, if you can assure everyone that your patch doesn't change any original behavor (the 'good' original behavior) and is well tested, then sure go ahead and commit it. OK. Thanks. I will present a patch after that which restores the original, pre-ObjectsTerrain behavior. It appears though that the scenery path semantics and devolved into an ill understood mess. That's a bit harsh. One feature was added, and another was modified (to the worse). This doesn't make it a mess. I think that the non-set sea tile center is *as* big a mess, and this was by design. But nothing is set in stone. Everything can be fixed. And if nobody noticed, and nobody cared, then it can't see the tragedy. We should discuss how we want the pathing to work and make the code do what we want. Right now it's a bit confusing [...] I know at least FGTileEntry::load() good enough now to not find it confusing. :-) We have to keep in mind that after the change to Terrain/ and Objects/ subdirs we *had* to process further dirs, namely the respective Objects/ directory. Even though we found a scenery file in the Terrain/ dir (which was searched first). Is the following behavior OK? Generate all objects from all FG_SCENERY paths until we found the first OBJECTS_BASE entry (including the other object entries in this *.stg file). Then read the matching Objects/ directory, too. But *then* stop scanning. ? 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: Is the following behavior OK? Generate all objects from all FG_SCENERY paths until we found the first OBJECTS_BASE entry (including the other object entries in this *.stg file). Then read the matching Objects/ directory, too. But *then* stop scanning. That makes sense. That way you can have a tree containing just additional objects followed by detailed scenery, followed by default scenery all on your path. You'll get the objects, plus the most appropriate scenery for the area you're in. Certainly being able to place objects at sea is a huge improvement (I mentioned that this failed quite sime time back, but was unable to work out why). -- Jon Stockill [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)
Jon Stockill wrote: Melchior FRANZ wrote: Is the following behavior OK? Generate all objects from all FG_SCENERY paths until we found the first OBJECTS_BASE entry (including the other object entries in this *.stg file). Then read the matching Objects/ directory, too. But *then* stop scanning. That makes sense. That makes sense to me too ... That way you can have a tree containing just additional objects followed by detailed scenery, followed by default scenery all on your path. And with the above suggested behavior you can override the 'global' scenery with something local or something newer or different ... without getting unintended duplication. 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
[Flightgear-devel] opengc
I'm having trouble with opengc connecting to flightgear 99 (windows) I THINK opengc is working, not sure how to check as I can't get FG to talk to it. It just seems to be listening to port 5800 FG is set up socket, out, (my ip), 5800, udp I think everything is setup properly, but I'm new to FG Has anyone got this to work...? Bruce begin:vcard fn:Bruce Benneke n:Benneke;Bruce org:Benneke Computers email;internet:[EMAIL PROTECTED] tel;work:1 (306) 542-2891 version:2.1 end:vcard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] opengc
On 12/2/05, Bruce Benneke [EMAIL PROTECTED] wrote: I'm having trouble with opengc connecting to flightgear 99 (windows) I THINK opengc is working, not sure how to check as I can't get FG to talk to it. It just seems to be listening to port 5800 FG is set up socket, out, (my ip), 5800, udp I think everything is setup properly, but I'm new to FG Has anyone got this to work...? Bruce ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d try using a port sniffer to see if any data is over the network. I recommend ethereal. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] opengc
Thanks for the quick reply I just found out the problem lies with there not being any provision to do this setup in the windows port of FG. I'm gonna move this over to linux and try again... Bruce bass pumped wrote: On 12/2/05, Bruce Benneke [EMAIL PROTECTED] wrote: I'm having trouble with opengc connecting to flightgear 99 (windows) I THINK opengc is working, not sure how to check as I can't get FG to talk to it. It just seems to be listening to port 5800 FG is set up socket, out, (my ip), 5800, udp I think everything is setup properly, but I'm new to FG Has anyone got this to work...? Bruce ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d try using a port sniffer to see if any data is over the network. I recommend ethereal. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d begin:vcard fn:Bruce Benneke n:Benneke;Bruce org:Benneke Computers email;internet:[EMAIL PROTECTED] tel;work:1 (306) 542-2891 version:2.1 end:vcard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] opengc
are you saying that you can't get FG to transmit UDP on WinXP. It works for me. On 12/2/05, Bruce Benneke [EMAIL PROTECTED] wrote: Thanks for the quick reply I just found out the problem lies with there not being any provision to do this setup in the windows port of FG. I'm gonna move this over to linux and try again... Bruce bass pumped wrote: On 12/2/05, Bruce Benneke [EMAIL PROTECTED] wrote: I'm having trouble with opengc connecting to flightgear 99 (windows) I THINK opengc is working, not sure how to check as I can't get FG to talk to it. It just seems to be listening to port 5800 FG is set up socket, out, (my ip), 5800, udp I think everything is setup properly, but I'm new to FG Has anyone got this to work...? Bruce ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d try using a port sniffer to see if any data is over the network. I recommend ethereal. ___ 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 mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] compile problem with plib
I can't figure out why this is happening. If anyone has any ideas,
please let me know. To me it seems that I have everything I need in all
the right places. Here's the situation:
*brand spanking new Debian sid install*
Package Installed PreviousNow
State
===-===-===-===-=
libglu1-xorg6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
libglu1-xorg-dev6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
xlibmesa-dri6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
xlibmesa-gl 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
xlibmesa-gl-dev 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
freeglut3 2.4.0-4 2.4.0-4 2.4.0-4
install
freeglut3-dev 2.4.0-4 2.4.0-4 2.4.0-4
install
glxgears has no problems, runs with HW accel
glxinfo looks right, it reports the OS radeon driver, lookslike it used
to when things worked.
but:
./configure --with-x --prefix=/usr/local
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal-1.4... found
checking for working autoconf... found
checking for working automake-1.4... found
checking for working autoheader... found
checking for working makeinfo... found
includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib
checking for gcc... ccache gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether ccache gcc accepts -g... yes
checking for ccache gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... ccache gcc -E
checking whether we are using the GNU C++ compiler... yes
checking whether ccache g++ accepts -g... yes
checking how to run the C++ preprocessor... ccache g++ -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... no
checking for pthread_create in -lpthread... no
checking for glNewList in -lGL... no
checking for glNewList in -lMesaGL... no
configure: error: could not find working GL library
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
Hi, as discussed already on IRC, there seems to be another gcc 4.0.2/SUSE 1.0 problem: engine sounds on the 737, Concorde and every other plane that uses thrust_lb[0] as base for the engine sound calculation don't work on this platform. Builds from SuSE 9.3 and from SUSE 10.0 compiled with -O0 instead of -O2 work, so it looks just like the multiplayer aliasing problem. Don't have a clue about the whole sound code, so this is definitely something for the C++ gurus of you. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Steve Hosgood writes: Do the current crop of cockpit builders happen to use real simulated physical instruments wired to USB or something? There are several vendors out there who have simulated instruments with needles and the like, often driven by RC servos. Granted, this runs your price up $20 an axis, probably on the order of $65-100 per instrument if you're not good enough with the styrene to build them yourself, but if you think about how much LCD panel space it'd take to cover a real-sized keyboard, I think it starts to look like a reasonable trade-off. Especially since external instruments can be driven with almost zero main CPU. if I had the budget to go hardcore (I've only built pedals, a full-length stick and a collective lever, but I've been looking at the USB joystick spec 'cause I'm starting to think about 10 bits and the ability to do some stuff on microcontrollers) I'd want that extra LCD to be dedicated to view, not instruments. Admittedly, though, I'm interested in aircraft that have a limited instrument set. Folks interested in comercial airliner cockpits have it harder than those of us who are into helicopters that just because of stability and the difficulty of removing hands from the primary controls to diddle with knobs would need a copilot to do any IFR. Dan ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] compile problem with plib
The very first thing I would check is the contents of the config.log
file. That shows the details of the test and the compiler error
signaling a failure. That often can be quite helpful.
Curt.
Josh Babcock wrote:
I can't figure out why this is happening. If anyone has any ideas,
please let me know. To me it seems that I have everything I need in all
the right places. Here's the situation:
*brand spanking new Debian sid install*
Package Installed PreviousNow
State
===-===-===-===-=
libglu1-xorg6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
libglu1-xorg-dev6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
xlibmesa-dri6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
xlibmesa-gl 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
xlibmesa-gl-dev 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11
install
freeglut3 2.4.0-4 2.4.0-4 2.4.0-4
install
freeglut3-dev 2.4.0-4 2.4.0-4 2.4.0-4
install
glxgears has no problems, runs with HW accel
glxinfo looks right, it reports the OS radeon driver, lookslike it used
to when things worked.
but:
./configure --with-x --prefix=/usr/local
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking whether make sets $(MAKE)... yes
checking for working aclocal-1.4... found
checking for working autoconf... found
checking for working automake-1.4... found
checking for working autoheader... found
checking for working makeinfo... found
includedir changed to ${prefix}/include/plib libdir is ${exec_prefix}/lib
checking for gcc... ccache gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether ccache gcc accepts -g... yes
checking for ccache gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... ccache gcc -E
checking whether we are using the GNU C++ compiler... yes
checking whether ccache g++ accepts -g... yes
checking how to run the C++ preprocessor... ccache g++ -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for ranlib... ranlib
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include
checking for gethostbyname... yes
checking for connect... yes
checking for remove... yes
checking for shmat... yes
checking for IceConnectionNumber in -lICE... no
checking for pthread_create in -lpthread... no
checking for glNewList in -lGL... no
checking for glNewList in -lMesaGL... no
configure: error: could not find working GL library
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
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] RenderTexture bug
On December 2, 2005 05:50 am, Harald JOHNSEN wrote: The code creates a pbuffer the standard way, there is nothing special in rendertexture, the only things special is the choice of the api, using glx pre or post 1.3 - and this code won't work well for long since mesa lies on version numbers. The only standard test of pbuffers that I know is fgl_glxgears. But perhaps there is a test case somewhere in the mesa/xorg cvs, after all how do they test their code ? Harald. Whether glXVersion1_3Present is true or false doesn't seem to make a difference. Last time I tried this, when glXVersion1_3Present is true, I get the GLXUnsupportPrivateRequest error at line 496. When glXVersion1_3Present is false, I get the same error at line 521. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] yasim(-test) vs fgfs
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? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] compile problem with plib
Curtis L. Olson wrote: The very first thing I would check is the contents of the config.log file. That shows the details of the test and the compiler error signaling a failure. That often can be quite helpful. Curt. Josh Babcock wrote: I can't figure out why this is happening. If anyone has any ideas, please let me know. To me it seems that I have everything I need in all the right places. Here's the situation: SNIP OK, looks like debian is broken. There was no link from libXmu.so to libXmu.so.6 in /usr/X11R6/lib. Thanks for the tip. For you Debian guys: Package Installed PreviousNow State ===-===-===-===-= libxmu6 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Was: [Flightgear-devel] compile problem with plib
Josh Babcock wrote: Curtis L. Olson wrote: The very first thing I would check is the contents of the config.log file. That shows the details of the test and the compiler error signaling a failure. That often can be quite helpful. Curt. Josh Babcock wrote: I can't figure out why this is happening. If anyone has any ideas, please let me know. To me it seems that I have everything I need in all the right places. Here's the situation: SNIP OK, looks like debian is broken. There was no link from libXmu.so to libXmu.so.6 in /usr/X11R6/lib. Thanks for the tip. For you Debian guys: Package Installed PreviousNow State ===-===-===-===-= libxmu6 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d OT, but it's possible to run .configure for fgfs without the sdl headers installed and not get an error. You don't see an error until you compile. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] CH Pro Yoke USB XML patch
The attached patch does the following things:
1) it's really difficult to fly a helicopter with the yoke,
but one can make good use of the throttle as the collective.
If one wants to fly and use the mouse as the cyclic control,
it's impossible unless the yoke doesn't send the axis0/1 position
as aileron/elevator control bindings. Thus, the patched file
checks at startup if the /rotors property exists (thanks to Melchior
for the tip on what to check!) and then ruthlessly removes
the bindings at runtime.
2) the view pitch change is reversed so that the hat movement
now corresponds to one's head (view) movement (tilting it forward means
tilting your head forward)
3) remap of some buttons:
#0: instead of firing the starter, this one cycles the views in the
reverse direction
#1: this one uses the nasal view cycle wrapper instead of the old
view-cycle command, thus we get the tip popup with the new view name
#8/#9: these get to work as x/X on the keyboard, and pressing them
together gives the same as Ctrl-X on the keyboard. For this,
I removed the /controls/engines/engine[?]/boost control bound to them
(I have no idea what these are for anyway)
Vassilii
Index: ../data/Input/Joysticks/CH/pro-yoke-usb.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Input/Joysticks/CH/pro-yoke-usb.xml,v
retrieving revision 1.19
diff -u -p -r1.19 pro-yoke-usb.xml
--- ../data/Input/Joysticks/CH/pro-yoke-usb.xml 22 Jun 2005 13:08:02 -
1.19
+++ ../data/Input/Joysticks/CH/pro-yoke-usb.xml 3 Dec 2005 01:41:34 -
@@ -4,6 +4,24 @@
nameCH PRODUCTS CH FLIGHT SIM YOKE USB /name
nameCH FLIGHT SIM YOKE USB /name
+ nasal
+ script![CDATA[
+ view_mod = 0;
+ reset_view = func {
+ setprop(/sim/current-view/field-of-view,
+ getprop(/sim/view/config/default-field-of-view-deg));
+ view_mod = 0;
+ }
+ if (props.globals.getNode(/rotors) != nil) {
+grove = props.globals.getNode(this);
+
+grove.getNode(axis[0]).removeChildren(binding);
+grove.getNode(axis[1]).removeChildren(binding);
+ }
+ ]]
+ /script
+ /nasal
+
axis n=0
descAileron/desc
@@ -110,7 +128,7 @@
binding
commandproperty-adjust/command
property/sim/current-view/goal-pitch-offset-deg/property
-step type=double2.0/step
+step type=double-2.0/step
/binding
/low
high
@@ -118,29 +136,25 @@
binding
commandproperty-adjust/command
property/sim/current-view/goal-pitch-offset-deg/property
-step type=double-2.0/step
+step type=double2.0/step
/binding
/high
/axis
button n=0
-descFire Starter on Selected Engine(s)/desc
+ repeatablefalse/repeatable
+ descScroll in reverse through views./desc
binding
commandnasal/command
- scriptcontrols.startEngine()/script
+ scriptview.stepView(-1)/script
/binding
- mod-up
- binding
-commandnasal/command
-scriptprops.setAll(/controls/engines/engine, starter, 0)/script
- /binding
- /mod-up
/button
button n=1
repeatablefalse/repeatable
binding
- commandview-cycle/command
+ commandnasal/command
+ scriptview.stepView(1)/script
/binding
/button
@@ -221,31 +235,46 @@
/button
button n=8
- repeatabletrue/repeatable
- binding
-commandproperty-adjust/command
-property/controls/engines/engine[0]/boost/property
-step type=double+0.01/step
- /binding
+ descDecrease field of view./desc
+ repeatable type=boolfalse/repeatable
+ binding
+ commandnasal/command
+ script![CDATA[
+ view.decrease();
+ if(view_mod0) { reset_view(); } else { view_mod = -1; }
+ ]]
+ /script
+ /binding
+ mod-up
binding
-commandproperty-adjust/command
-property/controls/engines/engine[1]/boost/property
-step type=double+0.01/step
+commandnasal/command
+script![CDATA[
+ if (view_mod0) { view_mod += 1;}
+]]/script
/binding
+ /mod-up
/button
button n=9
- repeatabletrue/repeatable
- binding
-commandproperty-adjust/command
-property/controls/engines/engine[0]/boost/property
-step type=double-0.01/step
- /binding
+ descIncrease field of view./desc
+ repeatable type=boolfalse/repeatable
+ binding
+ commandnasal/command
+ script![CDATA[
+view.increase();
+ if(view_mod0) { reset_view(); } else { view_mod = 1; }
+ ]]
+ /script
+ /binding
+ mod-up
binding
-commandproperty-adjust/command
-property/controls/engines/engine[1]/boost/property
-step type=double-0.01/step
+commandnasal/command
+script![CDATA[
+ if (view_mod0) { view_mod -= 1;}
+]]
+/script
/binding
+ /mod-up
/button
button n=10
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear FDM
k... got it fixed :-) On 12/2/05, bass pumped [EMAIL PROTECTED] wrote: On 12/1/05, bass pumped [EMAIL PROTECTED] wrote: Hi, I'm glad to report that I am an idiot and that there is nothing wrong with the data transmission code. It works fine except when trying to write throttle over udp. For some wierd reason it takes values of one or zero at random when the throttle is pushed from 0 to 1. For example, when sending a throttle value of 0.3459 the throttle gets set to 1 but stays at 0 at most points before and after that. I do remember seeing this same problem with 9.8 and also remember mentioning to me that this might be a bug. Would someone be able to give me some pointers on how I may be able to fix this? Thanks, Is there anybody out there?? follow up with pink floyd sound effects:-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: compile problem with plib
Josh Babcock writes: looks like debian is broken. There was no link from libXmu.so to libXmu.so.6 in /usr/X11R6/lib. Thanks for the tip. For you Debian guys: Package Installed PreviousNow State ===-===-===-===-= libxmu6 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install you need to install the development packages as well. in this case you need libxmu-dev but it's probably better to install xlibs-dev which will pull in all the relevant packages. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fg hanging
Josh Babcock wrote: Looks like the latest CVS version of FG is hanging: SNIP Anybody else seeing this? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Well, whatever it was, doing a fresh install of Debian and recompiling changed it. Now it just segfaults right away. Does this look like more problems with the OS radeon driver? It's kind of annoying to do a fresh checkout and compile from CVS onto a newly installed machine and get a segfault that no-one else sees. I just don't see what is different on this machine. http://jrbabcock.home.comcast.net/flightgear/strace.fgfs.0 Josh ___ 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 Friday 02 December 2005 04:18 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? Dave ___ 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. ___ 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
Last night I noticed that a couple of the yasim-related updates happened later after my prev. pull. This time tu154 doesn't want to load up at all (btw this time I am not flying using the mouse, having the CH Products USB yoke+pedals connected): YASim SOLUTION FAILURE: Insufficient elevator to trim for approach ___ 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 Samstag 03 Dezember 2005 01:57, 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? I know of one difference: Ground intersection tests. The yasim-test uses the standard ellipsoids sea level as ground as it has no scenery. Don't know what else. 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
