Re: [Flightgear-devel] 2D-Panel for A320
> I started to create a 2D-panel for the A320. > ... > But now i got stuck, because I have 3 questions: Nice work Hans-Georg! It seems to me that the FlightGear developers who have OpenGL experience have lost interest in the 2D panel code some time ago, and their answer to you will be to switch to 3D panels. I prefer the 2D panels, so I'm hoping you know C++ and OpenGL? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
Chris Metzler wrote: Chris, Is there code we can grab to test and look at other areas? Even what you have is okay for a lot of stuff. I like the screenshots. Thanks. Dale With building positions and heights from the FAA Digital Obstruction File, and a few new buriable (thus, height-adjustable) models, here's an approach into La Guardia Rwy 04, starting over Staten Island. http://www.speakeasy.org/~cmetzler/KLGA_04_approach_001.jpg --clip-- Re: frame rates. You can see the frame rates I was getting in the lower-right-hand corner. This is with a Gf4 Ti4600, but at 1600x1200. I did this approach again without the buildings in the scene, and got framerates that were 1-4 fps larger. And Manhattan is a worst-case scenario. So I don't think framerates are going to be much of a problem. -c ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 2D-Panel for A320
Hi all, I started to create a 2D-panel for the A320. First I send this Email to the Users lists, but there I got the hint to send it to the devel-list. Here I am Here is the first shot: http://home.t-online.de/home/wunder.hans-georg/A320-200_31012005.jpg You can download it from : http://home.t-online.de/home/wunder.hans-georg/A320-200_31012005.tar.gz You also need to install the 747, because the A320-modell refers to it. But now i got stuck, because I have 3 questions: - How can I pass a waypoint to the route-manager with Nasal ? (I want to enter the waypoint in the MCDU and pass it via Nasal to the route manager) - How can I display only a part of the speed ribbon ? - How can I improve the fonts ? (I am using Linux. I saw in the afternoon, the the fonts are much better under windows) Thank you for help. PS: Some details of the panel: Open items: Generell: - Bad fonts !!! - No photo-realistic textures - Dokumentation Primary flight display: - speed ribbon - altitude ribbon - speed marker - Vertical speed indictor Navigation display: - Incomplete LS-Mode - No VOR-Mode - No NAV-Mode - ARC-Mode incomplete - No PLAN-Mode EFIS-Control Panel - FCU- Flight Control Unit: - No Speed- and Auto-Throttle - No Course-Mode - No approach control Engine/Warning-Display: - Redesign is necessary - No warnings yet System Display: Only Flight Controls exist, but needs redesign MCDU: Connection between Route-Manager and MCDU and . and and... --- Primary Flight Display: - Autopilot displays Heading, Altitude, Waypoint - Indicated Airspeed, Altitude, --- Navigation Display ILS-Mode: Switch on EFIS-Control-Panel GS = Ground Speed = Heading DME = DME from NAV1, HOLD, NAV-2 NAV1/2-Freq = Switchable between standy and selected adjust direct on the NAV-Display ADF = Switchable between standy and selected adjust direct on the NAV-Display NAV/ADF Switch on EFIS-Control-Panel ARC-Mode: Switch on EFIS-Control-Panel NAV1= Switchable between standy and selected adjust direct on the NAV-Display ADF = Switchable between standy and selected adjust direct on the NAV-Display WPT = Waypoint name and distance - MCDU: Type the value in the scratch pad then transfer the value per Line select key in the corresponding field ON/OF = Switch ON/OFF INIT CO-Route= Company route (can be set) FUEL-PRED FOB CENTER = Fuel on board center tank (can be set) FOB LEFT= Fuel on board left wing (can be set) FOB RIGHT = Fuel on board right wing (can be set) FOB SUM = Fuel on sum CONSUMED= Fuel consumed since fuel set F-PLN Shows the entries of the route manager --- Engine Starter: RUN Indicates, wether the engines runs or not SEL You have to select the engines before you can start or stop it START Starts the engines, the CUTOFF switch has to be set The engine speeds up to 7 % N1, the you have to unset the CUT OFF switch Power Switch: Switches of the power. Not all instruments have a depency on this switch Autopilot: AltitudeWorks more or less Heading Works more or less Kind regards Hans-Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: Dreamcast porting competition]
Dave Martin wrote: > The Dreamcast is RISC based which may be a hurdle but the specs are *really* > low. > > SH-4 RISC CPU @ 206Mhz > 8MB PowerVR2 Graphics > 16MB RAM > 12speed GD-ROM. I think the CPU is not the limiting factor - FlightGear actually 'runs' pretty nice on a 195 MHz MIPS R1 (RISC) CPU as long as the scenery is not too complex. A 300 MHz R12000 (still with 1 MByte 2nd level cache) doesn't make that much difference. Unfortunately the video RAM will not be large enough to store all those textures that you need for a nice scenery, 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] [Fwd: Dreamcast porting competition]
Dave Martin wrote: You been smoking the 'whacky-baccy?' ;-P I prefer the tomacco. The Dreamcast is RISC based which may be a hurdle but the specs are *really* low. SH-4 RISC CPU @ 206Mhz 8MB PowerVR2 Graphics 16MB RAM 12speed GD-ROM. Who knows, perhaps FG would 'run' but I can't see it running 'fast' ;-) I'm just passing this along in case someone else finds it interesting. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: Dreamcast porting competition]
On Tuesday 01 Feb 2005 20:26, Curtis L. Olson wrote: > I suspect a flightgear dreamcast port is outside the realm of > possibility, but I am forwarding this to our developers list in case > someone wants to take a whack at it. It looks like you can get a > dreamcast unit for pretty cheap, and it looks like the development tools > are open source. However, the dreamcast has pretty wimpy specs by > today's standards and I'm not sure the amount of main RAM and video RAM > is even close to big enough to run flightgear without severe > modifications or rearchitecting the code. There appears to be an SDL > port for the dreamcast, but I suspect that there is no opengl available. > > If anyone is interested, feel free to run with this and contact Max > directly for more information. > > Regards, > > Curt. You been smoking the 'whacky-baccy?' ;-P The Dreamcast is RISC based which may be a hurdle but the specs are *really* low. SH-4 RISC CPU @ 206Mhz 8MB PowerVR2 Graphics 16MB RAM 12speed GD-ROM. Who knows, perhaps FG would 'run' but I can't see it running 'fast' ;-) Dave Martin ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [Fwd: Dreamcast porting competition]
I suspect a flightgear dreamcast port is outside the realm of possibility, but I am forwarding this to our developers list in case someone wants to take a whack at it. It looks like you can get a dreamcast unit for pretty cheap, and it looks like the development tools are open source. However, the dreamcast has pretty wimpy specs by today's standards and I'm not sure the amount of main RAM and video RAM is even close to big enough to run flightgear without severe modifications or rearchitecting the code. There appears to be an SDL port for the dreamcast, but I suspect that there is no opengl available. If anyone is interested, feel free to run with this and contact Max directly for more information. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d --- Begin Message --- Hi Curtis! My name is Max Scharl and I'm the C.E.O. of the non-commercial organisation Dreamcast-Scene (www.dreamcast-scene.com) which also has an online database based on the Wiki system. Currently we're in the early stages of preparing a "Dreamcast porting competition". The goal is to port a game (in your case: your game) to the Dreamcast and the best game and porting skills win. The winner receives prices worth approx. US$850 plus the 10 best productions will be added to the professional pressed CD "Dreamcast Demo Disc". 2.000 units will be produced (incl. case and all that stuff) and it's a free (!) giveaway. Okay, my question now is if you and your team is interested in this competition. I'm giving you all that info in advance because it would be a shame if we would set up such a competition and nobody would participate, plus I think your project is a bit more complex and it's worth to give it some extra time. :) If you like some short information about the Dreamcast system: * The Dreamcast is the one and only (!) videogame console which has a free, open source development kit called KallistiOS: http://www.dreamcast-scene.com/index.php/Main/KallistiOS * Beside the normal controller, there's also an official keyboard (like a normal PC keyboard), mouse, broadband adapter and modem available. * Specs: http://www.dreamcast-scene.com/index.php/Main/DreamcastMainSystem (scroll a bit down) * There are SDL libraries for Dreamcast out there: http://sdl-dc.sourceforge.net/#SDL * A Dreamcast system is available for 50 Euros / US$ 40 on eBay.com / eBay.co.uk / etc. If you have any questions left, please mail me. I'm interested in your opinion on this. Best regards, -Max --- End Message --- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Real weather fetch
* Pablo J. -- Wednesday 12 January 2005 01:23: > Regarding real weather processing from live METAR reports, please > consider providing the capability to load the weather conditions from > a file, not only from live stations. > > It may be possible for someone to wish to fly FGFS right now but using > the "actual" weather from some day in the past, and those particular > conditions are available through the respective METAR file. That > capability will allow for example, that someone take-off from his > local airport with the stormy and rainy nigth conditions from four > days ago, just right now that the sun is shinning!! This is now implemented. You just start a METAR proxy server and direct fgfs to it. A sample implementation for such a server is in utils/metarproxy/. See the README file in this dir for details. The protocol for the fgfs<-->proxy interaction is simple. It's pure HTTP with two special headers: fgfs sends such a request (no matter if noaa.gov or the proxy is on the other end): GET http://weather.noaa.gov/pub/data/observations/metar/stations/EGLL.TXT HTTP/1.0 X-Time: 1105534805 and noaa, which doesn't know what to do with an X-Time header and, thus, ignores it, sends the very last METAR string. The proxy knows that X-Time is the POSIX epoch time (seconds since 1970/1/1 00:00) for when the METAR string should be sent. The proxy returns an answer like this: Content-Type: text/plain X-MetarProxy: whatever 2005/01/12 12:50 EGLL 121250Z 25019G30KT SCT032 09/02 Q1020 NOSIG Which is what noaa.gov would send, too, *plus* an X-MetarProxy header, whose contents are currently ignored -- only its existence counts. This header is used in fgfs to determine the reference time for the age calculation: If the info came from such a caching proxy, then the age is (simulated GMT)-(report time). If there's no such header and the information is (likely) from noaa.gov, then the age is (real GMT)-(report time). METAR strings older than 4 hours are currently dismissed. (The proxy server, however, will never really send old METAR strings, but will re-send the last useful METAR information. This is to avoid that fgfs turns off METAR fetching after a series of failures.) Quick instructions to download the world weather for the last 3 hours and run proxy and fgfs with it (2-3 MB download; for less bandwidth consumption see the --record mode): $ metarproxy --download 3h $ metarproxy -v -c & $ fgfs --enable-real-weather-fetch --proxy=localhost:5509 --time-offset=-2 m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
If you have any luck building Atlas on a Mac, please let me know. I have had problems with the automake stuff, and I have not yet managed to get it to compile. -- Adam > From: James Turner <[EMAIL PROTECTED]> > Reply-To: FlightGear developers discussions > Date: Tue, 1 Feb 2005 15:23:50 + > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] Mac os x simgear build break with > RenderTexture.cpp > > > On 1 Feb 2005, at 15:11, Erik Hofman wrote: > >> It is not yet used. I've put the code in CVS in different stages to >> get developers the chance to get things working without being >> overwhelmed with changes. >> >> At least Atlas can use this code to render the maps (accelerated) in >> the background though. > > Ok. I note that Manuel's excellent looking terrain code is using > impostors, and hence will need this too, but also that GL 1.5 has > finally ratified the render buffer object extension, so coding up the > pbuffer stuff will be a temporary measure, with a bit of luck - render > buffers are platform independent. > > Assuming I was to add support, is there a simple test-case? Or do I > need to build Atlas? > > H&H > James > -- > They are laughing with me, not at me. > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
Quoting David Luff : > I have an inkling in the back of my mind that it might also possibly be > useful for drawing impostors for the 3D cloud rendering, but that's just a > wild guess. Mark Harris, who wrote both RenderTexture and 3d clouds, used the framebuffer to do the latter's impostors. But the resulting image has to be copied to the texture memory and this could be avoided by the use of pbuffer. Note that if we are careful to render to texture *before* the initial glClear, we could use this path ( drawing to frame back buffer and then copy image to texture memory ) for systems that will not support pbuffer. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
James Turner wrote: Ok. I note that Manuel's excellent looking terrain code is using impostors, and hence will need this too, but also that GL 1.5 has finally ratified the render buffer object extension, so coding up the pbuffer stuff will be a temporary measure, with a bit of luck - render buffers are platform independent. I'm afraid there will be no support for those extensions for my O2 (or rather any affordable sgi machine). So backward compatibility would be nice. Assuming I was to add support, is there a simple test-case? Or do I need to build Atlas? There is a file called TestRendertexture.cpp in the SimGear/simgear/screen directory that can be used to test it. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
On 01/02/2005 at 11:45 James Turner wrote: > >I'm in the middle of trying to resurrect my FG build (right now it's >dying during startup, oh well), but getting this integrated should be >ok, assuming I can clone the existing WGL / GLX code. > Atlas currently contains a copy of the SimGear render-to-texture code (to avoid depending on SimGear CVS) - you could possibly get this working in Atlas if FG won't start for you - and then it should also work in SimGear/FlightGear. >Question, though : what is FG using render-to-texture *for*? > Atlas is using render-to-texture to avoid image corruption due to overlaid windows, and to allow the creation of images larger than the screen resolution (on some hardware). I don't know what Erik has in mind, but I think that render-to-texture would be useful in FG for procedurally drawing complex 2D images into a texture in real-time (eg. gps unit / glass cockpit display), and then using that to texture a 3D instrument face. I have an inkling in the back of my mind that it might also possibly be useful for drawing impostors for the 3D cloud rendering, but that's just a wild guess. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
James Turner wrote: On 1 Feb 2005, at 10:34, Erik Hofman wrote: I've done some work to make this code at least compile on MacOS. It's obvious I can't really test it myself so any patches needed to get it compiling are accepted. Those who want to implement a real render-to-texture implementation for MacOS might find the following example helpful: http://developer.apple.com/samplecode/Carbon_Pbuffer_Shared/ Carbon_Pbuffer_Shared.html I'm in the middle of trying to resurrect my FG build (right now it's dying during startup, oh well), but getting this integrated should be ok, assuming I can clone the existing WGL / GLX code. Question, though : what is FG using render-to-texture *for*? To draw the instruments in the 3D cockpit. If I've followed the mailing list well enough, it's too costly (or too difficult) to draw the instruments through OpenGL, and easier to draw the instruments to a texture, which is used in the 3D cockpit. Steven ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
On 1 Feb 2005, at 15:11, Erik Hofman wrote: It is not yet used. I've put the code in CVS in different stages to get developers the chance to get things working without being overwhelmed with changes. At least Atlas can use this code to render the maps (accelerated) in the background though. Ok. I note that Manuel's excellent looking terrain code is using impostors, and hence will need this too, but also that GL 1.5 has finally ratified the render buffer object extension, so coding up the pbuffer stuff will be a temporary measure, with a bit of luck - render buffers are platform independent. Assuming I was to add support, is there a simple test-case? Or do I need to build Atlas? H&H James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
James Turner wrote: Question, though : what is FG using render-to-texture *for*? It is not yet used. I've put the code in CVS in different stages to get developers the chance to get things working without being overwhelmed with changes. At least Atlas can use this code to render the maps (accelerated) in the background though. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
On 1 Feb 2005, at 10:34, Erik Hofman wrote: I've done some work to make this code at least compile on MacOS. It's obvious I can't really test it myself so any patches needed to get it compiling are accepted. Those who want to implement a real render-to-texture implementation for MacOS might find the following example helpful: http://developer.apple.com/samplecode/Carbon_Pbuffer_Shared/ Carbon_Pbuffer_Shared.html I'm in the middle of trying to resurrect my FG build (right now it's dying during startup, oh well), but getting this integrated should be ok, assuming I can clone the existing WGL / GLX code. Question, though : what is FG using render-to-texture *for*? H&H James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
Arthur Wiebe wrote: That's what happens when you don't read the whole thing. :) I've done some work to make this code at least compile on MacOS. It's obvious I can't really test it myself so any patches needed to get it compiling are accepted. Those who want to implement a real render-to-texture implementation for MacOS might find the following example helpful: http://developer.apple.com/samplecode/Carbon_Pbuffer_Shared/Carbon_Pbuffer_Shared.html Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
