[Flightgear-devel] FGInterface initialisation bug
Hello,
wondering why my A4 stay steady on the ground with gear retracted, I
made a little debug session to find that 'remaining' value in
FGInterface::_calc_multiloop had a very huge value (about 1e+66)
that result in 0 iterations made by the FDM.
Applying the patch below solve the problem.
Cheers,
-Fred
C:\FlightGear\cvs\FlightGear\src\FDMcvs -nq diff -u flight.cxx
Index: flight.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/FDM/flight.cxx,v
retrieving revision 1.60
diff -u -r1.60 flight.cxx
--- flight.cxx 17 May 2002 15:25:28 - 1.60
+++ flight.cxx 25 Jun 2002 06:28:49 -
@@ -53,6 +53,7 @@
// Constructor
FGInterface::FGInterface() {
_setup();
+remainder = 0;
}
FGInterface::FGInterface( double dt ) {
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Multiplayer Engine project started
The first important decision now is, do we multi-threading or multiplexing-IO ? For multiplexing, PLIB can be used. For multi-threading, we got a problem. Another issue is how to get the code to compile on other platforms, because threading and sockets aren't 100% portable, to say the least. PLIB's socket library is reasonably portable. It runs on every platform that FlightGear runs on. There are many portable open source threading libraries available, Boost.Thread, ZThread and CommonC++ to mention just a few. Bernie Another issue here is performance/stability. Threading gives best performance(and most problems) with multiple processors. With a single processor the overhead might not measure up against performance. I don't have such an archictecture so bugs might not surface at my platform. Our first prototype will use multiplexing I/O, if it can handle 10+ users at once then we might stick with it. If it can't handle at least 10 users we will probably switch to threading. This should not effect clients since we will be using Flight Gears own scheduler for that. There might be a parameter to expect X packets per second spreaded of the second to minimize network overhead (like 10 for the 56k modem users, network users can turn this value to 100 or over). I don't know if we will be using ratios (56k modems have 33k6 up and +/- 45k down(on bad lines). I personally got 256k up and 512k down (in kilobit/sec) so there might be a ratio involved. __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Capturing warnings
On Tuesday, June 25, 2002, at 01:31 am, Andy Ross wrote: Jonathan Polley wrote: I cannot redirect stderr via 'command 2 file' on my Mac, so the easy solution was out. I did find that the following command works: Rubbish. Sure you can. You just have to run a real shell. :) Seriously, I'd be shocked beyond measure if bash didn't build and install just fine on OS X. Use it, it's vastly better than csh. Actually, it's even easier. Install Fink, and select the bash package. Oh, and change your shell selection from 'csh' to /sw/bin/bash in Terminal.app 's preferences. The idea that anyone doing development under OS-X would *not* have Fink installed doesn't bear thinking about :-) [note for non-mac people: Fink is a Unix ports tree for OS-X, which uses apt / dselect as the packaging and distribution system] Goodbye csh! Rumor has it that Apple desperately wants to switch to bash as the default shell for 10.2, it seems very few people out there enjoy using csh :-) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGInterface initialisation bug
wondering why my A4 stay steady on the ground with gear retracted, [...] Ah, we already had this 'feature' last week. This appears to depend on Adrew's panel updates. Thanks for the fix, 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] Multiplayer Engine project started
If you want good performance I'd suggest looking at the state-threading library which was designed especially for this kind of daemons: http://state-threads.sourceforge.net/ Erik I've reviewed this library and it looks good. If our first prototype fails we will consider this one. We intent to build modulair, so we can always switch system, as long as it supports UDP. Hi, i am really new to the list, and the last message is my first received message. For concurrency, i use the Ace[1] framework which have an interessant pattern, the active object[2]. Ace provide also a lot of networked oriented features Stephane [1]: http://www.cs.wustl.edu/~schmidt/ACE.html [2]: http://www.cs.wustl.edu/~schmidt/ACE-overview.html Look at the patern link (http://www.cs.wustl.edu/~schmidt/patterns-ace.html;) and see the amount of 'locking' has to be done, thats a constant and expensive overhead. So ACE is NOT a option. Its depends on threading too much, which will give a big overhead because we use a lot of shared storage (about 80% of used storage memory will be shared). Our planned prototype model will be Event-Driven State Machine Architecture (see http://state-threads.sourceforge.net/docs/st.html; paragraph 2.3), which should suffice. All the best, Leon __ Do You Yahoo!? Yahoo! - Official partner of 2002 FIFA World Cup http://fifaworldcup.yahoo.com ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Multiplayer Engine project started
ace project writes: The first important decision now is, do we multi-threading or multiplexing-IO ? For multiplexing, PLIB can be used. For multi-threading, we got a problem. Another issue is how to get the code to compile on other platforms, because threading and sockets aren't 100% portable, to say the least. PLIB's socket library is reasonably portable. It runs on every platform that FlightGear runs on. There are many portable open source threading libraries available, Boost.Thread, ZThread and CommonC++ to mention just a few. Bernie Another issue here is performance/stability. Threading gives best performance(and most problems) with multiple processors. With a single processor the overhead might not measure up against performance. I don't have such an archictecture so bugs might not surface at my platform. I think you will find that the PLib 'multiplexing' code a good 'base' in that it is patterned after a high-performance mechanism. http://www.nightmare.com/medusa/medusa.html which has 'proven' itself to be fast enough for real work even when written in Python. ie Zope http://www.zope.org Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Glut font format
Andy Ross writes:Glut font format Norman Vine wrote: Here's Mark's example of the command used to generate the sorority.txf file: Just change the Font name and the 'glist' to be what you want gentexfont \ -fn '-sgi-sorority-medium-r-normal--40-*-*-*-p-*--ascii' \ Right, but this only gets you a copy of the X11 bitmap font, which is ugly and aliased. My original point was that with only a little work, you could use ghostscript/FreeType to render a very high (16x) resolution bitmap of each character and downsample to get a very nicely antialiased texture to use with the font. Which would be great, except for the fact that there are no tools available to do this, nor documentation to write such tools. I think that you will find that inorder to get 'high quality' fonts one needs to use a vector based font directly. The only problem in doing this is that the polygon count goes up considerably. That said I have been working getting http://oglft.sourceforge.net incorporated into PLib. No promises as to when I will finish this up however Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Glut font format
Have you tried using the Font generator http://www.opengl.org/developers/code/mjktips/TexFont/gentexfont.c I have used this successfully with Cygwin and is in how ALL of the PLib fonts were created. I assume that this was Cygwin witn XFree86? Thanks, Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A-4C attitude indicator
Andy Ross [EMAIL PROTECTED] said: This looks fantastic. I think this may be the first working gyro ball in a PC simulator cockpit. At least, I haven't seen one anywhere else. :) Thanks! On question, unrelated to the ball actually, is exactly what we're trying to simulate. You seem to be aiming at an A-4C cockpit, but the aero model is for an A-4E which has a bigger engine. The 3D model claims to be a C, but it's dolled up in Blue Angels paint, and they flew the A-4F. Note the fine print ;-): http://www.blueangels.org/Aircraft/Stick/A4/ProudBird/ProBird.htm To nit further: the slats are down, but the Blue That'd be easy to do :-)...was planning to animate them. Angels planes had their slats bolted shut*. And the refueling probe is the cranked shape that wasn't introduced until the A-4M. :) Well I'm baffled. Take a look at this page: http://www.skyhawk.org/2D/blues.htm This page confirms that the A4-F was used, however none of the pictures looks like the F with the extended hump for electronics. On the other hand this couldn't really be a C either. Must be in between. In any case these photos seem to confirm the accuracy of model. Given the time frame in which the aircraft were built, I'd suggest we should leave the geometry alone and power it with the A4-F engines. * For safety. The A-4 had automatic slats that were retracted by aerodynamic force -- they dropped automatically at low airspeeds and high AoA's. On the ground, they just hung open. This was a great idea for maintenance purposes, but left open the possibility that they might get stuck and deploy asymmetrically. That's a recoverable situation normally, but not when there's another plane a few feet under or above your wing tip. :) Ah ok. If we modeled that, where would do it, in the FDM? 1) The flags. There are four of them in the photos I've seen but so far I haven't found any information on which is which. One has the word Off on it, and I assume that it means the entire assembly is unpowered. I'm clueless here. Obvious warning flags for the instrument would be the same as for a normal AI or HSI -- vacuum failure (or maybe electrical failure or low gyro RPM), lack of radio signal (VOR/TACAN/LOC/GS). Wild ass guesses: 8 o'clock flag, power to instrument. 9 o'clock flag, gs signal. 12 o'clock roll gyro failure (off). 3 o'clock pitch gyro failure (off). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Glut font format
Norman Vine wrote: I think that you will find that inorder to get 'high quality' fonts one needs to use a vector based font directly. The only problem in doing this is that the polygon count goes up considerably. Have you tried the antialiased fonts in KDE, WinXP or recent versions of Gtk+? They look *fantastic*, and are generated with exactly the method I propose -- a very high resolution bitmap is generated and then downsampled into a grayscale image that is alpha composited onto the screen. The plib TXF loader already does the second part, there simply aren't any tools to do the rendering and downsampling. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
