Re: [Flightgear-devel] Arrays of doubles
On Fri, Apr 09, 2004 at 08:03:49AM -0500, Jon Berndt wrote: class. All I want right now is how do I allocate storage for a 2 dimensional array of doubles, so that I can use the standard accessor operators: myDouble = Data[n][m]; If you insist on the [][] syntax, I'd strongly recommend a std::vector std::vector double . If not, you can use one of the many C++ matrix implementations floating around, for example (shameless plug :-) cpp-lib, which is available from my homepage: http://www.cosy.sbg.ac.at/~gwesp/ Here you can access the elements by Data( n , m ) ( 1 = n = rows , 1 = m = columns ) (Similar to FORTRAN notation). Kind regards, -Gerhard -- Gerhard Wesp o o Tel.: +41 (0) 43 5347636 Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ CH-8045 Zuerich \_/ See homepage for email address! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: FWIW I would be much more excited about this if we were switching to a library designed for highend simulations such as OpenProducer which by the way also has a portable threading library OpenThreads this aims at OpenSceneGraph - doesn't it ? ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Martin Spott Sent: Wednesday, April 14, 2004 8:11 AM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] SDL early access implementation Norman Vine wrote: FWIW I would be much more excited about this if we were switching to a library designed for highend simulations such as OpenProducer which by the way also has a portable threading library OpenThreads this aims at OpenSceneGraph - doesn't it ? ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] SDL early access implementation
Martin Spott writes: Norman Vine wrote: FWIW I would be much more excited about this if we were switching to a library designed for highend simulations such as OpenProducer which by the way also has a portable threading library OpenThreads this aims at OpenSceneGraph - doesn't it ? ;-) OpenProducer was written to support OpenSceneGraph but, it doesn't need OpenSceneGraph and more importantly it was designed to be used in 'multi-pipe' OpenGL systems as well as more conventional OpenGL configurations from the ground up. OpenProducer also takes a minimalist approach which I find attractive compared to 'full featured' libraries. One can think of it has a Direct Layer for OpenGL only and it doesn't concern itself with anything else. One thing I would like todo is use DirectX rather then the normal WIN32 API for the event loop but what is there works well enough and was a lot less work when porting from the original 'X' based code. FYI I have been doing some work on a global LOD based scenery engine that happens to currently be based on OpenSceneGraph Lot of work todo yet and I want to move this into SSG, but, I finally have the basics working http://cooa.whoi.edu/~nhv/images/test1.jpg note the texture used in the above is elevation but orthophotos or satelite imagery works as well Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
Norman Vine wrote: OpenProducer was written to support OpenSceneGraph but, it doesn't need OpenSceneGraph and more importantly it was designed to be used in 'multi-pipe' OpenGL systems as well as more conventional OpenGL configurations from the ground up. STLport, OpenThreads, OpenProducer, OpenSceneGraph, OpenAL they all convey the idea of a foresighted design concept and look like they they would be the first choice for FlightGear !? Is Norman the only advocate for this approach ? Just investigating, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 3d panel visible externally. Why?
I have a problem with the 3d panel. It is visible in the external views through the objects of the 3d model. Is there anyone who can help me? Thanks a lot Marco ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] 3d panel visible externally. Why?
Marco asked Sent: 14 April 2004 15:40 To: [EMAIL PROTECTED] Subject: [Flightgear-devel] 3d panel visible externally. Why? I have a problem with the 3d panel. It is visible in the external views through the objects of the 3d model. Is there anyone who can help me? Thanks a lot Marco Look in the Hunter or p51d model files to see how it can be done. Regards Vivian Meazza ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Fixing the --waypoint and --flight-plan comman line options
Hey Folks, After my recent crash tests last weekend, I feel a need to be able to do this in a more controlled way. Therefore, I'd like to fix the --wp and --flight-plan options. It appears that these are broken, because the airport and route manager subsystems are not yet initialized when the config file and command line is parsed. So a possible, yet somewhat inelegant, workaround would be to push all the waypoints into a vector of strings, and parse these later, after the airport and route manager have been initialized. Any thoughts, objections? Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3d panel visible externally. Why?
marco.gugel said: I have a problem with the 3d panel. It is visible in the external views through the objects of the 3d model. Is there anyone who can help me? Thanks a lot Marco Some models need to have a range selector added for that. You probalby won't see that if you run a 16bit depth buffer with your graphics card. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL early access implementation
On Wed, 14 Apr 2004 09:11:08 -0400, Norman wrote in message [EMAIL PROTECTED]: One thing I would like todo is use DirectX ..this too is Microsoft's IP, no? rather then the normal WIN32 API for the event loop but what is there works well enough and was a lot less work when porting from the original 'X' based code. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Fixing the --waypoint and --flight-plan comman line options
Well, since nobody objected... :-) I have a patch for this that appears to be working on my system. I want to do do a little more testing/cleaning up, so I can probably release it by tomorrow or so. Who would like to commit this to cvs? In which form? diffs or whole files? Cheers :-), Durk On Wednesday 14 April 2004 19:21, Durk Talsma wrote: Hey Folks, After my recent crash tests last weekend, I feel a need to be able to do this in a more controlled way. Therefore, I'd like to fix the --wp and --flight-plan options. It appears that these are broken, because the airport and route manager subsystems are not yet initialized when the config file and command line is parsed. So a possible, yet somewhat inelegant, workaround would be to push all the waypoints into a vector of strings, and parse these later, after the airport and route manager have been initialized. Any thoughts, objections? Cheers, Durk ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-users] FlightGear's 747-400 bugs?
Durk Talsma wrote: I assumed that your latest yasim fuel code had a lot to do with this, which would explain why the cvs 747 is performing so much better (i.e. longer) Heh, that's because I cleverly introduced a units bug (kgs/lbs) in the process. :) It's fixed now, so the 747 should be a short range pig again. Give it a try, and see if it matches the old performance (it should, the new fuel stuff is more flexible, but should produce the same results). Then we can try playing with the TSFC to make things right. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
