Re: [Flightgear-devel] shaders heads up
Am 28.08.10 01:16, schrieb Tim Moore: There needs to be some coordinate for the fog. You could try using gl_FogFragCoord instead. Tim Thanks for your answer Tim. And what should happen when I change gl_BackColor.a from 0.0 to 1.0 in default.vert? I see here that this makes the terrain shaders (or the light) running at least for some older ATI cards (and .z/.w is def. not the problem). What do I loose with this change? What do I have to check? And could this work for terrain also for other cards with gl_BackColor.a = 1.0? Thanks, Yves -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiple views without slaving to master camera
Hi, I hope someone can help me with the following. I am using FlightGear v2.0.0. I am trying to develop a feature for a Ground Replay System for an actual prototype aircraft using flightgear. What i want to achieve: Multiple views of the same scene . Lets call them View1 and View2(they may be on 2 separate screens). There should be only one instance of flightgear running. I should be able to have View1 = Cockpit View View2 = Chase View or View1 = Helicopter View View2 = Cockpit View or any other such combination of views. I am using FlightGear 2.0.0 I should be able to switch the view in each viewport without affecting the view in the other view port. i.e i should be able to double right click and change the view on each display with the mouse without affecting the view in the other display. README.multiscreen in the FlightGear documentation says its possible to create a master camera and a slave camera that is offset from the master camera. BUT I want 2 master cameras that can switch to any view at any time. I know that many people would like to see such feature but to my knowledge without a major change in the hardcode it isn't possible. No idea how difficult an implementation would be- maybe Tim Moore the man behind the multiple views can enlight us. May I ask you which aircrafts prototype you work on? Cheers Heiko -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial port programming question ...
Curtis Olson wrote: This is a little off topic, but I don't know where else I can find a stronger knowledge pool. :-) I am working on some code that needs to read and write from a serial port and has to write vast quantities of data ... Curtis, I wouldn't use threads, but a whole separated process. Use circular buffers in shared memory to transfer data, and semaphores to coordinate data transfers in/from these buffers. That way your main process only needs to do non-blocking memory to memory transfers. The serial coms process can handle all the quirks of the protocol, create separate Tx and Rx threads if necessary, decide when to drop data, block itself when needed etc. One of the advantages of using a separate process vs threads in the main application is fault isolation. (1) The unavoidable crashes during development may bring down only this process, allowing you to continue by restarting only this part and not the whole application. The same applies if you want to try a different version. Stop the subprocess, start a new one. Hope this helps, Roberto Waltman. (1) I worked for a company whose coding standards required a manager's waiver to use threads, because of the difficulties of debugging complex multi-thread applications where every thread can corrupt global data. And the fault isolation. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial port programming question ...
Hi Jacob, Thanks for the reply, I've got a couple options to consider so hopefully I can get something that works here pretty quickly. Best regards, Curt. On Fri, Aug 27, 2010 at 10:44 PM, Jacob Burbach jmburb...@gmail.com wrote: I know I can use select() to check if the file descriptor is ready for a write(), but that would still not be a way to determine if the file descriptor is ready for the size of my particular write() and ensure that my write() will return in a timely fashion ... it seems like it would still leave me open for potential trouble or potential unwanted time delays. I'm no expert and can't answer all your questions or give best design advice...but. If your using non blocking IO and select signals a write is available, then that write should always return in a timely fashion. Like you said there though, select won't tell you how much can be written, nor does the write call guarantee it will write everything you give it. As usual when doing non-blocking asynchronous type stuff, it will be up to you to do the book keeping and send any remaining data in subsequent writes. Though I seem to recall there may be some ioctl calls available that actually tell you how much data is ready for reading or writing on a file descriptor, but can't recall off hand...may well be platform/os/arch specific. cheers -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial port programming question ...
Hi Roberto, Thanks for the reply and the suggestions. I'm very nervous about giving myself a threading waver too! :-) I am leaning towards an independent process/app to handle just the serial comms and exchange that will communicate via some IPC mechanism with my main application. There are some messy aspects no matter how I proceed. - If I leave things as is, I have to live with some long program pauses and because this is a real time sensing and control application, that leads to some less than optimal results at time. On the plus side I keep a straight linear application that is easy to understand and maintain. - If I go with a threaded solution I maintain potential portability to embedded systems that are not unix based and perhaps only support a single process (with multiple threads.) But of course all the pitfalls of threads and long term maintainability apply. And there are many misunderstandings of threads and what they can do. I've seen times that a thread blocking on IO can block the entire application anyway. Certainly a thread that crashes or executes a bad instruction will kill the entire application. - If I go with a separate application, I push myself towards linux based systems only, or systems with advanced kernels that support multiple concurrent processes. There are also so possible messy startup issues to think through (I have to start multiple processes rather than a single process, although one process could launch the other I suppose.) I also have to decide what IPC mechanism to use ... I like the idea of using sockets, partially due to existing available socket communication mechanisms already built into my code and it fits the FIFO nature of my task pretty well. I spew data packets out and I don't care if random packets are dropped or corrupted (as long as an appropriate amount get through for the bandwidth of my serial link.) And the return data is infrequent commands which might be more appropriate as a stream socket connection (which I already have support for in my code.) Best regards, Curt. On Sat, Aug 28, 2010 at 7:23 AM, Roberto Waltman f...@rwaltman.com wrote: Curtis Olson wrote: This is a little off topic, but I don't know where else I can find a stronger knowledge pool. :-) I am working on some code that needs to read and write from a serial port and has to write vast quantities of data ... Curtis, I wouldn't use threads, but a whole separated process. Use circular buffers in shared memory to transfer data, and semaphores to coordinate data transfers in/from these buffers. That way your main process only needs to do non-blocking memory to memory transfers. The serial coms process can handle all the quirks of the protocol, create separate Tx and Rx threads if necessary, decide when to drop data, block itself when needed etc. One of the advantages of using a separate process vs threads in the main application is fault isolation. (1) The unavoidable crashes during development may bring down only this process, allowing you to continue by restarting only this part and not the whole application. The same applies if you want to try a different version. Stop the subprocess, start a new one. Hope this helps, Roberto Waltman. (1) I worked for a company whose coding standards required a manager's waiver to use threads, because of the difficulties of debugging complex multi-thread applications where every thread can corrupt global data. And the fault isolation. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about mp refueling
jean pellotier wrote: currently we can only refuel by mp behing a MOBIL plane, with a plane having the multiplay/tanker set. here's a proposal that permit to use any callsign (yes i know in this case the tanker will not have a tacan working), and any plane, for exemple the tanker pilot can cut the probe/drogue alimentation, or with adding a refueling pod any plane can become a tanker if a c++ guru can have a look and commit (any comment welcome, my c++ skills are just at a beguinner state). the victor is waiting for this (or something similar), with a refuelling available by mp only when the drogue is out . It is already the case that any aircraft can become a tanker simply by using a callsign starting MOBIL. I'm not quite sure what you want here. Would I be correct in saying that you want to be able to switch the tanker status on and off over MP? If so - I think that is a good idea, and one that was intended from the outset, but never got implemented. (I cant remember why - I think it just got lost). If so I'll get on the case. Vivian -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about mp refueling
Le 28/08/2010 20:01, Vivian Meazza a écrit : jean pellotier wrote: currently we can only refuel by mp behing a MOBIL plane, with a plane having the multiplay/tanker set. here's a proposal that permit to use any callsign (yes i know in this case the tanker will not have a tacan working), and any plane, for exemple the tanker pilot can cut the probe/drogue alimentation, or with adding a refueling pod any plane can become a tanker if a c++ guru can have a look and commit (any comment welcome, my c++ skills are just at a beguinner state). the victor is waiting for this (or something similar), with a refuelling available by mp only when the drogue is out . It is already the case that any aircraft can become a tanker simply by using a callsign starting MOBIL by using the callsign MOBIL, we just have a tacan, and are able to be used as tanker only if the plane has multiplay/tanker set to true, so this only works for some planes (victor, c130 and kc135), and to have a working refueling, the tanker pilot must have a MOBIL callsign. I'm not quite sure what you want here. Would I be correct in saying that you want to be able to switch the tanker status on and off over MP? If so - I think that is a good idea, and one that was intended from the outset, but never got implemented. (I cant remember why - I think it just got lost). I want two things: permit a working refueling with whatever callsign you want, even if the tacan can only be used with MOBIL callsigns, and the second is to be able to switch the tanker on/off status while flying, eg if your drogue is not deployed (got the victor ready for this), or if you are low in fuel (for the day the tanker fuel content will be impacted by the refueling). Another concern is that in case we are using a refueling pod, a lots of planes can be used as casual tankers. If so I'll get on the case. if so many thanks. Vivian jano -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] c172p file clean up
Hi all I sent a small merge request to fgdata repo http://gitorious.org/fg/fgdata/merge_requests/38 I was looking to the c172p directories and found some unused files and some wrong paths coming from last commit (?). - effects in models had wrong paths, (re-?)created a folder Effects - removed unused graphic files in top models directory - changed some .rgb-graphic files to .png (-50 % data) I did not change any of the graphics or any other code. It is just a small clean up and I checked the log well after this changes. Feel free to merge in, or not. Thanks, Yves BTW. Meantime I am checking some other 'real' issues of c172p graphics. Can someone tell me why looking to the c172p from the left in helicopter or chase view decrease framerate about -15 fps and from the right nothing at all? Interesting. -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about mp refueling
jean pellotier currently we can only refuel by mp behing a MOBIL plane, with a plane having the multiplay/tanker set. here's a proposal that permit to use any callsign (yes i know in this case the tanker will not have a tacan working), and any plane, for exemple the tanker pilot can cut the probe/drogue alimentation, or with adding a refueling pod any plane can become a tanker if a c++ guru can have a look and commit (any comment welcome, my c++ skills are just at a beguinner state). the victor is waiting for this (or something similar), with a refuelling available by mp only when the drogue is out . It is already the case that any aircraft can become a tanker simply by using a callsign starting MOBIL by using the callsign MOBIL, we just have a tacan, and are able to be used as tanker only if the plane has multiplay/tanker set to true, so this only works for some planes (victor, c130 and kc135), and to have a working refueling, the tanker pilot must have a MOBIL callsign. AFAIKS in the code an aircraft gets a TACAN if the callsign is MOBIL1 (060X), MOBIL2 (061X), or MOBIL3 (062X). On the other hand if the callsign includes MOBIL, it is recognized as a tanker on MP. The property 'isTanker' is not transmitted by default over the net and is not handled on receipt. It is set to 'false' for all mp aircraft, and is only set to true if the callsign contains MOBIL is the first part. The tanker property is used in aar.nas to determine if refueling takes place. Hmm ... this one needs a bit more investigation ... mainly to remind myself what I did in the first place :-). I'm not quite sure what you want here. Would I be correct in saying that you want to be able to switch the tanker status on and off over MP? If so - I think that is a good idea, and one that was intended from the outset, but never got implemented. (I cant remember why - I think it just got lost). I want two things: permit a working refueling with whatever callsign you want, even if the tacan can only be used with MOBIL callsigns, and the second is to be able to switch the tanker on/off status while flying, eg if your drogue is not deployed (got the victor ready for this), or if you are low in fuel (for the day the tanker fuel content will be impacted by the refueling). Another concern is that in case we are using a refueling pod, a lots of planes can be used as casual tankers. If so I'll get on the case. if so many thanks. It will take a little while to research this one. Vivian -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] about mp refueling
Le 28/08/2010 22:49, Vivian Meazza a écrit : AFAIKS in the code an aircraft gets a TACAN if the callsign is MOBIL1 (060X), MOBIL2 (061X), or MOBIL3 (062X). On the other hand if the callsign includes MOBIL, it is recognized as a tanker on MP. The property 'isTanker' is not transmitted by default over the net and is not handled on receipt. It is set to 'false' for all mp aircraft, and is only set to true if the callsign contains MOBIL is the first part. The tanker property is used in aar.nas to determine if refueling takes place. Hmm ... this one needs a bit more investigation ... mainly to remind myself what I did in the first place :-). you're right, and thinks are now more clear to me. in fact the change in the tanker property is taken in account by aar.nas, so exporting it by mp will work. I just wanted not to be forced to use a MOBIL callsign to do refueling by mp, this function should be enabled only by the tanker property. jano -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
