Re: [Flightgear-devel] Problem with sounds...
Jim Wilson wrote: Found the problem and here's the fix. Type once sounds were never getting stopped. Description of patch: Minor patch. Basically just moved a line of code that was causing a check for when sound should be stopped to be skipped. Now type once sounds get stopped when they should. Which means they'll now play when needed a second time. Yep, that's correct. In an attempt to get out of the update() function as quick as possible I've changed this in a previous patch, but a patch I sent to David this week already corrected that. I'm still in the middle of implementing a bunch of other stuff to have more controll over the starting/stopping of the sounds using the XML configuration, so there are some things which should be addressed in the near future (rumble only plays when the nose gear touches the ground for instance). Thanks anyway Jim. This file contains a patched fg_sounds.cxx file: http://www.spiderbark.com/fgfs/fg_sound-patch-20020309.tar.gz Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Cockpit panel_io.cxx,1.33,1.34
Bernie Bright wrote:
Curtis L. Olson wrote:
Update of /var/cvs/FlightGear-0.7/FlightGear/src/Cockpit
In directory seneca:/tmp/cvs-serv20681
Modified Files:
panel_io.cxx
Log Message:
Sgi doesn't define the != operator for string != char[] so we need to cast
the char array into a (string) type before doing the comparison.
! if (mbgTexture != (string)) {
A better test for non-empty strings is
if (!mbgTexture.empty())
This is portable and faster than a string compare.
There are a lot (and I mean a lot) of places where a string comparrison
is made (either == or != ). It might be a good thing to change that
then?
Erik
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
I agree, full 3D is the way new sims work and FGFS should have that as well and not implement now a feature that was state of the art some years ago. It is easy to make the yoke optional. While modelling the cockpit I would strive for realism and then let FGFS disable it if the user wants. There may be small artistic freedoms to make things more legible, for example shadows on gauges that partly and non-uniformly shadow digits on gauge faces can make it more realistic and pretty, but harder to read. Also, if in reality there is much space between gauges, you can increase the size of the gauges. I also love a fully 3D, fully functional, fully clickable cockpit. But it is a lot of work, more than exteriour models. Also, an artist can make an exteriour model without help from a coder. If an aritist does a 3D cockpit that holds a switch or gauge or whatever that has not been coded before, he needs the help of a coder. It should off course be possible to change the view direction. I have heard (IIRC from warbirds or Aces High users) that a very nice effect is if the eyepoint moves at the same time. If you sit and look in another direction, turning your head, the eyes move since you will probably hold your neck fairly constant. Also, it should be possible to move the eyepoint via keys so that you can look around things. This may go so far that you can open the canopy and stick your head out to look besides the large obstructing engine. If this is realistic (this technique is used for some planes in RL), then users appreciate this effect a lot. Also, g forces should move the eyepoint as an option (some people like me like this, some don't). AFAIK, this is already in the code. Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
This sounds ideal! I vote that you submit it! :-) What are the code dependencies? SimGear? Jon I have a stand-alone real-time and off-line plotting tool written in C/C++ (tested in Cygwin/WinNT/Win2K Linux) that is meant to be used as a flight test engineer's station. It has just been completed and it works, but I am yet to put it to serious use. The code is designed to run a separate PC and recieve data via network from the FDM and the plots are configurable via xml. Offline plots have zoom facility, scales (x/y ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Hi, I have a stand-alone real-time and off-line plotting tool written in C/C++ (tested in Cygwin/WinNT/Win2K Linux) that is meant to be used as a flight test engineer's station. [...] That does sound useful. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Wolfram Kuss [EMAIL PROTECTED] said: I agree, full 3D is the way new sims work and FGFS should have that as well and not implement now a feature that was state of the art some years ago. Fly! is a 3D cockpit. I was talking about usability, and IMHO it is a more usable panel because of its inaccurate eye point when in use. Just as the panel disappears when you use the mouse scrolling and reappears with a click, it'd be easy enough to snap to an operational centered viewpoint. There may be small artistic freedoms to make things more legible, for example shadows on gauges that partly and non-uniformly shadow digits on gauge faces can make it more realistic and pretty, but harder to read. Also, if in reality there is much space between gauges, you can increase the size of the gauges. Yes, unfortunately reality occurs in much higer resolution than even the best monitor can deliver. How about when the sun is right in your eyes and you can't see anything, even with sunglasses? It amazes me sometimes that people define reality in 3D as being something that looks like it was done with a video camera. To me its a more realistic experience if the gauge I'm looking at can easily be used and is closer to what it would be in size and perspective from my eyes sitting in the chair, not the camera's little box on the screen. I also love a fully 3D, fully functional, fully clickable cockpit. But it is a lot of work, more than exteriour models. Also, an artist can make an exteriour model without help from a coder. If an aritist does a 3D cockpit that holds a switch or gauge or whatever that has not been coded before, he needs the help of a coder. Yeah they are pretty cool, but for me once you've got them figured out (solved the puzzle and repeated it a few times) it's pretty dull. When I first got Fly! a couple years ago I used it a lot for a few months. Now I just dig it out when I'm interested in how the developers might have done something. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
It amazes me sometimes that people define reality in 3D as being something that looks like it was done with a video camera. To me its a more realistic experience if the gauge I'm looking at can easily be used and is closer to what it would be in size and perspective from my eyes sitting in the chair, not the camera's little box on the screen. Any simulator should have as it primary function SIMULATING as closely as possable the real thing. This applies to both the flight model and the controls and instruments. The fact that most folks only have a single monitor complicates this greatly. The fact that most folks have controls that do not have the proper sizes and forces complictes this. The best way for a simulator (such as FlightGear) to approach this is to give the users the ability to add and interface with such programs at the project magenta instruments, or the glass cockpit being worked on by John and others. The ability to open and close additional views for operating controls (such as FLY and PS-1 do) is needed as well, for those who have to rely on a single monitor. The photorealistic instruments in some simulators are good to have, but (IMHO) not as importaint as proper flight modeling. I personally see NO need for the nice views of the airplane, and its moving parts as seen from other airplanes except if one is flying formation or shooting at the airplane. While this is nice to have for some limited purpose, it adds nothing to the realism of the simulator from the perspective of the person flying the sim. These efforts could better be used in improving the flight models, and the functionality of the sim to interface to other sims and external programs and more realistic views (such as those for KSJC). jj ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim Brennan jjb - writes: The photorealistic instruments in some simulators are good to have, but (IMHO) not as importaint as proper flight modeling. I personally see NO need for the nice views of the airplane, and its moving parts as seen from other airplanes except if one is flying formation or shooting at the airplane. ... or replaying a finished flight to study it, or watching a student's progress in external view on a second monitor, or watching the propeller from inside the airplane. More importantly, I think that soon we won't be making the same distinction between internal and external view -- we might even use the same 3D model for both. In that case, the same animation code that spins the propeller can move the yoke, throttle levers, rudder pedals, etc. (I imagine that needles on gauges will still be done with rotating textures). While this is nice to have for some limited purpose, it adds nothing to the realism of the simulator from the perspective of the person flying the sim. No, but it might be useful for the instructor to watch, or for the student during a replay of a failed flight. These efforts could better be used in improving the flight models, and the functionality of the sim to interface to other sims and external programs and more realistic views (such as those for KSJC). It's not a zero-sum game. The people who are good at flight models (Jon, Tony, Andy, etc.) are already spending pretty-much all their time on flight modelling; contributions to other areas from other people aren't taking away from that. All the best, David -- David Megginson [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim wrote: While this is nice to have for some limited purpose, it adds nothing to the realism of the simulator from the perspective of the person flying the sim. I think more people use flight sims for fun or entertainment than for serious uses. Including me, although I am a pilot. But lets stop this discussion and agree that whether you find good exteriour 3D models fun is a matter of taste (additional to the serious uses David wrote about). jj Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual cockpit notes
Jim wrote: Fly! is a 3D cockpit. I was talking about usability, and IMHO it is a more usable panel because of its inaccurate eye point when in use. Just as the panel disappears when you use the mouse scrolling and reappears with a click, it'd be easy enough to snap to an operational centered viewpoint. In 3D, its easy to let the user move the eyepoint. It amazes me sometimes that people define reality in 3D as being something that looks like it was done with a video camera. To me its a more realistic experience if the gauge I'm looking at can easily be used I agree. Strangely enough, just a few days ago I had the same discussion on a forum and said what you say, legibility is more important than just good looks. They had smudges on the faces, different varieties of shadows, aging effects (white - yellow) etc. My only fear is - maybe I am missunderstanding - that we will implement some scheme that was state of the art 5 years ago when someone started work on a sim that was shipped 2 years later. As long as we don't close doors to future development by choosing the wrong scheme or waste time by doing several schemes, I am happy :-). IMHO the decision for a 3D cockpit is not a decision for bad legibility. Worse than a pure 2D cockpit, hand optimized for the resolution, yes, but not bad. and is closer to what it would be in size and perspective from my eyes sitting in the chair, not the camera's little box on the screen. In a 3D cockpit, this can be chosen via FoV. Actually, when I start a plane and click all the things in the cockpit, I reduce FoV a bit (zoom in, move my nose closer to the panel). OTOH, when I land, I zoom out very much to see the horizon left and right to judge my angle etc. Best, Jim Bye bye, Wolfram. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Rationalizing view
David Megginson [EMAIL PROTECTED] said: As far as I can figure out, there are only three situations we need to deal with in the viewer code: 1. Looking away from a known position. 2. Looking towards a known position from a known distance and angle(s). 3. Looking from one known position towards another. All of the views can still be managed by the view-manager class (a proper subsystem), but we should try to remove all hard-coded dependencies from the rest of the FlightGear codebase. For example, the scenery code doesn't need to know which view is in use; it only needs to know where the coordinates and VIEW matrix for the camera. Comments? Volunteers? I think that the easiest solution is probably a clean rewrite, but paying close attention to how Norm used the matrices and vectors in the original. This sounds interesting. Let me think about it for a bit and come back with sample properties in xml format. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
OK. I will do so on Monday (11th March). Do you want me to integrate it into SimGear so that its offline plotting function could be used by people who work with one PC and the stand-alone executable could be used by those who have more than one PC.? Or Should I just send the stand-alone code to Curt?. As a first step I will just integrate it as is, test it with our FDM (for real-time) and our ascii format data file (for off-line) and send it to Curt. Once I recieve suggestions from you I could get it to work with other FDMs of FlightGear. Regards Ranga --- Jon Berndt [EMAIL PROTECTED] wrote: This sounds ideal! I vote that you submit it! :-) What are the code dependencies? SimGear? Jon I have a stand-alone real-time and off-line plotting tool written in C/C++ (tested in Cygwin/WinNT/Win2K Linux) that is meant to be used as a flight test engineer's station. It has just been completed and it works, but I am yet to put it to serious use. The code is designed to run a separate PC and recieve data via network from the FDM and the plots are configurable via xml. Offline plots have zoom facility, scales (x/y ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] idea ... (?)
Fine. I will send it first thing on Monday to Curt alongwith a sample ascii format data file to help you see what it does. We have also put together a short 'instructions for use' and that may be of some help in understanding how it works. Regards Ranga --- Alex Perry [EMAIL PROTECTED] wrote: I suggest that you submit it mostly as-is and have Curt place it into CVS so we can all see how it's implemented ... that way we will have a basis to give you realistic answers to those questions (instead of guessing). OK. I will do so on Monday (11th March). Do you want me to integrate it into SimGear so that its offline plotting function could be used by people who work with one PC and the stand-alone executable could be used by those who have more than one PC.? Or Should I just send the stand-alone code to Curt?. As a first step I will just integrate it as is, test it with our FDM (for real-time) and our ascii format data file (for off-line) and send it to Curt. Once I recieve suggestions from you I could get it to work with other FDMs of FlightGear. Regards Ranga --- Jon Berndt [EMAIL PROTECTED] wrote: This sounds ideal! I vote that you submit it! :-) What are the code dependencies? SimGear? Jon I have a stand-alone real-time and off-line plotting tool written in C/C++ (tested in Cygwin/WinNT/Win2K Linux) that is meant to be used as a flight test engineer's station. It has just been completed and it works, but I am yet to put it to serious use. The code is designed to run a separate PC and recieve data via network from the FDM and the plots are configurable via xml. Offline plots have zoom facility, scales (x/y ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ 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 __ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
