Re: [Flightgear-devel] Feature request: will sound options be saved?
At this time no option is saved from FlightGear itself. If you are using fgrun then the options specified in fgrun will be saved indeed. And sound volume seems not to be included in fgrun options scheme. I understand. This is not an easy change (for FlightGear) but you could specify it yourself by adding the following: --prop:/sim/sound/volume=0.8 Erik That's a nice tip, thanks Erik :-) Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] JSBSim: Failed to tie propertypropulsion/c-thrust[0] to a pointer
> When the JSB a/c model has several engine+propeller we get > that JSB message error: > "Failed to tie property propulsion/c-thrust[0] to a pointer" > What must be defined in Aircraft.xml to solve it. > -- > Gerard Which version of JSBSim are you using? Is it the one currently in FlightGear CVS? You'll need to tell me more about your aircraft/propeller config files (or email them to me). Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] commit checker
Hi, On Friday 01 July 2005 14:05, Melchior FRANZ wrote: > Here's a small shell script that can be used to check if files are "good > enough" to be checked in: > > http://members.aon.at/mfranz/citest [1.2kb] [..] > checking for DOS line endings ... > ./dc3/Sounds/read-trev.txt: ASCII English text, with very long lines, > with CRLF line terminators ./Hunter/pilots-notes.txt: ISO-8859 English > text, with CRLF line terminators ... I'm working on a similar tool (meaning: checking sanity of files) for another project and this part does not work correctly with all versions of 'file'. Some just display things along the lines of "XML document text" etc. and no further information. Just thought I'd let you know. --Ivo ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
On Tuesday 02 Aug 2005 00:01, Arnt Karlsen wrote: > On Mon, 01 Aug 2005 18:14:16 -0400, Josh wrote in message > > <[EMAIL PROTECTED]>: > > Arnt Karlsen wrote: > > > ..pass, what I learned from my own research on gpu's > > > before buying an ATI 9250 clone, is ATI are "native 24bpp" > > > and "24bpp only", where Nvidia is "1x32bpp or 2x16bpp", > > > suggesting "ATI would suck at 16bpp doing less than > > > 3x8bpp" and "at 32bpp not being able to see or make any > > > use of the top 8 bits." > > > My understanding of Nvidea is "their cards should work > > > better at 32bpp and 16bpp than at 24bpp, because 24bpp > > > wastes half a 16bpp engine." > > > > > > > > > > > >From what I understand, 24bpp is the same amount of data as > > > 32bpp. It > > > > just signifies that there is a separate alpha channel. Since > > this is not strictly 'color' the last 8 alpha bits are not > > counted in the color depth. > > ..yes, but does this impact 32bpp performance relative to > 24bpp and "not" 24bpp relative to 16bpp like it "should" on > ATI's and "should not" on Nvidea and vice versa? > > > Still, each pixel takes up 32 bits of memory. > > ..my understanding is ATI cannot do 32bpp math at all, their > gpus are "24bpp only", while Nvidea gpus does both 16bpp and > 32bpp "but not 24bpp." > Strategic gpu HW design choises made a decade or so back. > > > ATI cards do 16bpp just the same as all the other cards, 16 > > bits of color and nothing else. (red and blue get 5bpp, > > green I think is the one that gets 6bpp) > > ..true, at the same speed as they will do 24bpp, 15bpp and > possibly also 8bpp, I doubt ATI gpu's has a 3x8bpp mode, > Nvidea however talks about a 2x16bpp and an 1x32bpp mode. As Josh said, in a 32 bpp mode 8 bits are used for an alpha channel so there isn't really any 32 bpp maths to worry about. It probably makes more sense to think in terms of 3x8 bpp for 24 bit modes or 4x8 bpp for 32 bit display modes, with each 8 bit channel giving 256 levels of intensity (brightness). 8 bit and lower colour modes work differently and use an indexed palette and a look-up table of absolute rgb values. The actual colours in the palette can have any value but you're limited to a total of 256 of 'em. An 8 bit greyscale mode is essentially the same as one of the 24 bit colour modes channels except you're only dealing with absolute brightness - all colour info is ignored. 24 bpp data can be displayed on a 15 or 16 bit mode simply by discarding the least significant bits of each channel. This can produce some colour banding and other undesired artifacts but it's economical as the data requires no conversion. After 24 bpp the next commonly used colour mode is 36 bpp - 3x12 bpp. This is mainly used for print stuff. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] JSBSim: Failed to tie property propulsion/c-thrust[0] to a pointer
When the JSB a/c model has several engine+propeller we get that JSB message error: "Failed to tie property propulsion/c-thrust[0] to a pointer" What must be defined in Aircraft.xml to solve it. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
On Mon, 01 Aug 2005 23:08:03 +0200, Gerard wrote in message <[EMAIL PROTECTED]>: > Le lundi 01 août 2005 à 21:53 +0200, Arnt Karlsen a écrit : > > > > Being Nvidia and X installed , i continu to search a good answer > > > : > > > After many experimentations, > > > I did not notice any change between 24bpp and 32 bpp. > > > > ...glxgears, FlightGear etc f/s? > > Ouaf. glxgears isn't a representative benchmark, with it we > cannot get a good performance analysis. ..I said "etc". ;o) > I have played to demonstrate that my old ati 9200 and my other old > nvidia 5200 is better than the NVIDIA 6600GT. > > assuming we use the Nvidia 7xxx driver (not the 6xxx) > > FG says 6600GT is x2.5 more (32 bpp or 24 seem the same performance ) > > Celestia says (depending on the render choice) from x3 to x4 more > (probably 32bpp, my Xserver is permanently 32bpp) ..benchmark start-up commandline ideas will help benchmark apples and oranges, as such, rather than as bananas and pineapples. ;o) > > > I am not an expert in graphics development, may be the differences > > > depends on the GPU itself and the capability to handle both > > > definitions, > > > The main question could be about CPU: > > > does CPU time used and is it any losses with one or the other ? > > > > > > Does somebody can give an answer ? > > > > ...pass, what I learned from my own research on gpu's before buying > > an ATI 9250 clone, is ATI are "native 24bpp" and "24bpp only", where > > Nvidia is "1x32bpp or 2x16bpp", suggesting "ATI would suck at 16bpp > > doing less than 3x8bpp" and "at 32bpp not being able to see or make > > any use of the top 8 bits." > > My understanding of Nvidea is "their cards should work better at > > 32bpp and 16bpp than at 24bpp, because 24bpp wastes half a 16bpp > > engine." > > > > > Ok , i will try to analyse it. > -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
On Mon, 01 Aug 2005 18:14:16 -0400, Josh wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > > ..pass, what I learned from my own research on gpu's before buying > > an ATI 9250 clone, is ATI are "native 24bpp" and "24bpp only", where > > Nvidia is "1x32bpp or 2x16bpp", suggesting "ATI would suck at 16bpp > > doing less than 3x8bpp" and "at 32bpp not being able to see or make > > any use of the top 8 bits." > > My understanding of Nvidea is "their cards should work better at > > 32bpp and 16bpp than at 24bpp, because 24bpp wastes half a 16bpp > > engine." > > > > > > >From what I understand, 24bpp is the same amount of data as 32bpp. It > just signifies that there is a separate alpha channel. Since this is > not strictly 'color' the last 8 alpha bits are not counted in the > color depth. ..yes, but does this impact 32bpp performance relative to 24bpp and "not" 24bpp relative to 16bpp like it "should" on ATI's and "should not" on Nvidea and vice versa? > Still, each pixel takes up 32 bits of memory. ..my understanding is ATI cannot do 32bpp math at all, their gpus are "24bpp only", while Nvidea gpus does both 16bpp and 32bpp "but not 24bpp." Strategic gpu HW design choises made a decade or so back. > ATI cards do 16bpp just the same as all the other cards, 16 bits of > color and nothing else. (red and blue get 5bpp, green I think is the > one that gets 6bpp) ..true, at the same speed as they will do 24bpp, 15bpp and possibly also 8bpp, I doubt ATI gpu's has a 3x8bpp mode, Nvidea however talks about a 2x16bpp and an 1x32bpp mode. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Arnt Karlsen wrote: > ..pass, what I learned from my own research on gpu's before buying an > ATI 9250 clone, is ATI are "native 24bpp" and "24bpp only", where Nvidia > is "1x32bpp or 2x16bpp", suggesting "ATI would suck at 16bpp doing less > than 3x8bpp" and "at 32bpp not being able to see or make any use of > the top 8 bits." > My understanding of Nvidea is "their cards should work better at 32bpp > and 16bpp than at 24bpp, because 24bpp wastes half a 16bpp engine." > > >From what I understand, 24bpp is the same amount of data as 32bpp. It just signifies that there is a separate alpha channel. Since this is not strictly 'color' the last 8 alpha bits are not counted in the color depth. Still, each pixel takes up 32 bits of memory. ATI cards do 16bpp just the same as all the other cards, 16 bits of color and nothing else. (red and blue get 5bpp, green I think is the one that gets 6bpp) Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport LFPO Paris Orly Update
Martin Spott writes: > David Luff wrote: > > > Can I jump-in here and say to everyone that updated airports should > > be sent to Robin Peel now. > > So I assume he accepted all changes that you've been collecting until > now ? > All of the one's I sent him, yes, which is about half of them, including all of yours. (Including the recent small airport additions in N Germany / Denmark ?). There was a slight problem with LCHM though - at the moment his data has your taxiways from v6 but the runways from v5, so they don't line up. I'll send it again and remind him about the runways! Hopefully I'll get rid of the rest of the data onto him by the time he updates again. Robin is using TaxiDraw himself now, as are a number of the regular X-Plane contributors, so there really should be no problem now :-) Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Le lundi 01 août 2005 à 23:08 +0200, Matthias Boerner a écrit : > Hi, > > also NVIDIA is not working with 32bpp: You will get following error message > if > you switch to 32bpp in the section "Screen", SubSection "Display",...: > > (II) Setting vga for screen 0. > (EE) NVIDIA(0): Given color depth (32) is not supported > (EE) NVIDIA(0): *** Aborting *** > (II) UnloadModule: "nvidia" > (EE) Screen(s) found, but none have a usable configuration. > > > The man pages of xorg.conf say at "DISPLAY SUBSECTION": > > Depth depth > > This entry specifies what colour depth the Display subsection is to be used > for. This entry is usually specified, but it may be omitted to create a > match-all Display subsection or when wishing to match only against the FbBpp > parameter. The range of depth values that are allowed depends on the driver. > Most driver support 8, 15, 16 and 24. Some also support 1 and/or 4, and some > may support other values (like 30). Note: depth means the number of bits in a > pixel that are actually used to determine the pixel colour. 32 is not a valid > depth value. Most hardware that uses 32 bits per pixel only uses 24 of them > to hold the colour information, which means that the colour depth is 24, not > 32. > > Matthias > Are you confusing both depth and pixel definition: here an extract from NVIDIA readme > DEPTH, BITS PER PIXEL, AND PITCH While not directly a concern when programming modes, the bits used per pixel is an issue when considering the maximum programmable resolution; for this reason, it is worthwhile to address the confusion surrounding the terms "depth" and "bits per pixel". Depth is how many bits of data are stored per pixel. Supported depths are 8, 15, 16, and 24. Most video hardware, however, stores pixel data in sizes of 8, 16, or 32 bits; this is the amount of memory allocated per pixel. When you specify your depth, X selects the bits per pixel (bpp) size in which to store the data. Below is a table of what bpp is used for each possible depth: Depth BPP ------ 8 8 15 16 16 16 24 32 > -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Le lundi 01 août 2005 à 21:53 +0200, Arnt Karlsen a écrit : > > Being Nvidia and X installed , i continu to search a good answer : > > After many experimentations, > > I did not notice any change between 24bpp and 32 bpp. > > ...glxgears, FlightGear etc f/s? Ouaf. glxgears isn't a representative benchmark, with it we cannot get a good performance analysis. I have played to demonstrate that my old ati 9200 and my other old nvidia 5200 is better than the NVIDIA 6600GT. assuming we use the Nvidia 7xxx driver (not the 6xxx) FG says 6600GT is x2.5 more (32 bpp or 24 seem the same performance ) Celestia says (depending on the render choice) from x3 to x4 more (probably 32bpp, my Xserver is permanently 32bpp) > > > I am not an expert in graphics development, may be the differences > > depends on the GPU itself and the capability to handle both > > definitions, > > The main question could be about CPU: > > does CPU time used and is it any losses with one or the other ? > > > > Does somebody can give an answer ? > > ...pass, what I learned from my own research on gpu's before buying an > ATI 9250 clone, is ATI are "native 24bpp" and "24bpp only", where Nvidia > is "1x32bpp or 2x16bpp", suggesting "ATI would suck at 16bpp doing less > than 3x8bpp" and "at 32bpp not being able to see or make any use of > the top 8 bits." > My understanding of Nvidea is "their cards should work better at 32bpp > and 16bpp than at 24bpp, because 24bpp wastes half a 16bpp engine." > > Ok , i will try to analyse it. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Hi, also NVIDIA is not working with 32bpp: You will get following error message if you switch to 32bpp in the section "Screen", SubSection "Display",...: (II) Setting vga for screen 0. (EE) NVIDIA(0): Given color depth (32) is not supported (EE) NVIDIA(0): *** Aborting *** (II) UnloadModule: "nvidia" (EE) Screen(s) found, but none have a usable configuration. The man pages of xorg.conf say at "DISPLAY SUBSECTION": Depth depth This entry specifies what colour depth the Display subsection is to be used for. This entry is usually specified, but it may be omitted to create a match-all Display subsection or when wishing to match only against the FbBpp parameter. The range of depth values that are allowed depends on the driver. Most driver support 8, 15, 16 and 24. Some also support 1 and/or 4, and some may support other values (like 30). Note: depth means the number of bits in a pixel that are actually used to determine the pixel colour. 32 is not a valid depth value. Most hardware that uses 32 bits per pixel only uses 24 of them to hold the colour information, which means that the colour depth is 24, not 32. Matthias ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
On Mon, 01 Aug 2005 15:13:54 +0200, Gerard wrote in message <[EMAIL PROTECTED]>: > Le lundi 01 août 2005 à 00:18 +0200, Arnt Karlsen a écrit : > > On Sat, 30 Jul 2005 16:40:58 +0200, Oliver wrote in message > > <[EMAIL PROTECTED]>: > > > > > On Saturday 30 July 2005 16:25, Dave Martin wrote: > > > > I don't know if anyone has brought this up yet but the 1.0-7667 > > > > driver from NVIDIA for linux breaks the drawn shadows as in they > > > > don't appear at all. > > > > > > > > This tested and confirmed on a FX5800U and 6600GT PCIE > > > > > > > > Dave Martin > > > > > > No, it works here. > > > You just need to start flightgear in 24 bit mode. > > > fgfs --bpp=24 > > > > ...does " --bpp=32 " work any better than 24bpp for you? > > (Assuming X run at 32 on Nvidia cards) > > > Being Nvidia and X installed , i continu to search a good answer : > After many experimentations, > I did not notice any change between 24bpp and 32 bpp. ..glxgears, FlightGear etc f/s? > I am not an expert in graphics development, may be the differences > depends on the GPU itself and the capability to handle both > definitions, > The main question could be about CPU: > does CPU time used and is it any losses with one or the other ? > > Does somebody can give an answer ? ..pass, what I learned from my own research on gpu's before buying an ATI 9250 clone, is ATI are "native 24bpp" and "24bpp only", where Nvidia is "1x32bpp or 2x16bpp", suggesting "ATI would suck at 16bpp doing less than 3x8bpp" and "at 32bpp not being able to see or make any use of the top 8 bits." My understanding of Nvidea is "their cards should work better at 32bpp and 16bpp than at 24bpp, because 24bpp wastes half a 16bpp engine." -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
On Mon, 1 Aug 2005 18:59:21 +0100, David wrote in message <[EMAIL PROTECTED]>: > Harald JOHNSEN writes: > > > Oliver Schroeder wrote: > > > > > >2) chat messages > > >[...] > > >protocoll supports chat-messages and the ATC-module has functions > > >to queue and display them on screen. So it should'nt be too hard > > >to combine them and enable chat-messages. Somebody willing to give > > >it a try? > > > > > > > > As Pigeon said, make that a separate window, because the ATC line is > > > > allready nearly impossible > > to read ;) It should not be hard to code but the atc code is not > > good for that (anyway it does not > > queue messages). > > > > Correct - it's not intended to queue messages. Messages transmitted > at the same time end up displayed on top of each other and appear > garbled, much as messages transmitted at the same time probably sound > garbled, screeched, or one non-existant in real life. All the message > collision logic is in the ATC and AI units, which attempt to speak > only when the frequency is clear. There are a few bugs in there, so > sometimes garbled speech occurs! ..garbled speech occurs in RL too. Bug in RL, feature in FG. ;o) > I do agree though that the basic ATC display can be nearly unreadable > under some colour conditions - it's very much a quick hack ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport LFPO Paris Orly Update
David Luff wrote: > Can I jump-in here and say to everyone that updated airports should > be sent to Robin Peel now. So I assume he accepted all changes that you've been collecting until now ? 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] Linux Expo, UK
Christopher Horler writes: > Hi All, > > Although I've not recently been active, I've just spotted something. > > After last years success I was wondering if anyone was interested in > returning > to the .org Village again? > > This year I can bring some hardware. > > Hotel arrangements - If anyone needs a hotel, I might be able to help out. > I'd very much like to do another expo, but this year I might be simply too busy to find the time unfortunately :-( I can't even keep up with the mailing list. If you were doing it I'd try and make at least one day, but I simply can't commit any time in advance. It was great to meet up with everyone last time though - we ought to try it again one year. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport LFPO Paris Orly Update
Martin Spott writes: > Orly is a well-known airfield which means the location is vermy much > expected to be correct in the airport database. If the airport layout > is incorrect, then the best bet is to correct this with TaxiDraw and > send the result to David Luff. > Can I jump-in here and say to everyone that updated airports should be sent to Robin Peel now. Simply export your project in X-Plane format from the 'File' menu, and sent to to Robin: www.x-plane.org/home/robinp/Contact.htm I believe he can cope with TaxiDraw project format as well, and changed runways are no problem as long as you tell him. Now that he is reliably accepting our data again there is no need to store data ourselves - it's simply slowing my coding down. I guess it might become necessary again in the future if/when we extend the data format beyond what X-Plane offers, but we can cross that bridge when we come to it. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Harald JOHNSEN writes: > Oliver Schroeder wrote: > > >2) chat messages > >[...] > >protocoll supports chat-messages and the ATC-module has functions to queue > >and display them on screen. So it should'nt be too hard to combine them and > >enable chat-messages. Somebody willing to give it a try? > > > > > As Pigeon said, make that a separate window, because the ATC line is > allready nearly impossible > to read ;) It should not be hard to code but the atc code is not good > for that (anyway it does not > queue messages). > Correct - it's not intended to queue messages. Messages transmitted at the same time end up displayed on top of each other and appear garbled, much as messages transmitted at the same time probably sound garbled, screeched, or one non-existant in real life. All the message collision logic is in the ATC and AI units, which attempt to speak only when the frequency is clear. There are a few bugs in there, so sometimes garbled speech occurs! I do agree though that the basic ATC display can be nearly unreadable under some colour conditions - it's very much a quick hack ;-) Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Only Information, Documentation
Le lundi 01 août 2005 à 18:38 +0200, Gerard Robin a écrit : > I have found this > > http://www.auf.asn.au/groundschool/ > > > Probably some of you knows it. > > I will put it in good place, i have found many good explainations or better this which is the upper level http://www.auf.asn.au/groundschool/contents.html -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Only Information, Documentation
I have found this http://www.auf.asn.au/groundschool/ Probably some of you knows it. I will put it in good place, i have found many good explainations -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Preferences.xml question
Oh, BTW.I figured out that the splash screens are SGI textures, the same as the AC textures and pictures can be converted to the RGB format in 512x512 size, and placed in the textures directory for the randomization code to display.So I am done with that. If I am working on anything that is of potential interest to others in the group, I will let you knowbut that will be a while, until my coding skills get better, which can either be sooner or later, depending on the assistance that I get from the group (which has been excellent in all cases except one...;) CraigErik Hofman <[EMAIL PROTECTED]> wrote: Craig Martin wrote:> To put in pictures that I likeyou know, the whole customization > thing.> > Is replacing the splash screens a problem in some way?Not really, but it sounds to me you have some kind of project you're working on. And that makes me curious ...Erik___Flightgear-devel mailing listFlightgear-devel@flightgear.orghttp://mail.flightgear.org/mailman/listinfo/flightgear-devel2f585eeea02e2c79d7b1d8c4963bae2d___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear mentioned at Clarin, the most printed newspaper in Spanish language]
Message transféré De: Gerard Robin <[EMAIL PROTECTED]> À: FlightGear developers discussions Objet: Re: [Flightgear-devel] FlightGear mentioned at Clarin, the most printed newspaper in Spanish language Date: Mon, 01 Aug 2005 14:53:11 +0200 Le lundi 01 août 2005 à 09:55 +0200, Erik Hofman a écrit : > Pablo J. wrote: > > Hi everybody, > > > > I'm very pleased to let you know that FlightGear was mentioned (although > > consider as a "game") in the Computers section of Clarin, the most > > important newspaper in Argentina, and the newspaper in Spanish language > > with the most printed copies every day. > > Nice! > > > May be some of you is dissapointed that FG was mentioned along some > > other free games, but for me is really very important that the link to > > FG had appeared in such a publication in my country. > > I'm not that disappointed, FlightGear *can* be used as a game but it's > main goal is a (scientific) flight simulator. > > Erik > Is it so "fat" to say in our loved http://flightgear.org/. ===What is really flightgear => scientific flight simulator. ===Who could be interested on => students, engineers, peoples who like and want to learn how does an aircraft... We can understand it in http://jsbsim.sourceforge.net/. We could expand it to FlightGear -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear mentioned at Clarin, the most printed newspaper in Spanish language
Le lundi 01 août 2005 à 09:55 +0200, Erik Hofman a écrit : > Pablo J. wrote: > > Hi everybody, > > > > I'm very pleased to let you know that FlightGear was mentioned (although > > consider as a "game") in the Computers section of Clarin, the most > > important newspaper in Argentina, and the newspaper in Spanish language > > with the most printed copies every day. > > Nice! > > > May be some of you is dissapointed that FG was mentioned along some > > other free games, but for me is really very important that the link to > > FG had appeared in such a publication in my country. > > I'm not that disappointed, FlightGear *can* be used as a game but it's > main goal is a (scientific) flight simulator. > > Erik > Is it so "fat" to say in our loved http://flightgear.org/. ===What is really flightgear => scientific flight simulator. ===Who could be interested on => students, engineers, peoples who like and want to learn how does an aircraft... We can understand it in http://jsbsim.sourceforge.net/. We could expand it to FlightGear -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [Fwd: [Jsbsim-devel] Carrier: Aircraft Landing and Launching]
Message transféré De: Gerard Robin <[EMAIL PROTECTED]> À: [EMAIL PROTECTED] Objet: [Jsbsim-devel] Carrier: Aircraft Landing and Launching Date: Mon, 01 Aug 2005 15:56:35 +0200 Hi, Jon Up to now, JSBSim does not offer the Aircraft Landing, Launching, on Carrier. With the old existing JSBSim which is integrated in FG CVS ,we can do it with a specific patch. If somebody do not want patch, it is only on way =>use YaSim . The new JSBSim stand alone is available. It will probably be integrated in a near futur in FG. Have you sheduled in a very short term before FG integration that facility ? I fear that we would not be able to use the old Patch. And to have to use only YaSim. Thanks BTW: Isn't it interesting to include it in your stand alone release, the Aircraft Dynamic analysis will be very interesting, launching and landing are very different compared to the usual "take off, landing". -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Le lundi 01 août 2005 à 00:18 +0200, Arnt Karlsen a écrit : > On Sat, 30 Jul 2005 16:40:58 +0200, Oliver wrote in message > <[EMAIL PROTECTED]>: > > > On Saturday 30 July 2005 16:25, Dave Martin wrote: > > > I don't know if anyone has brought this up yet but the 1.0-7667 > > > driver from NVIDIA for linux breaks the drawn shadows as in they > > > don't appear at all. > > > > > > This tested and confirmed on a FX5800U and 6600GT PCIE > > > > > > Dave Martin > > > > No, it works here. > > You just need to start flightgear in 24 bit mode. > > fgfs --bpp=24 > > ...does " --bpp=32 " work any better than 24bpp for you? > (Assuming X run at 32 on Nvidia cards) > Being Nvidia and X installed , i continu to search a good answer : After many experimentations, I did not notice any change between 24bpp and 32 bpp. I am not an expert in graphics development, may be the differences depends on the GPU itself and the capability to handle both definitions, The main question could be about CPU: does CPU time used and is it any losses with one or the other ? Does somebody can give an answer ? -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Preferences.xml question
Not really, other than trying to use this as a learning environment. So I am trying to tweak the little things first, so that I can get a handle on how things are structured.then move on to things like the HUDwhich is my real area of interest.Erik Hofman <[EMAIL PROTECTED]> wrote: Craig Martin wrote:> To put in pictures that I likeyou know, the whole customization > thing.> > Is replacing the splash screens a problem in some way?Not really, but it sounds to me you have some kind of project you're working on. And that makes me curious ...Erik___Flightgear-devel mailing listFlightgear-devel@flightgear.orghttp://mail.flightgear.org/mailman/listinfo/flightgear-devel2f585eeea02e2c79d7b1d8c4963bae2d___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] G3DViewer
This might be a useful utility for people 'dealing' with FG models - adding to that he offers a very nice model of my second favourite truck :-) http://automagically.de/index.shtml?g3dviewer 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
Re: [Flightgear-devel] FlightGear mentioned at Clarin, the most printed newspaper in Spanish language
Pablo J. wrote: Hi everybody, I'm very pleased to let you know that FlightGear was mentioned (although consider as a "game") in the Computers section of Clarin, the most important newspaper in Argentina, and the newspaper in Spanish language with the most printed copies every day. Nice! May be some of you is dissapointed that FG was mentioned along some other free games, but for me is really very important that the link to FG had appeared in such a publication in my country. I'm not that disappointed, FlightGear *can* be used as a game but it's main goal is a (scientific) flight simulator. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Preferences.xml question
Craig Martin wrote: To put in pictures that I likeyou know, the whole customization thing. Is replacing the splash screens a problem in some way? Not really, but it sounds to me you have some kind of project you're working on. And that makes me curious ... Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
Andy Ross wrote: Oliver Schroeder wrote: Andy is, of course, right. We should not send binary data over the wire and I think that using XDR for transmission Binary is fine. Uncooked memory is not. :) And FWIW, XDR seems awfully heavyweight to me. It involves a comparatively large amount of code for things that are really pretty easy, while at the same time making hand optimization of the packet format more difficult. The term "binary" is in fact not precise enough in this context. We need a way to encode the data in a host independent format, regardless of what data is send. XDR is a generalization of functions like ntohl(3) and htonl(3). If we implement it ourself with exactly what we need, it isn't bloated at all. Note that this hand tuning can be really beneficial, especially if the server is on a low bandwidth link. The multiplayer protocol I was thinking of (which these days is, I guess, mostly an idea box for the working version) managed to pack a full precision* position, velocity, acceleration, orientation and rotation rate into a block of 26 bytes. That's about 3x smaller than a naive implementations based on floats and doubles, which means that you can transmit data on 3x as many aircraft/objects over the same link. I don't understand exactly what you mean here, but as mentioned above: XDR is just an encoding standard for data. We can send whatever data we want and we should think about what data should really go over the wire. But that's a different story. Regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
