[Flightgear-devel] Modular / portable cockpit design

2005-12-02 Thread James Turner
On 2 Dec 2005, at 00:32, John Wojnaroski wrote:Just a question of time and energy.  The design issue is how to keep it portable so we can haul the gear around to shows like Scale4x coming up in Feb 06. Same problem with putting everything into a shell,  fantastic for a fixed installation but kind of like the old story of the fellow who builds the 30 foot sailboat in his cellar I would talk to some exhibition set / theatre set people if you can (I am slightly involved in the tech side of an amateur theatre company) - generally such people have to produce stuff which is pretty cheap, pretty durable and which can be transported, assembled and taken apart pretty fast without lots of support equipment.As far as I can tell (I haven't worked on set myself), a lot of it comes down the finding sufficiently fancy pins / hinges / bolts / locks that you can have everything be modular (eg, the pedestal, main panel, glare shield), but still be rock solid when it's all set into place. Experience is a big factor in that...James -- That which does not kill me has poor aim  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Request to the Mac folk

2005-11-25 Thread James Turner
On 25 Nov 2005, at 00:33, David Luff wrote:Thanks, that's great!  Would you prefer me to upload it to SourceForge for download from there, or to simply provide a link to your webspace?There's no problem with leaving it in my webspace, but you may as well add it to SF -that way you get SF's download stats and so on. No problem.  I don't really know much about Mac versions.  Am I right in thinking that Tiger is the latest one?  Does one have to pay to upgrade from one version to another? Tiger is the latest, upgrading from any previous versions costs in the region of £90 / $110 I think. As I said, producing a panther build should be doable by someone with Panther, or if you get many complaints, I can set up a cross-build environment to target Panther myself; I'm just being lazy on the assumption flight sim users are probably early-ish adopters and already have Tiger...HHJames -- Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Request to the Mac folk

2005-11-23 Thread James Turner
On 23 Nov 2005, at 20:44, David Luff wrote:Disregard this, using the current X-Plane data everything works. It's   my fault for not reading the instructions. Will test some more (and,   err, get some sleep) and post a link to a .dmg once I verify what   happens on Panther.  Thanks, I'm looking forward to it :-)  I'll probably ditch support for the old FG data format in the next version - should reduce the potential for confusion. Okay, a DMG is available from my .Mac account:	http://homepage.mac.com/zakalawe/.Public/taxidraw-0.3.2.dmgThis only works on Tiger; the problem (or at least the first one) is that Tiger ships with libcurl-3, wheras Panther only includes libcurl-2. I suspect a build from source on Panther would produce something that works just fine, and I've said as much in the readme file. If this is a big problem, I can setup my build environment to target Panther and rebuild wxMac + taxiDraw, it's just a bit complex so I will hold off for now.Hope this helps some people out,James -- There is a very fine line between 'hobby' and 'mental illness'  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Request to the Mac folk

2005-11-22 Thread James Turner
On 22 Nov 2005, at 23:50, David Luff wrote:Are there any Mac developers here who might be able to make up a Mac package of TaxiDraw v0.32 for me?  The last version was done an X-Plane user, but there is no Mac binary available for the current version, and the Mac is popular among X-Plane users.    TaxiDraw source can be found at http://taxidraw.sf.net  There should be very few code tweaks needed (I *think* I got most of the patches required for the last version into the code), but a non-unicode version of wxWidgets is needed for compilation (the next version of TaxiDraw should be unicode-safe). I built a binary that ran last year, haven't tried in ages - the issue is getting everything required linked statically, I think. I shall experiment, but don't let that stop any other Mac people having a go.HHJames___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Request to the Mac folk

2005-11-22 Thread James Turner
On 22 Nov 2005, at 23:17, James Turner wrote:I built a binary that ran last year, haven't tried in ages - the issue is getting everything required linked statically, I think. I shall experiment, but don't let that stop any other Mac people having a go.Okay, so building it was pretty painless (mostly because wxMac almost works out of the box these days; I had to create a few symlinks to get it to link, but anyway). I have a static taxidraw binary, which should work on Tiger (10.4), but probably not on anything earlier, I'll try Panther at work tomorrow.And now the bad news - when I point TD at my (CVS) apt.dat (unzipped), and do 'New...', I enter an ICAO code (say, EGPH), and crash. The crash is consistent at line 48 of fgfsIO.cpp: looking at the code it seems like a string-pointer issue. Is this a Mac-specific problem? I can dig deeper, but some guidance would be good.Alternatively, I can just upload what I have someplace and people can try - perhaps X-Plane data files would work.HHJames -- Morbo finds all humans pathetic  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Request to the Mac folk

2005-11-22 Thread James Turner
On 23 Nov 2005, at 00:23, James Turner wrote:And now the bad news - when I point TD at my (CVS) apt.dat (unzipped), and do 'New...', I enter an ICAO code (say, EGPH), and crash. The crash is consistent at line 48 of fgfsIO.cpp: looking at the code it seems like a string-pointer issue. Is this a Mac-specific problem? I can dig deeper, but some guidance would be good.Alternatively, I can just upload what I have someplace and people can try - perhaps X-Plane data files would work.Disregard this, using the current X-Plane data everything works. It's my fault for not reading the instructions. Will test some more (and, err, get some sleep) and post a link to a .dmg once I verify what happens on Panther.BTW, David, you should really investigate using a config.h - your compile lines are, uh, rather long :)HHJames -- There is a very fine line between 'hobby' and 'mental illness'  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] RenderTexture::BeginCapture(): Texture isnotinitialized!

2005-11-19 Thread James Turner
On 19 Nov 2005, at 01:49, Arthur Wiebe wrote:I have found the problem. My Xcode projects seem to be buggy. The PLIB project is fine but something is wrong with the SimGear project.  I just built using the autoconf system and everything worked fine. It even fixed my spash screen problem! :) I'll try to have it fixed by tomorrow afternoon if possible. I'll experiment as well - I had some strange issues earlier in the year building FG with my own X-Code projects; I was being more ambitious, and building PLIB and SimGear as frameworks, but on reflection that's not such a great idea. One change I have made is to use a 'copy files' stage for your Prepare files; otherwise they always touch config.h / version.h, and that tirggers a dependant rebuild of many files for me. The Copy Files stage has the right 'only re-copy if src mod time is more recent than existing destination' logic.HHJames -- Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] RenderTexture::BeginCapture(): Texture is not initialized!

2005-11-18 Thread James Turner
On 18 Nov 2005, at 20:08, Arthur Wiebe wrote:When running fgfs 0.9.9 I get this output:  opening file: /Users/arthur/Projects/FlightGearOSX/data//Navaids/carrier_nav.dat /Users/arthur/Projects/FlightGearOSX/data//Navaids/TACAN_freq.dat RenderTexture::BeginCapture(): Texture is not initialized! /Users/arthur/Projects/FlightGear/../SimGear/SimGear/simgear/threads/SGThread.hxx:233: failed assertion `status == 0' Abort trap  At first if failed right after this line: /Users/arthur/Projects/FlightGearOSX/data//Navaids/TACAN_freq.dat  But then I uncompressed TACAN_freq.dat.gz and carrier_nav.dat.gz and got past that. And now it aborts with RenderTexture.  As long as things go like this there'll be no Mac release anytime soon. I built from CVS last night (using Arthur's XCode projects, I've got 2.2), and hit this problem. I assumed it was a local config problem, but from Arthur's description it is something that broke very recently  hmm. The obvious reason for this to fail would be a corrupted / un-inited SGMutex; I am going to add some logging and check.Arthur / Ima / Anyone - can you confirm the latest CVS versions of SimGear / FlightGear that worked?James -- All hail the hypno-toad!  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Mac thread woes.

2005-11-18 Thread James Turner
On 18 Nov 2005, at 22:18, Adam Dershowitz wrote:But then it continues to load and run.  So I think that the error may be a red herring, and not the cause of the abort that you are seeing. The RenderTexture error is a red-herring, for certain, and by instrumenting SGThread I've found at least two trigger points - one in SGMutex, and another in SGPthreadCond. In both cases the pthread function is returning EINVAL, even though the object at the address has been created (I've instrument the mutex create/destory paths too).So, it's weird - perhaps something is trampling some memory structures? Hmmmph.James -- There is no such thing as a humble opinion.  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] XCode project files

2005-11-14 Thread James Turner
On 12 Nov 2005, at 14:30, Arthur Wiebe wrote:I've been using Xcode 2.2 for some time now building Flightgear and everything else. Preview builds until now of course.By the way Xcode projects you can use to build PLIB, Simgear, and FlightGear are available now. I've polished them up so they should be ready. If you're interested I'll commit them to the macflightgear cvs.Please do commit them, I've had hand-rolled projects for all three for some time, but they're out of sync. If I find any issues, I'll let you know.James -- You whine like a mule. You are still alive!  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] diff for browser change for mac os x to use safari

2005-11-11 Thread James Turner
On 12 Nov 2005, at 00:58, Ima Sudonim wrote:With this change, FlightGear on Mac OS X launches the mac os x Safari browser instead of netscape (w/o this change, the browser won't launch without netscape installed, and netscape isn't one of the installed mac os x browsers). This approach seems silly - I've got Core Foundation code to launch a URL string via LaunchServices - using whatever browser the user has selected in the system. Hard-coding a browser is always going to annoy people.I'll post the patch once I dig out the code.HHJames___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Which aircraft to include in v0.9.9?

2005-11-10 Thread James Turner
On 9 Nov 2005, at 19:31, Curtis L. Olson wrote:I reserve the right to make the final determination (and all non-included aircraft will still always be available for separate download from the web site ...)  Given that new aircraft have arrived on the scene since the last release, do we want to make any changes to the list of default aircraft included in the base package?  The rule generally is that if we add one, we have to remove an existing one so the total number of included aircraft remains about the same... De-lurking for a moment,I recall the original intention was to include at least one aircraft from each common category (single, light twin, heavy twin, bizjet, etc). The new criteria seems to be features / polish / completion - I'm not arguing which criteria makes more sense for a 0.9.9 or 1.0 release, but that's why the c310 is in, as I understand it - in the absence of a Baron or Diamond TwinStar, it's the only light twin that really exists with a model and cockpit. It's had very little love, and the default skin has been the military variant, which a few people have objected too in the past.If the argument about 'covering the categories' still holds, then replacing the c310 with b1900d is moot - for sure the b1900 should go in, because it's polished and slick, but it's a totally different class of aircraft (replacing the DC-3 with the b1900d would be more equivalent, but there are other reasons the DC3 is nice)Anyway, I guess all I'm really saying is, it sounds as if the criteria for inclusion have shifted changed, and that's fine, but it might put the existing aircraft selection from 0.9.8 in a new perspective.JamesPS - any time someone wants to do the TwinStar, I am prepared to offer all kinds of bribery! Cash, beer, you name it! -- Morbo finds all humans pathetic  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] [PATCH] README.multiplayer update

2005-10-14 Thread James Turner
On 14 Oct 2005, at 08:33, Oliver Schroeder wrote:Finding the "right" port isn't easy, since we have about 32 thousand (64  thousand on newer OSes) to choose from ;) However, I decided to use port 5000 on the server-side (and 5001 for telnet),  both ports are configurable but these are the defaults. Both ports are only  used by the free internet chess server (fics), which uses tcp. The udp ports  are not used, yet. (AFAIK) Although a client can choose any incoming port he prefers, my personal  predilection is to use the same port as used for outgoing. (=5000) It would be better to pick a port range that is entirely unused, for two reasons:- I think there's an implicit assumption that if the TCP port is well-known, the UDP port is reserved for your use- This stops FG providing a TCP alternative to UDP on the same port, which is something I think should be done anyway. Requiring people to update their firewall NAT tables is not a long term approach, even assuming the user is permittd to do such a thing; a much better approach is to have a 'try UDP, fall back to TCP approach', since TCP traversal from inside the firewall to out 'just works' with most NAT boxes. (One solution to using UDP is to implement Microsoft's UPnP system for asking the firewall to set up a dynamic port forward, but we looked at doing that for WorldForge and  it's horrible. Really big spec. Nasty.)- As a side issue to the second point, unless you want to implement your own reliable layer on top of UDP (boring, fiddly), it makes sense to have a TCP channel open anyway for reliable transfer of critical information. Textual ATC might fit into this category, and I'm sure there is other meta-info that should be reliably delivered.HHJames-- Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems.  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] [PATCH] README.multiplayer update

2005-10-14 Thread James Turner
On 14 Oct 2005, at 10:27, Oliver Schroeder wrote:But I do admit, that it might be a huge barrier for a user to alter firewall  rules as needed. But anyway, using a fallback mechanism leads to everyone  using tcp connections, as they would simply work. And I repeat, you don't want tcp in multiplayer environments. I simply don't agree with that statement - many Windows games offer both options, for this exact reason. The notion that using TCP for multiplayer games is inadvisable is simply unfounded in my experience. It is certainly 'conventional wisdom' that TCP is evil / bad / slow, and for sure it offers a performance and overhead cost, but TCP works perfectly acceptably providing you have a faster-than-modem connection and low packet loss rates, which is the case for virtually everyone with a DSL or cable connection these days.Back in the days of QuakeWorld and Tribes 1, for sure this was more critical, but we've using nothing but plain TCP in WorldForge for years, in a interactive environment, and the response is pretty good. For sure we will move the 'lossy' position update data to UDP in the future to get smoother updates, but it's purely an optimisation, and we will always keep TCP as a fallback, since so many people are NATed.So my perspective is that amount of code added is trivial, the usability benefit is high, the people who can make UDP work see no change, and a large group of people who previously would be completely unable to use MP can give it a go. Anyway, I'll resume lurking now.James -- Java is, in many ways, C++--  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Scenery files triangles

2005-07-13 Thread James Turner
On 13 Jul 2005, at 15:36, Andy Ross wrote:These days, it's usually faster to use indexed vertices.  Strips and fans are faster because they reduce the number of vertices that need to be transformed by (and sent to) the hardware by "saving" 1 or 2 from the last triangle drawn.  But modern cards have vertex caches that are much (!) larger than 1 or 2 entries.  If someone wants to change the terrain format, I'd suggest trying indexed vertices first -- it's simpler, too. Whilst wishing to avoid a 'me too' post, I fully agree with this; writing a strip-ifier is a complex job, storing each tile as several, or maybe even one vertex array with indices is easier to generate, involves fewer SSG nodes, and is easier for drivers to optimise on the card, than either fans or strips.James___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Fedora Core 4

2005-07-12 Thread James Turner
On 12 Jul 2005, at 03:14, Paul Kahler wrote:I'm looking to build FGFS on FC4-x86_64. I looked at the instructionsat: http://www.flightgear.org/cvsResources/anoncvs.html  It soundsreasonable, but I can't just "yum install plib". Is there a repositorywith a suitable package? A link to instructions on using non-standardrepositories would also be helpful ;-) http://download.fedora.redhat.com/pub/fedora/linux/extras/4/x86_64/(and search for plib)http://download.fedora.redhat.com/pub/fedora/linux/extras/readme.extrasBut for simgear / flightgear, you need to build following the instructions on the website; also if you want to run a CVS version of plib (to get bugfixes), then obviously you can't use the fedora-extras version.If someone here is building simgear / flightgear packages and providing a custom repo, I've never seen it mentioned.HHJames--The real enemy is the gramophone mind, whether or not one agrees with the record that is being played at the moment.___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Linking order problems?

2005-06-27 Thread James Turner
On 27 Jun 2005, at 02:20, Jon Berndt wrote:I've got the basic build procedure figured out (I think) with the new JSBSim code in FlightGear. However, once it gets to the Big Link, it ultimately fails. Here's the link line: I think the problem here is ordering of static libs - I assume the various JSBsim sub-libs, eg 'jsbsim/models/libModels.a', all rely on symbols from the core JSBsim lib, jsbsim/libJSBSim.a. However, libJSBSim.a is listed before them in the link order. GCC has the behaviour, when linking static libraries, of using the static library to resolve all currently un-defined symbols in the current code, and then discarding all remaining symbols from the static lib. If a later library in the link line then needs one of those symbols, it will not be found.So, in summary, the solution is to edit your Makefile so libJSBSim is linked after all the other JSBSim libs, and you may have to further tweak the order to get everything to come out right.Hope this helps,JamesPS - I used to wonder why GCC's linker doesn't do what most people expect, which would be to retain the entire static lib in memory until the complete link is finished, and only then discard un-used symbols. I believe the reason for the actual behaviour is to do with keeping the linker a single-pass system, with less drastic memory requirements. -- Morbo finds all humans pathetic  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] FlightGear Build Problem Under MacOS 10.4

2005-05-20 Thread James Turner
On 20 May 2005, at 15:30, Andy Ross wrote:it is no longer legal to do this:  int i; glGenTextures(1, i);  Instead, you have to declare 'i' as GLint (and similarly for GLuint and so on)  Are you sure?  I thought the Apple compiler was still a 32 bit environment on OS/X.  And in any case, PPC64 is an "LP64" ABI, which means that a plain "int" is still 32 bits, just like GLint.  Really, there are no meaningful (for our purposes) systems any more where an "int" is anything but 32 bits.  The size of longs and pointers is variable, but ints are pretty fixed. Umm - I am not sure about the reason for making the change, but the fact is that on Tiger, GLuint is a typedef for 'unsigned long'. Hence, the code has to be changed to use the portable names, or GCC 4.0 chokes.Next time I run into an Apple engineer, I'll ask about this.HHJames ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] Re: opening window splash screen

2005-05-05 Thread James Turner
On 5 May 2005, at 09:18, Melchior FRANZ wrote:Oh. I hope you mean that the startup time has become much too long over time, and not that this patch made it worse. I don't think that the patch has a noticable effect, neither positive nor negative. Except that it possibly improves the perception and makes it feel a bit faster. And that will further improve with progress info.  What has slowed down fgfs in the last time was the migration to the new database formats -- not because they are read less effectively, but simply because they contain much more data. That's at least the impression that I got from valgrind (http://www.valgrind.org/) runs. I don't have much time to delve into this right now (hah!), but I have some log calls in my local build, which have been fairly consistent (haven't tested since your changes, Melchior - when I do, I'll post those numbers).That said, here are the numbers I have (for three runs)            time to run  fgMainInit:    44 sec    32 sec    29 sectime between idle_state 0 and idle_state 1000     33 sec    10 sec    10 sec(wall-clock) time after hitting idle_state 1000 before scene appears    consistently about 25 - 30 secondsComments - the first phase (lots of database traversal) is obviously very dependant on file system cache hot-ness, and the second phase similarly. The third phase, *after* idle-state 1000, is the bit I was referring to when I talked about starvation; while it's doing this wait, I see the splash screen, and see log output from subsystems frequently (traffic manager, clouds, ephemeris), but it seems to sit there for ages before showing the cockpit + scenery.I ran a statistical profiler on the startup, and it didn't get all the way through startup before it hit it's log size limit, but the first part was spending huge amounts of time parsing data files, especially doing string - to float parsing. Doing the equivalent of 'atof' was something like 11% of the total time for the profile I ran.Lazyness is the way to go here, I'd suggest. Or binary file formats.James -- Ignorance more frequently begets confidence than does knowledge.  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

Re: [Flightgear-devel] opening window splash screen

2005-05-04 Thread James Turner
On 4 May 2005, at 21:39, Melchior FRANZ wrote:It opens the window (with splash image if configured) as soon as possible, and does all the other initializaion in the idle loop, split up into appropriate chunks. The patch does basically only shuffle parts around, without changing the order of initialization or removing anything. It is tested with glut  sdl, with and without /sim/startup/splash-screen and /sim/sceneryloaded-override. Minor partial objection - the Mac startup is dog slow (like 90 seconds to get to a usable plane in the C172 and SFO), and I think at least part of the problem is the 'init while idle' scheme - FG wastes too much time doing rendering type things when I'd be happier to have it be 'frozen' but take half the time.I think the fix for this could be as simple as a render flag that disables the entire scene graph and replaces with a dummy scene (black screen + progress bar?) while some property is set.Ah, wait ... does this affect tile-loading and hence hit-testing and hence ground-trimming?Anyway, I am nervous of changes that do yet more stuff in the idle callback, because I think it's a bit starved for time.HHJames -- Some people, when confronted with a problem, think I know, Ill use regular expressions. Now they have two problems.  ___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d

[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12

2005-04-06 Thread James Turner
On 6 Apr 2005, at 09:46, Erik Hofman wrote:
Modified Files:
fg_os_sdl.cxx
Log Message:
Melchior FRANZ:
Make SDL window resizable; This exposes the same problem that many
GLUT users have: resizing up may cause a temporary switch to software
rendering if the card is low on memory. Resizing down again switches
back to HW rendering. (KSFO is texture intensive, but there are no
problems in LOWL, and elsewhere.) Less and less users will have the
problem as cards become better, and it's no reason not to allow
resizing altogether.
Bad news - I've had this change in my tree for a few months now, and it 
doesn't work right on OS-X, due to a fairly deep-rooted problem with 
PLIB / FlightGear - there doesn't seem to be a way to do a 'vid 
restart', i.e force every display list / buffer / texture to get 
deleted and reloaded.

This is really something that should be supported at the PLIB level, 
but, well, that's another story.

Anyway, the Linux GL implementation appears to re-use GL contexts upon 
re-size, but the OS-X sometimes tears them down and re-allocates them. 
When this happens, I get a very interesting looking, un-textured 
version of FlightGear; kinda retro but not usable. Incidentally, the 
OpenGL spec dodges this whole issue, but from porting various other 
pieces of GL code, the rule seems to be that Windows and Linux tend to 
re-use contexts (but some Windows drivers don't always), but the Mac 
drivers are very aggressive about throwing out contexts are starting 
again.

Anyway, the 'display lists and textures are valid across a context 
change' assumption is basically an unportable one.

BTW, this is also the reason it's hard to do a 'full-screen toggle' at 
runtime (which otherwise would be easy in SDL), or other graphics 
changing options. However, I had a look around the code and I'm pretty 
sure trying to make vid-restarts possible at this point would be quite 
invasive changes, so I didn't even bother to suggest it.

Ho hum,
James
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12

2005-04-06 Thread James Turner
On 6 Apr 2005, at 11:14, Melchior FRANZ wrote:
So then add a #ifdef for OS-X around the resize event, so that it is
simply ignored? Did you send a bug report to the SDL people?
I think you misunderstand, it's not an SDL bug:
*FlightGear is relying on assumption about how OpenGL implementations 
work that does NOT hold on OS-X, and may not hold on some Windows 
drivers, but which happens to hold in the common case on Windows, and 
apparently always holds on Linux*

There are plenty of SDL + GL applications on the Mac that do re-sizing 
just fine, but they have the ability to initiate a vid-restart (as they 
correctly should on *every* platform, strictly speaking) when re-sized.

Of course, we can certainly live without the feature on Mac - just be 
aware the fault lies with FG / PLIB for not providing an API that is 
somewhat important in real-world situations. I for one would love to be 
able to switch from full-screen mode to windowed while running, for 
example.

HH
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] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12

2005-04-06 Thread James Turner
On 6 Apr 2005, at 12:53, Melchior FRANZ wrote:
Err ... or is it SDL_SetVideoMode() in SDL's video/SDL_video.c? There's
a suspicious comment in there:
* WARNING, we need to make sure that the previous mode hasn't
* already been freed by the video driver.  What do we do in
* that case?  Should we call SDL_VideoInit() again?
*/
Would be nice if we could identify and fix the bug where it is, instead
of removing a useful feature that is certainly *not* the bug.
I'm going to restate the problem, just to be very clear.
- When a window is resized, SDL (or GLUT) need to re-allocate the GL 
context. The SDL documentation explicitly mentions that 
SDL_SetVideoMode will be called again with new size, so a new context 
will definitely get created on the Mac. I'm putting aside any platform 
specific ways to modify existing contexts.

- There is nothing (absolutely nothing) in the OpenGL spec about the 
sharing or lifetime of texture objects or displays lists across 
different contexts - logically they are completely separate.

- The current FlightGear code assumes that display lists and textures 
are preserved across a context switch.

- This has not been noticed for the past X years because it *so 
happens* that the Linux and stock Win32 implementations happen to 
implement the sharing behaviour between contexts, while OS-X does not. 
Both behaviours are completely valid and compliant implementations of 
the OpenGL spec.

- Most (if I'm being bitchy, *good*) scene-graph / engine libraries 
have some kind of 'invalidate' button you can kick that makes them 
delete all their display lists / textures and reload them. This is what 
Unreal / Quake / etc are doing which you change full-screen-ness or 
many other graphics settings while they running, i.e a vid restart.

- Making PLIB / FG support vid restarts would be a very good thing to 
do, but would be a lot of work and invasive. I would be happy to give 
it a go if I thought the patches would be accepted!

- Until such a change is made, re-sizing the window is not going to 
work right on OS-X

- We can live with this situation. But if there are any user bugs 
reported from Windows users with odd drivers about 'everything looking 
crazy after I resize the window', well, now you know :-)

Regards,
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] Running Flightgear on Mac OS X

2005-03-10 Thread James Turner
On 10 Mar 2005, at 05:02, Josh Babcock wrote:
I've successfully compiled Flightgear from CVS (thanks for the help),
but for some reason it won't run. FlightGear loads and all i see is a
Black screen with a white box in the middle (where the splash screen
should be). The CPU usage goes to 100% and stays there until i kill
fgfs.
Sounds like it is using software rendering.  Do you have a 3D card and 
the appropriate driver installed?  It would help to know what OS, 
driver and 3D card you are using.
It is pretty much impossible for any recent Mac to use software 
rendering - even a G3 iBook has some kind of Radeon in it as standard. 
What this could be is something that caught me ought the first few 
times - FG is now taking an looong to startup on OS-X, something on the 
order of 90 seconds on my PowerBook G4 1GHz.

The first few times I assumed it had hung, but then I waited and it 
actually got as far as showing the splash screen.

I have spent some time doing some profiling and spot timing of startup, 
and unfortunately there are no really obviously bad things happening; 
there's just an awful lot of work to be done, much of it greedily, and 
it takes a while. If you run with the logging level put back up (as it 
used to be), you can see all the work that's going on.

Of course, your problem could be something completely unrelated - you 
could run under gdb and ctrl-c once it seems to have stopped, to find 
out where.

HH
James
--
The lack of planning on your part does not constitute to an emergency 
on mine

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: instrument xml question

2005-03-04 Thread James Turner
On 4 Mar 2005, at 15:08, Curtis L. Olson wrote:
It's maybe analogous to writting assembly language without any sort of 
jump labels ... anytime you insert a statement, you have to go back 
and recompute all your jump addresses (or in this case any time you 
add anything you need to go back and recompute all your indentation 
levels ...)
An 'obvious', not non-trivial solution:
the current alias logic is used to refer to one XML node, from another, 
using a file-system like syntax. This is pretty much the job XPaths 
were designed to solve. XPaths support a syntax similar to what is 
being used for aliases (I think), but also support matching by tag name 
/ attribute (for example, and id attribute)

So one option would be to implement a small subset of useful XPath 
functionality, or just to support something like a 'named-alias' where 
instead of using
	
../../../../../my-params/foo/bar

you could use (for example)
@my-params/foo/bar
This is robust against the relative position / depth of the XML nodes 
changing, naturally. Implementing the '@' operator is not especially 
difficult, but it can be a costly operation to do repeatedly (you need 
to either build a map of named nodes, or do a search each time). I 
assume for panels the alias is only resolved at panel load, so the cost 
is unimportant.

HH
James
--
Morbo finds all humans pathetic
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


[Flightgear-devel] Speedbrakes / Spoilers

2005-02-10 Thread James Turner
I've been spending as much time as possible over the past few days just 
flying around (I've had a very long gap where FG wouldn't build and I 
was busy with other things), but this has raised a small issue which 
may indicate something about my flying habits...

Basically, I have not yet found an aircraft where the speedbrakes or 
spoilers seem to work, either visually or in terms of slowing the plane 
down. From looking at data/keyboard.xml, I can see the current bindings 
are j/k for the spoilers, and Ctrl-B for the speedbrake, but pressing 
the keys doesn't seem to do anything.

So, have I missed something here? In particular, which models should 
have spoilers and speedbrakes that definitely work, and maybe even 
animate? I could swear I recall seeing pictures of the Fokker-100 with 
it's 'distinctive' tail brake assembly deployed.

And on a related note, do any of the jets have thrust reversers 
installed?

HH
James
--
Morbo finds all humans pathetic
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Speedbrakes / Spoilers

2005-02-10 Thread James Turner
On 10 Feb 2005, at 11:57, Innis Cunningham wrote:
Basically, I have not yet found an aircraft where the speedbrakes or 
spoilers seem to work, either visually or in terms of slowing the 
plane down. From looking at data/keyboard.xml, I can see the current 
bindings are j/k for the spoilers, and Ctrl-B for the speedbrake, but 
pressing the keys doesn't seem to do anything.
Can't remember if the speedbrakes actually slow the aircraft on the
737 but the animation should work when you hit Ctrl-B
Ah, ok. Thanks to Martin, I realised they work on the TSR2 as well, and 
both the spoilers and speed-brakes work on the Fokker-100. I haven't 
had a chance to test if the FDM is seeing any effect yet, this is just 
checking over the visual models.

So, apologies for the confusion, I didn't check closely enough, and the 
two aircraft I happen to have been using the most, the F16 and the 
A320, don't seem to have either system installed.


And on a related note, do any of the jets have thrust reversers 
installed?
Not that I am aware of.
Drat, and no auto-brakes either - I guess I'll have to stop flying my 
approaches so fast :-)

Adding animated reverser cowls to the A320 would be a seriously nice 
touch, if whoever made the model + animations has any free time to 
kill.

HH
James
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Speedbrakes / Spoilers

2005-02-10 Thread James Turner
On 10 Feb 2005, at 13:03, Martin Spott wrote:
While we are are it, do we already have consensus on which keys to use
for these functions - are the keys consistent across different aircraft
and FDM's ?
The keys do seem to be standard, j/k for spoilers and Ctrl-B for 
speedbrake, the issue of course is guessing for a given model which 
surfaces are assigned to which name. I guess 'things on the wings' are 
spoilers, and 'things not on the wings' are speed-brakes?

Except that the TSR2's brakes are on the spoiler key. The Fokker uses 
the spoiler key for the wing spoilers, and Ctrl-B for the tail-brake 
thing, which seems sensible to me.

BTW, there is no keybinding for reverse thrust : I'm going to test with 
some nasal code i found in one of the joystick files, but is there a 
free key I should use? Ctrl-R perhaps?

Here's the snippet I found (in Top-Gun-Afterburner.xml):
reverser = !getprop(/controls/engines/engine[0]/reverser);
props.setAll(/controls/engines/engine, reverser, reverser);
if (reverser) {
gui.popupTip(Thrust Reverser ON);
} else {
gui.popupTip(Thrust Reverser OFF);
}
HH
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] Mac joysticks

2005-02-07 Thread James Turner
I finally managed to get my FlightGear behaving itself last week - there are a few issues I want to investigate before I bring them up here, but one affected me almost immediately - the input code as it stands right now means Mac joysticks tend not to be recognised.

There are two issues: firstly, when support was added in the XML joystick definitions for platform specific axis / button identifiers, a case was added for 'mac' as well as 'unix' and 'windows' - but most (none?) of the joystick files actually use this tag. Now, one option is to go around adding 'mac' tags, but at least for my SideWinder, the OS-X axis / button assignments match the Unix ones. I would be prepared to bet a small sum of money that most of the time, the assignments are going to match ... but of course I can't be sure until Mac users with some of the existing joysticks test this. (Knowing what happens with the logitech and thrustmaster sticks would be interesting)

Anyway, I have a trivial patch to 'input.cxx' which adds in a fallback to 'unix' on OS-X; it works for me.

The second issue is probably my fault, since I did the original code to add joystick support to PLIB on OS-X (but various people have fixed bugs since then). The code that reports the device name is only using the Product ID, and not the manufacturer ID as well. Hence, on OS-X, the name returned for my joystick is 'SideWinder Precision 2 Joystick', whereas on Linux it would be 'Microsoft SideWinder Precision 2 Joystick'. Obviously this is breaking the config lookup logic.

I guess I should submit a patch to PLIB for this issue - in the short term I have just extended my joystick definition.

HH
James
--
That which does not kill me has poor aim___
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

2005-02-01 Thread James Turner
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*?
HH
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

2005-02-01 Thread James Turner
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?

HH
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] Individual aircraft downloads

2005-01-04 Thread James Turner
On 4 Jan 2005, at 23:49, Jim Wilson wrote:
tar and gzip come free out of the box on Unix.
We have to get (un)zip separately to get it working. It's either way 
and
  I don't feel like giving windows users the benefit of the doubt (the
number of windows _developers_ is frighteningly low compared to any 
UNIX
flavor).

gzip extracts pkzip files.
Just to add an extra idea to the fire; many game engines [1] (and one 
bytecode computer language [2]) support reading data from compressed 
zip files (as certain datafiles in FG are already read from gzipped 
sources, I think). The code to do this can be as simple as a self 
contained, public-domain C file (that builds ontop of zlib), assuming 
only read-access is necessary. (If anyone wants the code, I can dig it 
out, we use it at my work for exactly this purpose)

Hence, in the future, these files could be downloaded and dropped into 
an aircraft folder directly (this works for other kinds of 'pluggable' 
things too, such as scenery). The only penalty is the time taken to 
decompress the zip data when it's read, but zip decompression is very 
fast.

Anyway, obviously not a priority, but it 'might be nice one day'
For some reason, I have never seen code to do this with the .tar.gz 
format, thought in principle it should work; the issue is that ZIPs 
have a table of contents that can be read without extracting all the 
files, whereas for a .tar.gz I think you'd have to uncompresss the 
whole contents and then start examining the tarball. But I know very 
little of how tars are structured internally.

HH
James
[1] - Quake 3 (not sure about doom) uses zip renamed to PK3, earlier 
versions used a custom WAD format which was essentially the same idea. 
CrystalSpace supports 'mounting' a .zip to access textures / meshes / 
etc from it

[2] - Java .jar files are zips with a magic file inside
--
Morbo finds all humans pathetic
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Diamond TwinStar Panel

2005-01-01 Thread James Turner
On 1 Jan 2005, at 17:38, David Megginson wrote:
Here's a high-resolution picture of the Garmin-1000-based panel on the
new Diamond TwinStar, one of my dream aircraft (it rececently crossed
the Atlantic non-stop from Canada to Spain burning less than USD
200.00 worth of fuel).  Anyone aircraft model designers ready to take
this one on?
http://www.diamond-air.at/Pressebilder/DA42TwinStar/Panel/tn/ 
DA42panel_high.jpg.html

That's a beautiful airplane, and an amazingly clean panel. I want one.
HH
James
--
The lack of planning on your part does not constitute to an emergency  
on mine

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] are we switching from blender to ac3d?

2004-12-26 Thread James Turner
On 26 Dec 2004, at 00:37, Curtis L. Olson wrote:
What did I say that was incorrect?  If I've missunderstood something 
about plib/ssg I'd appreciate being corrected.  If  modeling is still 
done in blender/ac/multigen/whatever, then you need a conversion path 
to plib.  That means going through one of the existing loaders no 
matter how you approach it.  Using .ssg doesn't gain you anything in 
terms of rendering quality or features since you have to pass through 
a higher level format anyway.  The only thing .ssg gives you is 
potential model load performance increases, although I've never seen 
any comparison benchmarks ...  If you do get a performance increase, 
then perhaps we could have some util that converts to other formats to 
.ssg on the fly  ... so you pay a price when you first load a new 
model, but after that, for each subsequent run of the application, you 
can load the .ssg format.

We just need to handle this in a way the doesn't send us down a one 
way .ssg street.
What it means is that the MAX / Blender exporters for .ssg need to be 
linked against PLIB, but so what? That's not difficult (that I can 
see). And the core issue is that it's easier to do the selective 
mapping of modeller features (nurbs, meshes, materials, animations, 
whatever) to renderer features inside that modeller's exporter API, 
which invariably makes all the data available in sensible, documented 
ways. The exporter becomes code that builds a PLIB scene graph by 
traversing the modeller's data, and then saves that graph.

One catch is that the Blender exporter would have to be a compiled 
plugin, not a Python script (unless Norman is sitting on a 
Python-wrapper for PLIB :-), but that will still be less coding, and 
more maintainable, than trying to deal with the entirety of a Blender 
file (or other high-level format) inside a PLIB loader. Which, as you 
pointed out, is *exactly* why many of the PLIB loaders have 
limitations.

Again, this is exactly analogous to the 2d art pipeline - people edit 
in a rich format like Gimp / Photoshop, but no one would suggest trying 
to load those formats directly in a game (layers, paths and all); you 
keep your original files around some place, and export / Save As to 
whatever simple format suits your needs, whether it be PNG or RGB or 
JPEG.

Anyway, I'll go back to lurking now.
James
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] are we switching from blender to ac3d?

2004-12-25 Thread James Turner
On 25 Dec 2004, at 14:43, Chris Metzler wrote:
A plib loader for .blend would, IMHO, be an incredible boon for FG.  As
noted, ac3d file format can't include specular/diffuse shading info.
Blender/.blend files also give you the ability to texture an object's
faces in a fashion other than UV mapping -- by assigning (named) 
materials
to faces, and then assigning different textures to the different
materials.  ac3d files can't do this.  There's a lot of other .blend
functionality that ac3d can't do (e.g. procedural textures), but these
two are the ones that have bitten me so far.

This is absolutely the wrong approach; the .blend file (like the .3ds 
format) is a very, rich, complex format that evolves with Blender 
releases. Just like 3DS, it is a dreadful format to import / export, 
and no-one should try.

The correct approach is to pick a format that makes sense for 
FlightGear (whatever that may be), and write / find / improve a Blender 
exporter script (which are written in Python) for that format. The 
exporter API evolves slowly across Blender releases and is stable for 
precisely this reason.

BTW, this is why 3DS do not document their file format, but do provide 
a very good exporter API. All commerical games invariably use an 
efficent, renderer specific format for their meshes; early in the 
development cycle they write a 3DS exporter (or Maya, etc) and give it 
to the artists, and that it the tool-chain. For plib, that format would 
probably be some kind of serialised representation of the scene-graph, 
but I'm not a PLIB expert.

BTW, I have been through this cycle with WorldForge clients; currently 
one client loads 3DS files, but we are hurriedly switching to 'export' 
formats (as opposed to editable ones) becuase the 3DS loaders are 
enormous and complex. Trying to load 3DS / .blend / .lwo (and, I would 
contend, .ac3d) is analagous to saying FG should load it's textures as 
XCFs / .psps / PaintShopPro files - it's possible, but why on earth 
would you go to so much effort?

HH
James

___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Re: FlightGear on Mac OS X

2004-11-15 Thread James Turner
On 14 Nov 2004, at 13:42, Arthur Wiebe wrote:
What needs to be done is something like this
if (defined(macintosh) {
  #include OpenGL/gl.h
}
else {
  #include GL/gl.h
}
Can you tell that I don't program in C? :)
 Two things - please use __APPLE__ to detect OS-X, 'macintosh' is more 
for Classic era stuff (though still works, of course)

Secondly, Flightgear in most places has #defines for gl.h and glu.h, 
which are setup by configure. The files you have encountered are the 
ones that have been added since I sent Curt the changes (probably two 
years ago) for the FG_GL stuff, I think.

My current inclination (which I've done in other projects) is to make a 
'fg_gl.h' which simply includes the #ifdef test you have above, and use 
that everywhere instead of the system GL headers. This needs to be done 
for glu, glut and gtlext.h as well, of course.

The reason I haven't done that yet is, SDL already has a header that 
does this (SDL/SDL_gl.h), any scene graph FG switches to will also do 
this, and PLIB probably ought to be doing it, I'm just too busy to 
fight to get patches into plib. Doing it locally in FG will work, of 
course, but is slightly redundant.

BTW, I have local changes to built with XCode, run as a bundle, with 
PLIB and SimGear as private frameworks, I'm just having some SDL 
startup issues I haven't had time to look at.

HH
James
--
Morbo finds all humans pathetic
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] FG MAC OS 10.3 binary for 0.9.6 scenery?

2004-10-28 Thread James Turner
On 28 Oct 2004, at 11:57, Geoff McLane wrote:
Can anyone help with such a beast? Have tried the 0.9.3 (from
Wally's World) and 0.9.4 binary (FlightGear-0.9.4.tgz)  with
the current 0.9.6 scenery base, thank you for these, but no
go ... even when the 'version' file is altered to match!
I had this problem, I was able to work around it eventually but I 
forget how - sorry.

Says missing Navaids/default.nav, (and thus also .nav.gz)
for a start ... It seems there is a default.something
in several folders, but the data/Navaids folder of 0.9.6 contains
awy.dat.gz, fix.dat.gz and nav.dat.gz, among other things ...
Yes, that sounds about right.
(a) can anyone make a recent MAC OS (10.3 bash) binary available? or
(b) is there an archive where the old scenery base 0.9.3 or
4 is/are available for download?
I've done bits of work in this direction in the past, and since 
Jonathan Polley is busy these days (he's the guy who did the previous 
Mac binaries) I guess I should step up to the plate. I'll take a look 
tonight / over the weekend, but don't hold your breath.

HH
James
--
You whine like a mule. You are still alive!
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] ATC Network Test

2004-10-05 Thread James Turner
On 4 Oct 2004, at 19:17, John Wojnaroski wrote:
A few details...
Volunteers will get a package of software that contains the TNL 
libraries and a basic set of software to connect to the ATC net as a 
controller or pilot. Package will include ALL source code and make 
files for a Linux system.  Sorry, I'm just not an MS type. However, it 
will build under Cygwin.

I'm happy to test, and probably even get the code building on OS-X, 
since it should be very close to working already.

HH
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d


Re: [Flightgear-devel] Linuxtag

2004-06-18 Thread James Turner
On 18 Jun 2004, at 13:09, Mathias Fröhlich wrote:
Next week is the Linuxtag in Karlsruhe, Germany.
http://www.linuxtag.org/
Is Flightgear present this year?
Or will somebody be there for an other project?
I'm exhibiting at the WorldForge booth, where we are also going to have 
a few Blender guys. Games in general seem fewer this year, last time I 
attended LinuxTag (2001) Alex Perry and Durk were there exhibiting 
Flightgear and doing demos that everyone loved.

Of course, I'm not sure anyone will be able to beat Jon Stockhill and 
co's amazing efforts at LUDEX back in April this year.

Anyway, if you're at LinuxTag, stop by the WorldForge booth and say hi. 
I have flightgear on the demo machine, but it's got a job to do demoing 
our client software!

HH
James
--
There is a very fine line between 'hobby' and 'mental illness'
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] OpenAL - http://www.openal.org

2004-04-22 Thread James Turner
On 22 Apr 2004, at 09:24, Erik Hofman wrote:

Go with SDL's sound support. SDL itself supports OpenAL giving best of 
both worlds.

This is not quite right, I think; like OpenGL, SDL can use OpenAL, but 
it doesn't wrap the OpenAL API.

In general, I think OpenAL would be a big improvement, not least 
because it uses CoreAudio (modern) vs the Sound manager (old) on OS-X; 
I've looked into updating PLIB's snd code, but it's not a fun task. And 
besides, the doppler effects and such would be cool. Another more 
noticeable one for me is hearing the engine sound change as I pan 
around the aircraft in an external view...

HH
James
PS - Congrats to Jon Stockhill and co on a truly excellent demo of 
Flightgear at this year's Linux User  Developer Expo, which I just got 
back from.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] SGPropertyListener (was Re: [Flightgear-flightmodel] crash reporting)

2003-12-19 Thread James Turner
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 19 Dec 2003, at 19:03, Andy Ross wrote:

You would need to hook up the reset code as a command, so that Nasal
and other bindings could see it.  But it should work.  One thing that
isn't implemented yet is a SGPropertyListener interface that can be
used from Nasal; you would have to poll the property value just like
the external script would.


Just so you know, I think the *only* code in FG which uses the listener 
is the patch I submitted to the property browser to make it 'live'. The 
problem, which was discussed at the time, was that certain properties 
(eg, 'bound' ones, I think) don't fire listeners correctly. David 
Megginson and I proposed a few schemes, which would allow keeping both 
the existing binding interface, but also the existing listener 
interface : they basically revolve around listeners which poll their 
SGProperty once per tick : so there is still polling, but it's 
centralized.

Ideally, many more things would use the listener interface, and thus 
any polling of properties would be removed from all the other code, and 
only done if required by the property listeners themselves.

However, I think that large number of properties (all the JSBSim ones?) 
are of the 'bound' type, so quite a bit of polling would still occur 
(iff there's a listener on the property).

HH
James
- --
They are laughing with me, not at me.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (Darwin)
iD8DBQE/45nb7QfkxSkK4DcRAs3nAJwOUmy6N/3rEqY58wpvNCIaOwykcwCgiy63
y7vMlbOFB9/FMVO9E1TByj8=
=aOwZ
-END PGP SIGNATURE-
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] TaxiDraw-0.0.5 available.

2003-11-26 Thread James Turner
On 25 Nov 2003, at 23:56, Jon Stockill wrote:

On Tue, 25 Nov 2003, David Luff wrote:

Eliminated the bloody annoying flickering.
I was going to ask if you could do anything about this - not good on 
the
eyes - particularly when zoomed in, and a large percentage of the 
screen
is flashing.

In case anyone cares, TaxiDraw works for me using the CVS version of 
WxMac, on Panther (10.3) - I've had to hack a few things about, will 
clean them up and submit patches at some point. Thing is, I was only 
doing this to add Taxiways for EGPH (Edinburgh)  and ... and ... it's 
already got them! So I'll have to find something else to do :-)

One thing I'd really like is the ability to place some generic, 
rectangular buildings objects down, on the airports. Obviously this 
outputs to a totally different place to the runways.dat file so  is 
there any chance of eventually rolling TaxiDraw into FGSD? (I assume 
the hard / complex work is the canvas and positioning code, so moving 
from wx to FLTK would be tedious but not especially difficult)

The reason I mention is, I was about to add a couple of GUI features to 
taxidraw (like a list box to select airports by name instead of ICAO 
code), but I don't really want to invest brain-space learning WxWindows 
if I can avoid it. Not that I'm a fan of FLTK either ...

Any ideas how this might develop in the future?
HH
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] TaxiDraw-0.0.5 available.

2003-11-26 Thread James Turner
On 26 Nov 2003, at 10:53, Frederic BOUVIER wrote:

The reason I mention is, I was about to add a couple of GUI features 
to
taxidraw (like a list box to select airports by name instead of ICAO
code), but I don't really want to invest brain-space learning 
WxWindows
if I can avoid it. Not that I'm a fan of FLTK either ...

Any ideas how this might develop in the future?
This is something I would like to do, as time permit, or someone else 
do.
It shouldn't be very difficult to draw OpenGL rectangles over the 
existing
framework. It would benefit of having map or chart as an underlying
overlay and placement aid.
Right, being able to include an aerial photo as Jon suggested, or a 
plan (as is available from the CAA, for major Uk airports), would 
obviously greatly ease taxi-way creation.

I might see if i can get FGSD running on OS-X too, and then see how 
much work would be involved in moving some functionality around.

HH
James
--
The lack of planning on your part does not constitute to an emergency 
on mine

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] TaxiDraw-0.0.5 available.

2003-11-26 Thread James Turner
On 26 Nov 2003, at 11:44, David Luff wrote:

I've almost finished getting a 5 arc-second orange grid overlay 
working,
which is the same as used on the CAA aerodrome charts available online 
(UK
aip).  I was also going to add functionality to call wget to get the
Terrasever US aerial photos and use them as background - Terraserver 
terms
of use specifically allows any use whatsoever of the images.  I agree
though that fgsd is ultimately the way forward in this area.
Sounds great on all counts :-)

snip
apps I'm also working on.  Once FLTK 2.0 is released I'll have a good 
play
with fgsd, in the meantime I'll try and code the functionality as
generically as possible to make it easier for others to port if they 
want
to.  The only upside I can think of for the wxWindows version over an 
fgsd
addition is that it doesn't need hardware openGL support to run 
smoothly,
but realistically even most laptops should handle that these days.
Yeah, personally I think we should be doing all our tools as plain GL / 
PUI with extensions, though using a real toolkit has advantages too, 
and it's pointless to waste time bickering about toolkits rather than 
actually getting useful tools written. So, I'll shutup :-)

How can you not be a fan of wxWindows? - the chap who started it lives 
in
Edinburgh, and it uses 'colour' instead of 'color' ;-)
Because of the hideous macros for the event maps, for one thing. It's 
like a throwback to MFC. But, as I said, no futile toolkit bickering 
:-)

And remember chaps, pressing 'w' will completely and silently overwrite
your ICAO.dat file, so keep it backed up somewhere other than the 
working
copy!!!

(Putting the .dat file handling into the file open/save dialog should 
be
easy - I'll have a look)
This would resolve some of the Mac issues : the Mac version is running 
as a bundle, so it's CWD is '/' - my hacks are mainly changing paths so 
it can find runways.dat

Being able to use the gzipped version would be nice, if the code isn't 
excessive. Maybe a simgear dependancy is they way to go, since at least 
some of the parsing code must already be duplicated

HH
James
--
We are all in the gutter, but some of us are looking at the stars.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] SimGear/matlib.cxx: problem with gcc-3.3 and PowerPC

2003-11-10 Thread James Turner
On 10 Nov 2003, at 13:38, Olivier ABILLON wrote:

On a PowerPC platform (iMac) the gnu compiler gcc-3.3 (from Xcode) 
creates a bad object
file when optimisation are turned on. This causes FlightGear to crash 
at startup.
There is no problem when optimisations are off (-O0) for this file.
I didn't found such a problem on another file.

That explains a lot . can we do a #pragma optimization level 0 in 
the file, or is it only CodeWarrior that supports such options?

HH
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] FG and Mac OS X - standalone app (bundle, ...)

2003-11-03 Thread James Turner
On Monday, November 3, 2003, at 04:57 PM, Olivier ABILLON wrote:

Here are a few comments about making a standalone application for Mac 
OS X:

  I do not think that putting all data stuff (scenery, ...) in the 
application bundle is a good idea: users will no be able to edit 
preferences files, aircraft files, and so on, without a special menu 
function in FG or with the terminal.
  On my Mac, I put the data folder in the same folder where FG 
application is.
  I just add an APPLE case in the funtion bool fgInitFGRoot ( int 
argc, char **argv ) in the fg_int.cxx file:
I think the correct solution is to allow the base files to be packaged 
inside the bundle, but search the application support locations and 
preference support locations. That's pretty easy using FSFindFolder and 
the various domain and folder flags. However, many places in Flighgear 
currently only support a single location, rather than a list of paths 
to search, so this can't be done right now.

  it's simpler than using Apple's functions...
I don't think that's a big problem, the Apple functions are pretty 
verbose, but I'm happy to stick them in a separate source file, and 
they're a bit more robust than mangling the paths by hand.

  There is another problem: the Finder adds an argument in the 
argument list argv: -psn:xxx.
It must be removed. The Apple version of GLUT removes this funky 
argument; so a call to GlutInit must be done before parsing options.
  Another method is to trap this argument in the fgParseArgs function 
(file options.cxx):

snip
Isn't it safer to move glutInit? We don't know what behaviours glutInit 
is relying on, so passing it the raw command line seems more likely to 
work if things change in the future.

   I also added the following code at the beginning of the fgMainInit 
function in the file main.cxx:

#if defined( __APPLE__ )
freopen (/Users/'your_login'/stdout.txt, w, stdout );
freopen (/Users/'your_login'/stderr.txt, w, stderr );
#endif
 this way I can see what happens without using the console or the 
terminal (very useful for debugging)


  I noted that from version 0.9, FlightGear is slower (about 5 fps)(I 
have a 500 MHz G3 iMac, with an ATI rage pro graphic card - 16 Mo 
only). Disabling the drawing of objects does not speed the rendering. 
Reducing the size of the textures can enhance greatly the fps: up to 
15 to 20.
I haven't got FG running on my powerbook yet, but i'm hoping that with 
a 64mb radeon 9600, it will be usable (it wasn't, on my ibook). Still 
waiting on panther, alas.

HH
James
--
They are laughing with me, not at me.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Mac OSX 10.3 (Panther) Build

2003-10-28 Thread James Turner
On Tuesday, October 28, 2003, at 04:57 AM, Jonathan Polley wrote:

Oops, I sent this to the Users list instead.

For those of us who use Macs, I just installed Panther on my machine.  
Just the OS upgrade increased my frame rate by about 15%.  I am 
currently working through some compiler issues with Xcode and will let 
you know how well the new compiler works.

I assume you're using your own project files? I've locally set up 
project files for PLIB, SimGear and FlightGear, and it all compiles, 
but it's dieing even earlier than you are, in glut initialization. Oh, 
and I'm still on Jaguar : I will rebuild once my copy of Jaguar turns 
up.

I'm also still waiting to get my framework changes into PLIB ...

HH
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] Patch : support bundled operation on OS-X

2003-10-18 Thread James Turner
Here's a patch to locate the base package inside the application bundle 
on OS-X. The patch also disables the CPSForeground hack in 
boostrap.cxx, which is unnecessary if the we're running as a proper 
bundle rather than a Unix command line program.

Both of these changes are only compiled if OSX_BUNDLE is defined (I'm 
doing this via a setting in ProjectBuilder), so if you're building on 
OS-X using configure + make, you shouldn't see any chance.

I'll submit the actual project files once we resolve the OpenGL 
includes issues I mentioned in my previous email.

HH
James


fg-osx-bundle.patch
Description: Binary data


--
That which does not kill me has poor aim___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] OS-X binaries for 0.9.3-pre1

2003-10-16 Thread James Turner
On Thursday, October 16, 2003, at 05:18  am, Curtis L. Olson wrote:

Gene B. pointed me to a free windows setup.exe creator so I'm
thinking we ought to bundle the windows version up with that (or
something similar) for upcoming releases.
I know Darrel Wassiler (who's probably lurking here somewhere) has 
already done similar work, but for my own amusement, I've been working 
on getting SimGear and FlightGear compiled as a framework (in the case 
of SimGear) and a bundle (in the case of FlightGear). This translates 
as 'relocatable, double-clickable end-user-application' for those who 
don't know OS-X packaging formats.

It's not working yet (still fixing link errors), and I have a few 
patches to submit, but I'll keep playing over the weekend, so providing 
shrink-wrapped OS-X binaries for this release ought to be no problem.

Darrel / Other OS-X people : I was thinking of doing something clever 
with the FG_ROOT detection, especially now FG supports multiple scenery 
directories, such as searching $HOME/Library/Application 
Support/FlightGear/

As a sidenote to all FG developers, it would be great if any part of 
the base package that normal users might want to expand can handle 
multiple paths : then I can locate the main base package, which is 
essentially static for a given release, inside the the application 
bundle (i.e invisible to the end user), and they can drop new aircraft 
/ scenery / other extendable resource into a 'plugin' directory 
location as described above.

But of course, that can wait till post 0.9.3 (and a minor beef-up of 
the path / directory functions in SG, I suspect)

HH
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] OS-X binaries for 0.9.3-pre1

2003-10-16 Thread James Turner
On Thursday, October 16, 2003, at 09:55  am, Erik Hofman wrote:

As a sidenote to all FG developers, it would be great if any part of 
the base package that normal users might want to expand can handle 
multiple paths : then I can locate the main base package, which is 
essentially static for a given release, inside the the application 
bundle (i.e invisible to the end user), and they can drop new 
aircraft / scenery / other extendable resource into a 'plugin' 
directory location as described above.
This sounds like an excellent idea!
Heh, I'll take a look once I have a working binary, then. Packaging is 
a pet-peeve of mine, because installing and un-installing add-ons for 
MSFS and Fly! was such a chore. This is related to my desire of 
packaging each add-on as a zip / tarball, but that's going to have to 
wait until the PLIB model loaders are fixed not to access the 
filesystem directly.

Anyway, just being able to search a list of places for Scenery and 
Aircraft will be a start, I have no idea which other pieces of the base 
package end-users might modify (nav-data maybe? but even then, probably 
not, if releases are every 6 months ... and most people don't care 
about having the most accurate AIRAC cycles)

HH
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] OS-X binaries / OpenGL includes

2003-10-16 Thread James Turner
First the good news : I have a 'shrink-wrapped', double-clickable 
FlightGear CVS-as-of-today binary working on the Mac.

The bad news - boy is it slow! and big (which may be why it's slow, 
killing the CPU caches) I need to check what debug info and 
optimizations are being used, because simgear is coming in at 14mb 
compiled, and FG at 64mb! (that's including statically linked PLIB, but 
even still).

On my 700Mhz, Radeon 7500 Mobility equipped iBook, i'm getting 2-3 FPS 
in the cessna's cockpit, and 4-5 in outside views, or 7-8 if I look 
away from the model. If i look directly down at the ground (from the 
tower view, i.e to remove fill-rate / polygon-rate limits as much as 
possible), I can just about get 19fps

However, I'm getting a new laptop in a couple of days, will see how 
that improves things!

Anyway, before I can start submitting patches, I need to agree a 
solution which, alas, affects everyone, thought it's entirely of 
Apple's making: the OS-X openGL headers are in 'different' places from 
every other OS.

Essentially, on the mac, we need to do:
#include OpenGL/gl.h
instead of
#include GL/gl.h
For a myriad of reasons, this cannot be symlinked or worked around - 
the code needs to use a different file on OS-X.

The prior solution which I did (and Curt agreed to, I think), was to 
make the header file name a #define, define it in config.h via 
autoconf, But this sucks, because it's easy to end up with the value 
not defined, which leads to a really odd error. Here's what I'm talking 
about:

(in config.h or on the command line via -D:)
#define FG_GLUT_H   GLUT/glut.h
(in the file using glut)
#include FG_GLUT_H
So, my proposed new solution, is to add 3 files to simgear (at the 
root, beside sg_inlines and so on):
	sg_gl.h
	sg_glu.h
	sg_glut.h

These will all look like:

#ifdef (__APPLE__)
#include OpenGL/gl.h
#else
#include GL/gl.h
#endif
Then I will go through, and convert every reference to the open GL 
headers over to use these new headers.

How does this sound? Acceptable? Hideous?

HH
James
--
Morbo finds all humans pathetic
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] gear door sequencing

2003-09-25 Thread James Turner
On Thursday, September 25, 2003, at 01:20  pm, Erik Hofman wrote:

Speed brakes are on the top of the wing ( the extrados ? ) and can 
be used flying,
On civilian aircraft and gliders this is usually the case.  Military
types can have them in different places - such as the F16 (on top of 
the
fuselage?), the Buccaneer (opening tail cone) etc.
F-15  : top of the fuselage.
F-16  : horizontally along the fuselage, between the horizontal tail 
and
turbine compartment, at the end of the strakes.

One thing I've never been clear on - is there a distinction between 
'things you deploy in the air' and 'thing you deploy on touchdown'? I 
know the things I call spoilers on the wings of big jets can be 
extended in flight to slow the aircraft, as well as auto-deploying 
(more?) on touchdown to kill lift + decelerate.

But, I can't imagine deploying the split tail brake of the Fokker 100 
while in the air  is this actually ok, or is there some definite 
separation of usage?

On a related point, do any of the FDMs / FlightGear model  an increase 
in buffet / vibration / noise when deploying spoilers (or indeed, lots 
of flap) at high speed?

For thrust reversers, as well as a sleeve, you also get two (or more?) 
segments of the exhaust pipe that pivot at their rear end, to redirect 
the thrust. I think the fokker has this type of reverser. Playing with 
google image search turned up the following: (2nd is especially nice)

http://www.thrustair.com/dc9_thrust_reverser.jpg
www.robl.w1.com/Pix-4/ C970493.jpg
Anyway, the sooner FG / the FDMs / the planes support more of these 
devices, the happier I'll be - because I habitually fly my approaches 
too fast, and auto-spoilers really help stick the plane to the ground 
:-)

HH
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Wireeframe and Flat Shaded Display

2003-09-25 Thread James Turner
On Thursday, September 25, 2003, at 11:25  am, Norman Vine wrote:

Wireframe mode works,  it's the turning the textures on and off that 
no longer
works.  Maybe we should remap F9 to switch wireframe on and off?
We really need either
1) a key for wire-frame  or
2) figure out how to get PLIB to switch back to shaded after switching
to wire-frame as the prop browser is useless in wire-frame mode
I was just looking at main.cxx (in mounting fear...) and it looks 
pretty simple to cancel and restore the wire-frame state around 
puDisplay(), which I **presume** is what does the PUI drawing. There 
are probably a bunch of other things that might want to be excluded 
from wireframe mode, I guess. Around about line 748 of main.cxx, btw

As to *why* I as looking at main.cxx - I'm trying to get an idea how 
complex a conversion to SDL would be - what other people are working in 
this area? I've got quite a bit of experience with SDL itself, but 
main.cxx is frightening me.

HH
James
--
That which does not kill me has poor aim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] San Francisco city lake

2003-09-08 Thread James Turner
On Monday, September 8, 2003, at 04:07  pm, Alex Perry wrote:

I suspect that, since the vmap data was collected, the dips were 
drained
and thereby turned into the parkland that you see in the photo.
The problem is, that 'lake' is the Golden Gate Park. Having it be 
anything other than green parkland would be as wrong as having Central 
Park show up as water or sand in NY city! Note I'm not arguing that the 
park isn't low enough (or sandy enough) at the western end to have been 
tidal flats in the past, but it's been a park for a long time, and the 
land rises up (and gets less sandy) less than a quarter of the way east.

The impression I have is that no matter what texture is picked for 
'default' landcover, it's going to be massively, obviously wrong much 
of the time.

James

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker50/Models

2003-09-05 Thread James Turner
On Friday, September 5, 2003, at 03:12  pm, Martin Spott wrote:

3.) I know, you should not employ the flaps at 200 kts 
But if you do so, the aircraft climbs like attached to a high
speed elevator  :-)
I've been flying the Fokker 100 quite a bit, and I've noticed similar 
instabilities. Roughly (I am not a pilot)

- very rapid control response, especially on the roll axis). This  
sometimes extends to a 'snap' condition where I command an aileron 
reversal (okay, I just pull my joystick to the other side), and there 
is a very prolonged period with no response (for example, 8 or 10 
seconds, usually continuing the previous roll command) until the roll 
suddenly flips over.

- a similar elevator effect to that martin described, when deploying 
the flaps at high speeds
- very odd high pitch angle behavior ... I can't really describe it, 
alas. It seems like way too much lift is getting developed at high 
angles of attack, without a corresponding increase in drag to slow the 
aircraft.

Essentially, the aircraft flies pretty well (if a bit twitchy) 
providing you stick to a 'good' flight regime, but handling 
deteriorates exponentially when  I go even moderately beyond it. I'm 
aware that part of this may be running 'past the end of the data' in 
JSBsim, but other models do not seem to have these problems. Can this 
be alleviated by tuning the last data point for various coefficients, 
which I assume is what JSBsim extrapolates from?

(I was about to say the 747 is much more forgiving of my 80-degree 
banks, but of course, it uses YASim).

Anyway, aside from the nit-picking, it's a lovely plane, at least until 
we get an ERJ ;-)
James

--
There is a very fine line between 'hobby' and 'mental illness'
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] Packaging data files

2003-08-25 Thread James Turner
I did a bit of background research on the packaging / bundling issue, 
partly for my own curiosity, and in the vague hope of helping someone 
who wants to take a crack at this..

Essentially, anyone who's installed add-ons for MSFS (any version) 
knows what a pain it is, and uninstalling them is next to impossible. 
As people here have noted, the sane thing is to support (optionally!) 
reading files from a package. This is done by Fly! (.pod files), Doom, 
Quake, Mozilla, Crystal Space and indeed, Java.

The preceding list of software was not selected at random :-)

The last four all use .zip files (but renamed to pk3 in the case of 
Quake 3, and .jar in the case of Mozilla and Java) as the packaging 
format. Using a well known format makes many thing easier, as anyone 
who's found the limitations of  Fly!'s POD editor will agree.

Now, I wondered why no one has used tar.gz, rather than .zip  so I 
went and read the file format specs for .tar, and for .zip. 
Essentially, the tar format was designed around a write-once, stream 
orientated device (well, yeah, it's a Tape ARchvie). One of the things 
it's therefore lacking is a Table-of-Contents structure listing the 
archive contents. This makes accessing arbitrary individual files from 
the archives a bit of a pain; you either do a linear search each time, 
or build a TOC in memory (with offsets into the archive) at startup. 
This has issues of it's own, like further slowing down startup time :-)

So, it seems like ZIP might actually be the way to go ... extracting a 
single (say) 2k texture from a 300MB archive is doable without reading 
the entire archive. The next issue is stealing some code

Mozilla has a libjar, which is rather large (it also handles the 
'MANIFEST' files which are part of the Java JAR spec, and which provide 
lots of useful meta-data about the file contents, like the classes it 
contains ... we could use meta-data, certainly, but I think it's be 
easier to define a trivial XML syntax than use the JAR one).

However, CrystalSpace contains a single file, C++ implementation of a 
.ZIP reader, with a sane API. It's at:
 crystal/CS/libs/csutil/archive.cpp

Obviously it would need a little adaption for FG, but it's pretty 
simple code (it even has comments), so if anyone is considering doing 
this, I'd strongly recommend it, rather than someone here having to 
grovel in the ZIP format manually, or to create a dependancy on some 
heavy-weight library.

Anyway, hope this is of some use.
James
--
There is no such thing as a humble opinion.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Packaging data files

2003-08-25 Thread James Turner
On Monday, August 25, 2003, at 11:57  am, Erik Hofman wrote:

As a unix user the first thing that comes to my mind is off course tar 
and gzip (or maybe bzip2). I am aware of the limitations of the tar 
format, but the scan once for a TOC method seemed fast enough for me.
For very large archives, I contend this is not the case, and FG's 
startup performance is already, uh, poor. Pulling a 100Mb or 200Mb 
archive off the disk and through memory is going to hit any machine 
hard.

Regarding ZIP files, is it legal to use the compression algorithm 
without any limitations at the moment (for example GIF has a similar 
issue).
ZIP can use a range of compression schemes (including BZIP2!), and only 
one of them (compress) is covered by the LZW patent, which in any case 
expired in the US at the end of June. (and in europe / japan early next 
year) I suspect that encoders deliberately avoid this scheme, or don't 
support it, to avoid the issue. Notably, the CrystalSpace code only 
appears to support the common deflate / implode methods, but since I 
personally have used various 'random' ZIPs with crystal space, I assume 
these are the widely used methods.

Presumably, this also means the code could be extended to support the 
BZip2 format, by linking with libbzip2 (which is widely deployed on 
Linux, at least), and we'd get much smaller zip archives. I've no idea 
what spectrum of Zip readers, eg Nautilus, Konqueror, or WinZip or 
WinXP's builtin ZIP-as-a-folder mode, support that encoding.

HH
James
--
We are all in the gutter, but some of us are looking at the stars.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Packaging data files

2003-08-25 Thread James Turner
On Monday, August 25, 2003, at 02:44  pm, Erik Hofman wrote:

Not necessary, it is mainly the number of files that causes the 
slowdown. You can jump from one info block to another without actually 
reading any date in between them (there is a pointer in the current 
info block that points to the next). SO it's not that bad.
That's true. I don't suppose you'd like to code up an SGArchive class 
that does this, then? Obviously it won't be much use until PLIB is 
modified to support virtualizing disk operations, but i'd be curious to 
see how a 'base.tar.gz' performed at startup compared to the unpacked 
files...

Alas, I wasn't able to find any open-source projects that have already 
written a single-source-file, decode only tar impl ... which is 
annoying.

Oh, I just did some browsing of the SSG loaders  they're full of 
fopen / fseek  calls. Damn. Much work to be done there, I think.

James

--
We are all in the gutter, but some of us are looking at the stars.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Glut

2003-08-14 Thread James Turner
On Wednesday, August 13, 2003, at 09:56  am, Erik Hofman wrote:

Oh, I almost forgot. It's actively developed.
Nobody seems interested in anything but ssg in the plib list (and 
still).
For me this is the absolute crux of the argument; SDL has been and is 
used to develop commercial quality game releases, on Linux, FreeBSD and 
windows (and probably other platforms I don't know about). While 
there's nothing in GLUT that explicitly stops you from using it in 
large projects, having used both, I say positively that SDL is by far 
the more polished and elegant tool. A classic example being video-mode 
switching, which SDL implements well (and with a sane API and 
fallbacks) on all it's platforms. The existing full-screen mode has 
never worked for me, ever.

And while we can move code / implement features in PLIB, we're making 
work for ourselves. Eg, I ported the SDL OS-X joystick driver to PLIB. 
It works, but it's still not very good, because the PLIB js API is a 
bit limited in terms of the objects it describes. And PLIB's sound code 
certainly seems to be the source of many problems around here.

If the only issue is cygwin support, why not just switch to mingw? Is 
there any actual advantage to having win32 binaries that rely on 
Cygwin? Obviously the code is pretty close to building under mingw, 
given that Fred has been doing MSVC builds

All my opinion, naturally
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] request for comments?

2003-08-05 Thread James Turner
On Tuesday, August 5, 2003, at 05:23  pm, Curtis L. Olson wrote:

At the risk of tainting the discussion I will say that from my
investigation, Open Scene Graph seems to be the better choice.
There are people here locally that use it, and I know that other
flightgear developers have used it as well.  It seems to support all
the platforms that we currently support.  No one I've talked to seems
to know much about OpenSG and the one web link I found
(http://sgi.felk.cvut.cz/~pavlicm/Dipl/sw.htm) seems to put Open Scene
Graph ahead in terms of performance (based on a single test which
doesn't say too much actually.)
OpenSceneGraph looks much better than I remember, but it's also worth 
looking at OGRE, which is being (very) actively developed.

http://ogre.sf.net/

Is the place to start. Note that OGRE is a bit more 'gamey' than the 
other systems mentioned, notably it supports DirectX in addition to 
OpenGL. I'm not really sure if being more game-orientated would be 
considered a bonus or not for FlightGear.

Also, I'm far more concerned about getting rid of PLIB / GLUT for our 
OS interaction, than the graphical shortcomings of SSG. There are a 
couple of obvious replacements: SDL, SDL, or just possibly, SDL.

:-)

This would remove various limitations on joysticks (SDL supports hats), 
number of sound channels (SDL has a mixer), video mode-switching (SDL 
knows how to make X do that, quite apart from on Win32 or OS-X)

Perhaps most importantly, SDL gives the application back it's event 
loop.

Oh, and the the OpenSceneGraph FAQ lists SDL as a candidate rendering 
layer, for people who're finding GLUT a pain.

Of course switching both the scene graph and the OS-abstraction at the 
same time would be silly : one could either switch to SDL, and 
initially retain SSG, or alternatively, try and get OpenSceneGraph 
working alongside the rest of PLIB. Not sure which makes more sense.

All my opinion, naturally.
James
--
They are laughing with me, not at me.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] 747 Panel Feedback

2003-07-24 Thread James Turner
A few comments, after playing with the 747 panel a bit more. Firstly, 
I'd just like to say how amazing it is, given the non-impact on the 
frame-rates, smoothness and clarity of the text, and so on. It's just 
lovely.

Now, on with the nit-picking. Note many things I'm going to suggest 
probably require some level of C++ coding (even if it's just exposing 
more properties), and given sufficient arm-twisting I might even look 
at them myself. I've looked over the panel files, but I find the 
relation between the 3d models and the panel a bit hard to grasp...

Also note my 'experience' is based on the PMDG 777 for Fly!, but I 
assume Boeing glass cockpits don't vary much.

- The PFD auto-pilot annunciation is lacking supported for armed modes 
(in white, rather than green text). Eg, when in heading mode, and 
engaging a NAV mode to intercept a VOR radial, NAV should be displayed 
in white above (below?) the still-green HDG until the radial is 
intersected.

And the more common case, in V/S mode, heading towards a commanded ALT, 
ALT should be displayed in white. The whole reason I'm writing this is 
because I subconsciously found it very disturbing to enter a target 
altitude and not see ALT there in white (I've obviously spent way too 
much time with the PMDG 777 in Fly!).

- The speed trend indicator bar is missing; obviously this requires 
code and probably FMS interaction to be accurate, though I suspect a 
first order approximation [trend-velocity = velocity + 
(current_acceleration * 5.0)] would be enough. Again, it wasn't till I 
sat and thought about this I realized it was missing, but it made my 
flying much worse (on a manual throttle)

And now a couple of 'please's

- I really need a visual indicator of flap position, either the lever 
itself or the EFIS page showing the flap 'bar'. And related to that, is 
the 747 missing some detents? I'd expect 1,2,5,10,15,25 (and maybe 
40?). It seems like there's only three detents at the moment, and I 
keep ballooning on approach picking the wrong one.

[anyone who points out a good visual indicator of flap position would 
be switching to the external view gets a sullen look from me]

Oh and, if we're being clever, updating the safe Vmax marker on the 
speed-tape based on the current flap setting would be wonderful (yes, 
I'm a lazy person who uses that to schedule flap retraction on 
climb-out). But of course, this requires code and aircraft-dependent 
data (though maximum rated speed for each flap setting is usually given 
in pilot manuals)

When we finally get an FMS, it will of course compute notches on the 
speed tape for flap retraction, given the gross weight of the aircraft 
and so on  but that's *a lot* of C++ coding.

- I *really*, *really* need the ADF indicator on the NAV display. 
Especially intersecting an ILS localizer, I keep over-shooting because 
the 747 turns so slowly, when normally I'd use a handy ADF to work out 
when I'm almost on the glideslope and hence start turning in.

Anyway, that's more than enough nit-picking. I'll go back to lurking 
and bouncing the 747 down runways..

HH
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] 747 Panel Feedback

2003-07-24 Thread James Turner
Are you talking about the xml files for 3d animation?  The objects 
refered
to in the xml are specific polys on the display.  For example the 
apalt1 on
the PDF might refer to the first digit on the AP Altitude setting 
display,
apalt2 the second digit.  For the most part they are numbered right to 
left,
where 1 is the rightmost digit.
Ah, I didn't realize you could 'address' individual polygons this way...

This is the way it should work.  But I don't have the ARM displays in 
there
yet.  BTW when waiting for NAV intercept is it just HDG (and not HDG 
SEL)
annunciated?  IIRC selecting NAV in the autopilot currently sets the 
aircraft
on a course 60 degrees off the radial.  When it hits the radial it 
switches to
a heading that follows the radial.  There is some voodoo I put in 
there a long
time ago to make sure the 747 didn't overfly the radial.  Any 
suggestions on
how this mode should actually work?  Also, at what point (degrees from
radial?) is the radial considered intercepted?
HDG SEL is right, I think. here's how I remember it working in the PMDG 
777:
assume no LNAV mode is active, or HDG SEL is; providing you have a 
valid NAV 1 signal,
and the line projected from the current position of the airplane along 
the heading at some point intersects the radial, I think NAV mode will 
arm. Certainly it always has when I've tried. It obviously can't be a 
pure angle cutoff,
because you might be flying very close to the radial, but almost 
parallel to it, and NAV should still arm.

Anyway, the NAV mode stays armed until you get 'close' to the radial, 
at which point it activates and executes the turn to bring the aircraft 
onto the radial's heading. I'm not sure how 'close' is quantified, but 
in the PMDG 777, it never over-shot, so it must be a bit cleverer than 
a fixed distance.

Actually the autothrottle is now outputing a trend value.  I'm just 
not sure
exactly how the graphics should look.
It's a green purple line on the speed tape, with an arrow at it's top / 
bottom indicating the speed in K seconds (I think K = 5, but it might 8 
or 10). The other end of the vertical line is fixed at center of the 
speed tape. Visually, you use the height of the line to judge the 
plane's acceleration.

I googled for 'boeing PFD' on images.google.com, and some of the pics 
include the speed trend line. Also, some of them also show the yellow 
right-hand speed-tape border than indicates warning speed regimes, and 
the red dots that indicate danger speeds.

I'll be doing an EICAS display that will have that.  Also there's a 
center
console thing,  not sure when the center console will get done.
Are the number of flap setting and the detents correct, btw?

- I *really*, *really* need the ADF indicator on the NAV display.
Especially intersecting an ILS localizer, I keep over-shooting because
the 747 turns so slowly, when normally I'd use a handy ADF to work out
when I'm almost on the glideslope and hence start turning in.
Again,  I need more info.  I'm not really sure what it should look 
like or how
it should work.  If you can help, I'll add the features.
Ah, the ADF is pretty easy, it's just a green arrow on the NAV display, 
with the the head in the 'compass ring' pointing at the NDB, and the 
tail (which is forked) also in the track. I can't remember if there's a 
solid line between the head and tail or not.

Hopefully, Dave Culp or someone else who's looked at these things for 
too long can fill in more gaps, or correct any mistakes I've made.

HH
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] boeing 747-400 3d cockpit

2003-07-20 Thread James Turner
On Sunday, July 20, 2003, at 02:07  pm, Jim Wilson wrote:

So basically I'm saying that if you want to model a 747-400 series, the
General Electric CF6-80C2-B1 is the probably one you want.
I am reasonably sure the RB211 is an option, because British Airways 
always spec Rolls-Royce engines, in a minor display of nationalism.

Oh, and the cockpit is very, very nice. I've been waiting for the day I 
can fly jets without the HUD, and it seems like great progress is being 
made. Anyway want to set the 747 cockpit as the default for the Fokker, 
airbus and 737, at least for the time being? Or does the nature of the 
3d cockpit make that hard?

HH
James
--
We are all in the gutter, but some of us are looking at the stars.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] New Sutro tower in CVS

2003-06-21 Thread James Turner
On Friday, June 20, 2003, at 09:19  pm, Frederic Bouvier wrote:

The highest point of the bay area is in CVS :

http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-sutro-sf.png
I appreciate this is a dangerous precedent to set, nominating requests, 
but : the buildings that *really* stand out are not the big 
skyscrapers, but the 'edge' buildings and bridges. Notably the Coit 
tower (though it's hill isn't very noticeable with our current DEM 
data), the Ferry Building at the end of market, and Candlestick park.

On flying the actual approach, though, the most visible objects by a 
long, long way are the bridges. The approach I've always flow into SFO 
has been down over Marin / Napa, coming quite close to pacific coast, 
then turning inland (with the golden gate bridge visible to starboard), 
then turning south-east once almost central over the bay, (parallel to 
the 28L/R runways) flying over the oakland bridge (bay?) bridge and 
down as far as the dunbarton bridge. Once past this there's a long 
U-turn onto final, which brings you back over the dunbarton bridge at 
what feels like quite a low altitude (still 2000 feet, I suppose).

So in general, you don't have a sense of individual buildings, but more 
the pattern of green and built-up areas, but lots of water (which we do 
pretty well) and the bridges.

That said, if the auto-gen could use some hinting data to place rings 
of bigger buildings towards 'centre points' of cities, we'd get the 
sense of city 'mass' much better. (Oakland would probably need one 
centre-of-density to look about right, SFO would need a couple, as 
would London)

HH
James
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] New release

2003-06-06 Thread James Turner
On Saturday, June 7, 2003, at 12:45  am, matthew Law wrote:

Nice to see the 0.92 release made it on to flightsim.com quickly.
Although it's dominated by FS2002, any publicity is good publicity as
they say.
Though this is a slippery slope, what about avsim.com? (Which I 
consider to be marginally higher quality, though they're both FS2002 
heavy)

HH
James
--
The real enemy is the gramophone mind, whether or not one agrees with 
the record that is being played at the moment.

___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] setting fuel load

2003-05-30 Thread James Turner
On Thursday, May 29, 2003, at 01:05  pm, Erik Hofman wrote:

Jon Berndt wrote:

The reset file sets the current *dynamic* state.  I suppose we could 
(for
JSBSim standalone) set actual fuel load in a script, but if that's 
not done
right we might still end up with a user going: why don't my plane 
start?
I see. There are some conflicting requirements here.
Maybe JSBSim should use the pre-defined value as an initial value and 
provide a function call to override it by the user (program).
This issue (JSB needing to set values that FG also wants to set) has 
come up before, and I'm unclear why we can't always do the following:

1. JSB sim reads config file (maybe sets fuel load, etc)

2. FG reads -set.xml file, and potentially over-writes some JSB sim 
values

3. Everyone is happy.

Am is missing something here? Obviously bits of the -set.xml files may 
need to be loaded before the JSB (or yasim or UIUC) file is loaded, but 
in general I'd always expect to be able to over-ride any values they 
specify from the  -set file.

Is this what already happens, and the fuel thing is simply a bug, or is 
there some ordering constraint I'm unaware of?

HH
James
--
That which does not kill me has poor aim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Corrupted p51d textures on windows

2003-05-28 Thread James Turner
On Wednesday, May 28, 2003, at 07:08  am, Frederic Bouvier wrote:

I also had a hard time remembering how to start the engine. I finally 
found
the
magneto switch on the panel and hopefully it has hotspot because keys 
'('
and ')'
are not working on my system although they are present in my 
keyboard.xml.
Is it
the same for you ?

Umm, this is embarrassing, but after hunting around for quite a few 
minutes, I couldn't find the magneto switch ... where is it?

HH
James 'it must be on the overhead panel, beside the IRS ...'  Turner
--
The real enemy is the gramophone mind, whether or not one agrees with 
the record that is being played at the moment.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] fgLoadAircraft build failure

2003-03-29 Thread James Turner
cvs up -dP as of 30 minutes ago,

Making all in Aircraft
make[2]: Entering directory `/home/jmt/FGFS/FlightGear/src/Aircraft'
source='aircraft.cxx' object='aircraft.o' libtool=no \
depfile='.deps/aircraft.Po' tmpdepfile='.deps/aircraft.TPo' \
depmode=gcc3 /bin/sh ../../depcomp \
g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src  
-I/usr/X11R6/include  -g -O2 -D_REENTRANT -c -o aircraft.o `test -f 
'aircraft.cxx' || echo './'`aircraft.cxx
aircraft.cxx: In function `bool fgLoadAircraft(const SGPropertyNode*)':
aircraft.cxx:143: `bool fgLoadAircraft(const SGPropertyNode*)' was 
declared
   `extern' and later `static'
aircraft.hxx:62: previous declaration of `bool fgLoadAircraft(const
   SGPropertyNode*)'
make[2]: *** [aircraft.o] Error 1

OS is Suse 8.1, gcc version 3.2.

I don't get why aircraft.cxx defines fgLoadAircraft as a static inline, 
since both of these seem wrong; it's a large function to inline (and 
not called frequently, I assume), and it's been declared in a public 
header file.

HH
James
--
You whine like a mule. You are still alive!
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] fgLoadAircraft build failure

2003-03-29 Thread James Turner
On Saturday, March 29, 2003, at 05:57  pm, James Turner wrote:

I don't get why aircraft.cxx defines fgLoadAircraft as a static 
inline, since both of these seem wrong; it's a large function to 
inline (and not called frequently, I assume), and it's been declared 
in a public header file.
Silly me, forgot to add, removing the static inline keywords from 
aircraft.cxx means I can build fine, though switching doesn't seem to 
affect the aircraft model (and hence, the 3d panel). Anyway, I guess 
this is work in progress, so not too worried about that (waiting on a 
new graphics card so I can properly use FG again, the 3d panels pushed 
my geforce 1 over the edge...)

HH
James
--
Whenever a friend succeeds, a little something in me dies.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] base package cvs update failing...

2003-03-17 Thread James Turner
Doing 'cvs up' in fgfsbase. (flags are -dP)

cvs server: Updating .
cvs [server aborted]: cannot stat /tmp/cvslck: No such file or directory
cvs [server aborted]: cannot stat /tmp/cvslck: No such file or directory
Have I done something dumb (been away from my FG box for 2 weeks, it 
worked before then) and has failed every time from it since I got back 
(Friday). Also get and identical error when I do the update on my 
iBook. So if it's me, it's not the machines or the OS.

Hope this isn't completely uninformative, I don't know much about the 
internals of CVS.
HH
James

--
That which does not kill me has poor aim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] DAFIFT navids

2003-02-21 Thread James Turner

On Friday, February 21, 2003, at 02:27  pm, David Megginson wrote:


1. For VORs, we're interested in the slaved magnetic variation; you
   can always ignore the actual one, since we calculate that inside
   FlightGear anyway.


Already done



2. Entries for TACANs have only a channel, not a paired VHF
   frequency.  By trial and error, I've figured out how to get the VHF
   (I think):

snipped scary conversion

Err, I'm not sure this is correct. the VORTACs have an explicit 
frequency as well as a channel, and a straight TACAN isn't receivable 
using a VHF NAV radio, is it?

3. Entries for civilian DMEs also have only a channel.  You can use
   the same formula as you used for TACANs, but you have to add
   0.05MHz to every one (I don't know why, but that is the pattern I
   found on the charts).


I'm again not clear about this, I assumed these were 'DME only' 
military installations.

4. You have to split the NDB/DME entries into two to make them usable
   for FlightGear.  The DME channel will be provided, so handle it as
   above to get a paired VHF frequency (tuning the NDB will never
   automatically tune a DME).


I haven't done this, but right now I don't believe the radiostack logic 
works this way. I think it
simply looks for the 'isDME' flags on FGnav.


5. Non-U.S. VORs don't have a range provided, but they do have the
   usage code -- you can kludge a range from that (I used 200 nm for
   'H' or 'B', 20 nm for 'T', and 50 nm for anything else).


I was going to do this, but various people indicated these values were 
bogus and we'd be better using the 'practical approximation' you and 
Norman discussed a few weeks back.




I don't need any arm-twisting to dump Metakit -- these are tiny
databases for modern computers (that 20-second porn video clip your
roommate/son/neighbout just watched probably needed several times as
much memory as all our nav/arpt data put together).




Yes, please.  I'd also be interested in ILS.


Supporting new types is trivial. I would greatly prefer to switch the 
airport data over too, simply for consistency in the data set. Can 
anyone establish what (if anything we would lose by doing so?)

HH
James


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Navaids and fixes from DAFIF

2003-02-21 Thread James Turner

On Friday, February 21, 2003, at 02:12  pm, David Megginson wrote:


We should also consider whether we want to compress the DAFIFT files.
They take much more disk space uncompressed, but presumably CVS
updates would be significantly faster, since they would exchange only
deltas (or does the whole file come anyway?).


I was assuming we wouldn't ship the DAFIFt files at all, but instead 
use wget / PLIB's http client to pull them down automatically. But in 
any case, I'm using Simgear's gzip_ifstream so just gziping the dafift 
text files will work fine too.

--
That which does not kill me has poor aim



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] DAFIFT navids

2003-02-21 Thread James Turner

On Friday, February 21, 2003, at 03:23  pm, Curtis L. Olson wrote:


The DAFIFT doesn't have taxiway data.  Beyond that, it would be
interesting to compare the X-Plane data set vs. DAFIFT to see what
airport X-Plane has that are not in DAFIFT.  Much of the X-Plane data
is hand entered, especially for areas outside the USA.



I'm a bit confused by this : why can't we get the runway data from 
DAFIFT and the taxiway data from ... oh

.. wait...

it won't match up, will it?

Nevermind, I'll leave the airport data for now!
/me learns an important lesson about trying to be too clever.

James



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Boeing 747 cockpit

2003-02-17 Thread James Turner

On Saturday, February 15, 2003, at 11:19  pm, Jim Wilson wrote:


The two possible options that come to mind are as follows:

1) Use the current 3D Modeling system.
2) Take code from the opengc project and change it so that it gets data
directly off our property system (property paths configurable).  The 
idea then
would be to load these using Andy's panelnode code that currently 
loads the 2D
panel into 3D cockpits.  I'm thinking that these could be special 2D 
panel
types and there could be a separate panel class (inherited from a 
general) for
each glass display.  Any comments?

My plan was to add a bunch of new panel element types, though at some 
stage we are going to need some big chunks of custom code. For example, 
for the KLN-89b, the screen is essentially a 4-line, 20? character 
display, so I was figuring on an ncurses-like markup of fields, pages 
and lists, all of fixed character positions and dimensions. This will 
work really well for the [M]CDUs of big jets too.

But even the KLN-89b has the dreaded NAV4 mode, which provides a 
graphical map of the flightplan, waypoints, airspace boundaries an so 
on. I was mentally planning to cross that bridge when I got to it, but 
obviously it'd be nice to share code with other similar displays.

Basically, I think the currently panel method (a tree of elements we 
place) is essentially right model (i.e declarative, not just procedural 
bits of openGL). We would need quite a few custom elements in this 
approach, and NAV (map) displays are a special problem, but I think the 
other stuff is pretty doable (tapes, number fields, artificial horizon) 
in a tuneable way. And would also map closely to a XML-ified HUD.

Indecisively,
James

--
The lack of planning on your part does not constitute to an emergency 
on mine


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Hmmmm

2003-02-17 Thread James Turner

On Monday, February 17, 2003, at 04:21  pm, Jon Stockill wrote:


http://www.linux.org.uk/diary/ if anyone has the ability to translate.



According to my native welsh friend (who also hacks the kernel, so I 
assume the technology is correct to):
'Too many collisions, DRI collides too much when playing Flightgear, 
cars colliding in front of the house'



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Updated set of goals?

2003-02-10 Thread James Turner

On Monday, February 10, 2003, at 10:09  am, Erik Hofman wrote:


Rendering
-

snip

* Material edge blending


This one, and some fractal subdivision of soft-edges, would give far 
and away the best visual improvement for the current data set, in my 
opinion.  The issues get fairly complex though (this is what I tried to 
do for my final year project, and didn't get very far at all). What 
you'd 'like' to do:

- use a generic coastline texture for sea boundaries (and a 'narrower' 
one for non-tidal inland water)
	- use shore gradient to pick a rocky texture, and, just maybe, VMap 
sand/mudflat land coverage to get decent tidal zones (of course then 
people will demand correct tides ... yukc)

- blend the major 'massy' land use types together, based on their type.
	- fields / agricultural areas have sharp edges and mostly straight 
boundaries
	- snow / rock / moorland / pasture tends to have very rough edges
	- urban areas have rough transitions of empty but non-agricultural 
land and smaller 'chunk' sizes.
	- forrest have varying edges based on whether they're natural or 
managed!

So this gets to be quite a major task very quickly, and your polygon 
count is soaring through the roof all the time. The attribute data in 
the VMap files can help, eg it differentiates between parkland (hard 
edges) and open grassland, natural vs managed forests, and so on. 
Making sensible guesses is still a huge undertaking and guaranteed to 
go badly wrong in  some places.

HH
James

--
You whine like a mule. You are still alive!



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Question about METAR updates

2003-02-09 Thread James Turner

On Sunday, February 9, 2003, at 01:25  am, Ima Sudonim wrote:


Is it possible to use a metar file to give flightgear the current 
weather conditions for the world.  Are there special setup or options 
required to set this up?  Are there any mac os x compatible apps (java 
probably ok, too) to download metar info periodically (from 
http://weather.noaa.gov/weather/metar.shtml ) so that flightgear can 
(possibly) use it?


I was actually looking at this (on a complete whim) the other day. It 
looks to be fairly easy, if you can assume the existence of wget / curl 
on the system. Otherwise, you need to write a bit of FTP functionality 
(probably a trivial amount, though). Also, I didn't look at the actual 
weather code inside FG but based on the command line switches I think 
gluing it in will be doable.

That said, I've got quite enough on my plate with the flightplan / 
flightcomputer stuff to look at this (sorry).

HH
James

--
Morbo finds all humans pathetic


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] CVS FlightGear and plib 1.6 (was Mac OS X: at a loss)

2003-02-08 Thread James Turner

On Saturday, February 8, 2003, at 03:23  am, Jonathan Polley wrote:


Hmm, that's odd.  Out of the box, the version of the Mac joystick code 
that is in CVS does not compile.  As I reported to the plib group, if 
I incorporate the non-CVS versions of jsMacOSX.cxx and js.h, I get the 
following errors in the FlightGear joystick code:

ld: Undefined symbols:
jsJoystick::read(int*, float*)
_CFArrayApplyFunction
snipped lots of CoreFoundatioon / IOKit symbols 

_kCFAllocatorDefault

I've been trying to help David Drum get his FlightGear to build and he 
discovered that adding -framework Carbon to the Makefile reduces the 
link errors down to

ld: /Users/david/FlightGear/FlightGear-CVS/lib/libplibjs.a(jsMacOSX.o) 
illegal reference to symbol: _IOCreatePlugInInterfaceForService 
defined in indirectly referenced dynamic library 
/System/Library/Frameworks/IOKit.framework/Versions/A/IOKit

Sorry, I thought I'd covered this : you need to add '-framework IOKit 
-framework CoreFoundation' to configure.ac, around link 168. I've 
attached my version of configure.ac, let me know if you have any other 
problems.

HH
James




configure.ac
Description: Binary data

--
The lack of planning on your part does not constitute to an emergency 
on mine


Re: [Flightgear-devel] Does SGRoute.distance_off_route() work?

2003-02-07 Thread James Turner

On Friday, February 7, 2003, at 03:57  am, Norman Vine wrote:


John A. Gallas


I was just wondering if the subroutine
SGRoute.distance_off_route() calculates accurate
results (or even reasonably usable results for
navigation in fgfs) for waypoints on a wgs84 system.
I've run some tests and it seems okay, but I'm no
expert - can someone verify this?


This is a *much* better approximation
http://williams.best.vwh.net/avform.htm#XTE


Just to add, in my local tree I've got an FGRouteBase which (I hope) 
supersedes the SGRoute stuff totally. I spent ages trying to come up 
with a better 'distance off route' calculation (trigonometry not being 
my strong point), clearly I should just have asked here. Whatever I do 
is going to have to be compatible with SGRoute (but I don't think 
inheritance from it is going to work, since my routes aren't 'flat', as 
they can incorporate chunks of other routes, i.e airways and 
procedures), but let me know if you'd like to see the code (it's 
alpha-quality and incomplete but loads a route from XML fine, and basic 
traversal is working too. Adding the distance and course and 
distance-off-route computations could be done tonight if it would be of 
interest).

HH
James

--
Whenever a friend succeeds, a little something in me dies.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Live property picker

2003-02-07 Thread James Turner

On Thursday, February 6, 2003, at 02:10  pm, David Megginson wrote:



I think that we can centralize this and make it invisible to JSBSim
and other suppliers of property values.  Polling inside the property
manager makes sense, since

a) it will be done only on demand (when someone assigns a listener to
a property),

b) it will be done only once for each property, no matter how many
   other routines are listening to it,

c) it will create no extra work for anyone.



I'm happy to have a go at this, or do you (David) want to take a look? 
i agree it's far and away the best suggestion I've heard in terms of 
non-impact on the code, efficiency and so forth.


--
Morbo finds all humans pathetic


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Live property picker

2003-02-06 Thread James Turner

On Thursday, February 6, 2003, at 01:56  am, David Megginson wrote:

If so, seems like we're kind of shooting ourselves in the foot  or 
am I just being super-anal and should just poll them as Jim Wilson 
suggests?

This is a good discussion to start.  I'm inclined to eliminate tying
altogether and have every module set properties explicitly; what does
everyone else think?

Couldn't agree more, but I think this is likely to be unpopular. We can keep tying if we have an efficient 'notifyTiedValueChanged' method, which should be a no-op if there are no change-listeners registered on the property, and otherwise should run through them.

Tony Peden wrote,

I'd really like to see tying stay in.  I'm not sure we ever would have
incorporated the property tree into JSBSim without it.

I don't understand why

xPosNode.setFloatValue( x ) 

is so much worse than

my_tied_xPos_float = 

apart from being a bit verbose. And the advantage is, it forces you to appreciate (when you do the set) that some extra working is going to get done (listeners being invoked for now, who knows what else in the future)


Jim Wilson wrote,

Ummm...it's not polling, it's just updating the data.  Same as many of the
subsystems do every frame.  Polling is a contious loop that waits for
something to happen.  Like I said,  if we're not displaying the prop_picker
then it should
not be updated.

Well, I take polling to mean, going and looking at a value over and over again (one 'look' per frame). That works fine, and I'm *not* trying to argue an efficiency point (sorry if my original email came across that way, since that's how most people seem to have taken it). It's an issue of dataflow in the program : should it be driven by the people updating the values, or by people reading them? 

Basically, I can envisage lots of things the ChangeListener  API is perfect for, whether you're observing a value that changes one a week or 50 times a second, but right now those things won't work because some % of the properties don't tell you they've changed. Now, we could always flag some properties as 'immediate' I suppose, but that seems like a hack. There's nothing wrong with the current API, we just ought to make all the property nodes meet the contract it defines, or we need to remove change listeners from the API and have everyone poll / update as you suggest.

HH
James
--
That which does not kill me has poor aim


Re: [Flightgear-devel] Live property picker

2003-02-06 Thread James Turner
On Thursday, February 6, 2003, at 10:16  am, Frederic BOUVIER wrote:


Aren't the C++ opperators the perfect place to add this kind of action
to tied properties?


I had the same idea reading the message from James.
imagine that template (we are not against templates, aren't we ? ;) :

template class T
class tied_value
{

snip quite reasonable template idea

}

Then replace every tied values with that template :
  change :
double xPos;
  into :
tied_valuedouble xPos;

You get the picture ?


I do, but this is not the problem (as I understand it). The tie-ing 
system is 'low-invasion' for existing code / code which may not be part 
of FG, and works well with existing state variables. Your template / 
operator overloading fix the syntax, but I sort of think that's worse, 
because people may not realize what they're doing will be more 
expensive than assigning to a double. But the main problem is people 
now need to pull in your template and the property node headers into 
places they don't want to.

The impression I have is that a bunch of code uses 'tieing' to expose 
lots of internal variables directly. I'd prefer an explicit 
'publishing' phase, i.e calls to setValue. Of course your template 
works fine too, if you're prefer the syntactic sugar.

HH
James

--
That which does not kill me has poor aim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] CVS FlightGear and plib 1.6 (was Mac OS X: at a loss)

2003-02-05 Thread James Turner

On Wednesday, February 5, 2003, at 01:22  pm, Jonathan Polley wrote:



The solution, for me at least, was to revert back to the CVS version 
of plib and overwrite the src/js directory with plib 1.6's (as the 
current Mac joystick code is in a major broken state).  Hopefully, 
David will have a chance to see if it fixes his build problem as well.


Err, the JS code is fine for me now (and for Ima too, I think), once 
you replace js.h and jsMacOSX.cxx with the ones I posted to plib-devel 
a few days ago. If these do not fix any problems you're having, then 
**please** post something to plib-devel or email me directly. Since 
getting things checked into plib CVS seems to be rather slow, I'd 
rather get the files confirmed working for people before requesting 
another commit.

FWIW, CVS of 'everything' is working on my iBook, updated today, but I 
have a bunch of local mods to simgear/flightgear (in addition to the 
plib JS updates) : let me know if you want them. (I'll start feeding 
them to Curt / David soonish anyway I think)

HH
James

--
They are laughing with me, not at me.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Live property picker

2003-02-05 Thread James Turner

On Wednesday, February 5, 2003, at 05:42  pm, Jim Wilson wrote:


Currently, the property tree knows about changes only when someone
changes a value through it; when a property is tied to C++ code, the
valueChanged() method is never fired.



Sounds like a better technique would be to just reread the current
directory's values once every 5 frames or some such thing.  It'd be 
pretty
quick.  Actually, every frame wouldn't be bad.

I'm pretty adamant that's the wrong way to do this, we're reduced to 
polling. Being anal for a second, SGPropertyNode is an interface, and 
therefore is supposed to make some guarantees about it's behavior. One 
of these is that changeListeners are correctly invoked. Sure the 
property picker dialog can do polling, but that's wasteful for 
infrequently changing values. If there's a performance issues with the 
core values needing to notify listeners, that's something we need to 
address too.

BTW, I assumed listeners worked, because I figured several things, such 
as updating panel state, the telnet property browser and so on used the 
changeListeners: are they actually all using polling?!

If so, seems like we're kind of shooting ourselves in the foot  or 
am I just being super-anal and should just poll them as Jim Wilson 
suggests?

HH
James
--
We are all in the gutter, but some of us are looking at the stars.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] DAFIFT progress

2003-02-03 Thread James Turner
Okay, so I have FG working with the DAFIFT NAV and WPT data (replaces 
default.fix and default.nav). Now, I need some advice:

- What things to test that may have broken. I've extended 'testnavs' 
quite a bit and everything in there works, but this is a minute sample 
compared to what's out there. So, any suggestions for things to try? 
Other than 'fly around a bit, tuning the radios lots'..

- I uncovered some API inconsistencies between the fixlist and the 
navlist (some routines taking degrees, others radians, for lat / lon) : 
which do we prefer? (I'll fix the offenders)

- I'm getting a bunch of odd records from the DAFIFT NAV file: they 
have no frequency defined (which renders them rather useless except as 
waypoints). They appear on my SimCharts from Jeppesen, along with 
frequencies. Examples:

In the UK:
	SAT
	ODH

In the US:
	VBG
	TOL
	SSC
	PAM

In the netherlands:
	TWN
	SSB

At least the UK ones all have the 'TAC' prefix on my SimCharts. So  
does anyone know what these things are? I'm guessing it's something 
military related. The have frequencies in the VOR range (eg 117.7 Mhz 
based on SimCharts). Now, I can happily ignore them, but I'd like to 
know what I'm looking at before I do that.

- The current code detects the datafile format dynamically, so with a 
trivial patch to fg_init, I can dynamically use FG_ROOT/DAFIFT instead 
of FG_ROOT/Navaids  if the DAFIFT files are present ... assuming I do 
this, shall I go ahead and send my changes out for some wider testing? 
Curt / Dave, which of you is less busy?

- Next stop, airways  and I almost have a 737 to fling about them, 
thanks to Dave Culp :-)

HH
James

--
That which does not kill me has poor aim



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] TACANs (was DAFIFT progress)

2003-02-03 Thread James Turner

On Monday, February 3, 2003, at 05:30  pm, Mally wrote:


The UK ones appear to be TACANs at Odiham and St Athan:
http://www.nightstop.freeola.com/beacon%20decodes/beacon%20decodes.htm


Thanks for this, I've now done a bit more background reading on TACANs..


In the netherlands:
TWN
SSB
At least the UK ones all have the 'TAC' prefix on my SimCharts. So ...


You are right, its TACAN.
They will be replaced by ILS this year.


So, armed with the knowledge that TACANs are UHF, not VHF, and that 
they use military channel codes, I went and looked at the DAFIF fields 
again ... and guess what the field two after FREQ is? Yeah, it's the 
channel. Boy do I feel silly.

Of course, this leaves one problem / task (especially for the A4 and 
harrier pilots): does anyone fancy adding a TACAN receiver to the 
radio-stack? I'll add in another field on the FGNav class, and do the 
right thing for VORTACs, now that the light-bulbs have switched on in 
my addled head. Actually, it'll be two fields: an unsigned int channel 
ID and a flag for X / Y band, whatever they are. Oh, and these things 
can be mobile, for example on a carrier. If anyone fancies doing that, 
FGNav list is going to need some work, it's not quite set up for navids 
that don't stay put.

HH
James

--
The lack of planning on your part does not constitute to an emergency 
on mine


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] TACANs (was DAFIFT progress)

2003-02-03 Thread James Turner

On Monday, February 3, 2003, at 07:40  pm, David Megginson wrote:


It's more complicated than that.  DME receivers (which are UHF) can
use TACANs to get distance information -- usually, you do that by
tuning in a fake paired VOR frequency.  For example, if I tune my DME
to 108.8, or slave it to a NAV radio tuned to 108.8, I get distance
readings from the UPP TACAN at CYOW, even though there's no VOR.  Can
the paired frequency be deduced from the channel?


Right now, I think the answer is no. I was hoping that such TACANs 
simply listed the fake frequency in their FREQ column, but I've got 
checks for that in place and I'm not hitting them (just got that code 
working).

That said, the UPP TACAN is not listed in NAV.TXT, if you know of any 
others, please let me know and I'll check. (Or did you mean UUP, 
'Uplands'?)

HH
James

--
Whenever a friend succeeds, a little something in me dies.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] OT: question about Atlas build - missing files on MacOS X

2003-02-03 Thread James Turner
On Tuesday, February 4, 2003, at 01:38  am, Ima Sudonim wrote:


I can't find any information on building Atlas from CVS to use with 
flightgear. I've modified configure.ac to get past autogen.sh and 
configure. I have the following build problems.

I'll give Atlas a shot today :-)



LoadPng.o: Where/what is png.h


Get libPng via Fink, hopefully Atlas has a ./configure --with-libpng= 
option, otherwise we'll need to add one.
'fink install libpng' or pick it from the list using dselect. Or you 
can just build it from source, Apple already supply 'zlib' which libpng 
requires.

MapMaker.o: What is dirent.h? The problem is the uint parts of this 
struct
This sounds a bit strange, possibly pulling in sys/types will help 
(as Bert Dreihuis suggested) but I think that should have been done 
automatically..

I am using MacOS 10.3 with 12/2002 dev tools, gcc 2.95, latest plib, 
fg from cvs, simgear is recent

Is there any reason you're using 2.95 rather than 3.2? It's a much 
better compiler for C++
And unlike other OS-s, switching back and forth is simple.

HH
James

--
That which does not kill me has poor aim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Mac OS X: at a loss

2003-01-31 Thread James Turner
On Friday, January 31, 2003, at 05:14  am, David Drum wrote:


OK, both of you that are left reading this, thanks.

/me looks around the room and waves



I'll make a long story short: every attempt I have made to compile
FlightGear, whether 0.9.1 or from CVS, fails in the final link
in the same way: ld is unable to resolve the symbols gen_leaf and
ssgVtxTable::ssgVtxTable.  I have attempted the compile in every
permutation I can imagine, which is not a few.  More importantly,
I have attempted the compile on a fresh install of OS, etc. with as
little as possible installed.  Same error.  I can only conclude that I
am introducing the problem somewhere in the same way each time.

I am installing:
- Mac OS X 10.2.0 (minus all extra languages and applications)
- Mac OS X Update Combo 10.2.3
(at this point I change my shell to bash)
- Dec 2002 Dev Tools CD (plus BSD SDK)
- StuffIt STD 7.01 OS X Install
- Fink 0.5.0a
(at this point I add the Fink init.sh to my .bashrc, and source it)
- cvs-1.11.2.tar.gz (to support fink, installed via fink)
- dlcompat-20021117.tar.gz (to support fink, installed via fink)
- X4211src.tar.bz2 (via fink)
(everything below is installed in a work directory in my $HOME)
- plib-1.6.0.tar.gz
- metakit-2.4.3-33.tar.gz
- SimGear (via CVS)
- FlightGear (via CVS)



Umm, I am going to bet a moderate amount of money that CVS plib will 
help, though you may need a patch from me to make the OS-X joystick 
code compile. Simgear CVS needs a few tweaks to build too, again I have 
a diff. Also, I find that metakit 2.4.3 doesn't work, I have to use 
2.4.8 to get it to build correctly.

And again, there are some local mods for flightgear. Otherwise, 
everything looks sounds. I can send you unified diffs for Simgear and 
PLIB anytime, and giving them some testing would be good. I haven't 
actually tried to build FG in a while, been doing other FG hacking on 
linux. I did have it all up and running a couple of weeks ago, though.

Hope this helps,
James

--
You whine like a mule. You are still alive!


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] Naivd frequency / Magnetic variance

2003-01-31 Thread James Turner
So, I've got the basic FGNav structure being constructed from a row in 
the DAFIFT NAV.TXT file. A couple of the fields are giving issues:

- it looks like the scaling of ADF frequencies in the Robin Peel data 
is wrong: they're in KHz? (eg 340.0), whereas the VORs are in MHz (eg 
109.8), but there's a uniform scaling of 100 applied  this seems a 
bit odd to me. I'd rather 'freq' was just the frequency in Hertz.

- All the navids in the DAFIFT have a supplied Magnetic Variance, so I 
need some help dealing with the format. It's basically:
 E/W (direction)
degrees variation (actually deg / min / tenths of minute, but I can 
convert)
year / month stamp.

Now, what I'm wondering is whether I can do anything with the year / 
month stamp to update the variation? Oh, and what's the sign convention 
for our magvar values? +ve = East, -ve = West?

Anyway, the DAFIT stuff is going well, I'm able to pull in lots of 
extra data which will be useful for ATC and the like, as well as 
reception quality: there are things like guaranteed service ranges / 
volumes, transmitter wattages and the like.

HH
James

--
There is no such thing as a humble opinion.



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] FW: Cygwin Build problems

2003-01-29 Thread James Turner
On Wednesday, January 29, 2003, at 02:43  pm, Curtis L. Olson wrote:


SimGear/FlightGear configure used to automatically add /usr/local/lib
to the library search path.  That was removed because apparently it
causes gcc-3.2 to gripe?  Someone needs to explain the gcc-3.2 problem
so that we can get this resolved in a way that works for everyone


SNIP


Same /usr/local/lib issue ... apparently we don't include
/usr/local/lib in order to appease the gcc-3.2 gods, but then it never
get's included at all ... why does gcc-3.2 detest having to look in
/usr/local ???


The problem is that /usr/local/include and /usr/local/lib are in the 
default *system* search path, so
#include simgear/foo.h works. When you manually add 
/usr/local/include to the search path using -I, you're adding it as a 
*user* path, with a totally different order in the search.

Apparently, this can cause very obscure breakage (don't ask me to 
provide an example). As a result, GCC 3.2 prints out a *huge* warning 
for every single source file it processes, which is very, very 
annoying. Hence, the correct solution is only to add /usr/local/include 
(or lib) on systems where it is not already in the search path. Which, 
it sounds like, includes cywgin.

Hope this is of some help.
HH
James



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] RFC: Radios and Instrumentation

2003-01-29 Thread James Turner

On Wednesday, January 29, 2003, at 03:18  pm, David Megginson wrote:


With the move, I'm also considering cleaning up the radio code a bit,
and introducing better lags for the ADF and VOR needles (they're a
little too snappy right now).



Just one thing : when I get to the KLN-89b, I'm going to need support 
for optionally back-driving the instruments from the GPS's output (this 
couple if required in order for the installation to be certified for 
GPS precision approaches). Such operation is usually done via simple  
NAV/GPS toggle switch on the panel somewhere. I *think* the only thing 
I need to drive is CDI deflection, since you can't get GS from a GPS 
approach (please, someone, correct me if I'm wrong here, all I have to 
go on is Fly! and the Bendix-King PDF manual..)

In larger aircraft, I assume there's other things that can be 
back-drive, even before you get up to a full PFD / NAV display. So, I'd 
just like to establish how we differentiate between 'signal output from 
the radio' versus 'signal input to the HSI instrument', so that someone 
can trivially add the toggle switch to their panels.

HH
James

PS - reading the DAFIFT is going well, more on that in a few days.

--
We are all in the gutter, but some of us are looking at the stars.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Partially Offtopic: Help open up the FSD protocol

2003-01-27 Thread James Turner

On Monday, January 27, 2003, at 01:27  pm, Michael Basler wrote:


Neither my flying skills nor my spare time are sufficient for taking 
part in
Vatsim :-(

Me too ...



However, I know that there are a few competiting networks a la Vatsim
present or just emerging and I read several quite sharp debates (from
various parties) about stealing ideas, data, members from each other 
in
Newsgroups right now (instead of sharing services, members, 
controllers...).

There's also IVAO? which is a different group but uses the same software


If you can do it, I'd propose developing our own (albeit small) 
service. If
not more, than just a few controllers around KSFO as a proof of 
concept.

The problem will all these system, as I see it, is the lack of people 
willing to control. What I think would work much better is a web of 
servers, but with the ATC manned by AIs. Of course in the long run 
people could write a controller client and take over from the AI at a 
position, but basically the system could function happily without any 
human controllers. Now, writing those ATC AIs is non-trivial, but it's 
something that's in the pipe-line anyway.

This also suggest a 'Quake-like' approach for local traffic and ATC : 
simply start a local server running the ATC ai and some plane AIs, and 
connect the main program to it over loopback. (Quake-like as in this is 
how every modern first-person shooter based on Quake or Unreal is set 
up. Bots on the server are indiscernible from other live players, and 
single-player works as expected, but is in fact running a server too).

Comments?
HH
James

--
The lack of planning on your part does not constitute to an emergency 
on mine



___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] FGNavList searching

2003-01-26 Thread James Turner
On Saturday, January 25, 2003, at 09:55  pm, Curtis L. Olson wrote:


I made some changes to the FGNavList class, take a look and see if it
will work better for your needs.


Thanks, I already saw this and picked it up, it works great! I'd done 
the research (okay, 2 minutes with grep) to see who the users of the 
NavList code were, but obviously that hadn't made me realize they were 
all doing their own range checks. Anyway, thanks again.

HH
James

--
We are all in the gutter, but some of us are looking at the stars.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] FMC / GPSs [ was End of /steam approaches]

2003-01-26 Thread James Turner

On Sunday, January 26, 2003, at 05:12  pm, Norman Vine wrote:



Hopefully we can now actually start implementing a realistic 
'navigation computer',
as is present in most modern GPS units and autopilots that, since the 
hopefully the
AP is no longer dependent on hardwired to steamed input from C172 
instrumentation



Actually, I'm rapidly approaching that area, from a different 
direction. I'm working on extending the Navaids layer to know about 
structured route data, namely DPs / SIDs / STARs / GPS approaches / 
airways, but most importantly, flight plans. I've got an XML format I'm 
reading in, and am about to start exposing the data to the property 
system.

One of my 'route' types is FGActiveFlightPlan, which is designed to 
provide a good chunk of the runtime state necessary to drive either a 
KLN-89b-style thing, or a full blown FMC (c'mon Dave Culp, I need that 
737!).  What I'm hoping is that with our new-found scripting 
capability, a lot of the 'device specific' logic I was probably going 
to do in code can be done in scripts in the instrument files, providing 
my C++ code exposes rich enough data to the property system (shouldn't 
be a problem).

BTW, there is another important goal of my flightplan code that it 
should be common to multiple subsystems. most notably that AI aircraft 
and full-blown ATC systems should be able to work from the same base 
classes. FMCs and such are my initial goal, though.

Current plan of attack is :
- get the flight plans exposed into the property system. Will look 
something like

/ .. owner system /flightplan[n]/origin/icao = EGPH
/ .. owner system /flightplan[n]/origin/runway = 06
/ .. owner system /flightplan[n]/destination/icao = EDDF
/ .. owner system /flightplan[n]/desintation/runway = 27L
/ .. owner system /flightplan[n]/eta = .. computed time
/ .. owner system /flightplan[n]/waypoints[0]/id = TLA
/ .. owner system /flightplan[n]/waypoints[0]/alt = 8000  (this is a 
crossing restriction)
/ .. owner system /flightplan[n]/waypoints[1]/id = DCS
/ .. owner system /flightplan[n]/waypoints[2]/id = ... etc

(all subject to change!)
The owner system might be an FMC / GPS unit, an /aircraft[n]/ai node 
for an AI plane,
an /atc/aircraft/ node, or so on.

- one the above is done (hopefully in the next few days), I'm going to 
hook up the waypoint following in the current autopilot to follow my 
loaded flight-plans. Once that's done I need to try adding route 
sub-structures, i.e airways (easy) but then also the different kinds of 
DPs, STARs and GPS / non-precision approaches. My intention is to write 
loaders that parse some of the existing formats out there, so we leech 
the data available for the various FS2000/2 flight computer devices.

Anyway, that's about where I am, none of this stuff is in CVS yet, if 
anyone else thinks they're working in an area where they might benefit 
from this, let me know and I'll see about getting it committed. 
Otherwise I'll keep the damage confined locally, the API, such as it 
is, is changing daily at the moment!

HH
James

--
Morbo finds all humans pathetic


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] FMC / GPSs

2003-01-26 Thread James Turner

On Sunday, January 26, 2003, at 08:47  pm, Norman Vine wrote:


You are aware of these
http://www.ibiblio.org/fplan/
http://www.ibiblio.org/fplan/avdbtools/guide.html

and FlyWay at
http://www.bellz.org/progs.html


Ah, I'm aware of things like them, but I guess my terminology is wrong. 
What I'm working on is the in-memory representation of routes. 
Obviously I'm expecting to write importers for any formats that exist 
already (eg SquawkBox and FS2k2), as well as the XML one I've knocked 
up. I know there's a Java one for X-Plane which is also popular, again, 
I'm happy to steal people's data formats. If someone wants to write an 
in-process flight planner, they can do that too (hell, I might even get 
around to it myself in a year or so...)

Right now, I'm not really worrying about that, but rather pulling all 
the disparate bits of data (navaids, airports, aero data, position 
info) to make up the working flight-management system. I simply had to 
do the 'flight plan' bit first because that's something that wasn't 
already there (at least, the logic in Simgear/Route and the existing 
simple flight plan format isn't nearly semantically rich enough for my 
purposes).

I am aiming to eventually support the full feature set of Boeing and 
Airbus CDUs, so I need things like 'smart' joining of airway and 
procedure segments into chunks of route, on-the-fly (re-)selection of 
arrival runways and procedures, auto-sequencing of missed-approach 
segments, holding at waypoints (including picking up default hold 
parameters for holds on STARs), and so on (and on...). Hopefully the 
classes I'm doing up are flexible enough to handle all this and more, 
since I certainly don't know all the things every FMC out there can do.

Anyway, I'm calling a sequence of waypoints you *could* fly a 
'flightplan', and a set you *are* flying (i.e once you get clearance, 
pick an aircraft and fuel load, and know your departure runway and 
procedure) an 'active route'. If my terminology is horribly skewed, 
please correct me sooner rather than later :-)

HH
James
--
We are all in the gutter, but some of us are looking at the stars.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


[Flightgear-devel] Missing FGCondition.h

2003-01-24 Thread James Turner
My Linux and OS-X builds (cvs updated today) are both failing in 
FDM/JSBSim/FGSwitch.cpp, because FGCondition.h is not found ... a 
missing cvs add?

HH
James

--
We are all in the gutter, but some of us are looking at the stars.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] KSFO International Terminal

2003-01-18 Thread James Turner

On Saturday, January 18, 2003, at 12:44  am, David Megginson wrote:


Michael Basler writes:


as an interim report, the guy with the FS98 add-on KSFO scenery did 
not
answer until now (but mail did not bounce either). I'll stay tuned, 
but
doubt he will... it's just been so long ago and he did never provide
upgrades for FS2000/2 .

I fear you'll have to find pictures and stuff somewhere else.

You're not willing to make a quick trip from Germany and take some,
then?  Where's your team spirit?



Actually, I'll be flying into KSFO at the start of march (going to GDC 
again), so I can easily get snap away .. the problem is I'm unlikely to 
get good shots out the window of a 747, hopefully some good elevation 
ones of the terminal after touch-down though. It doesn't help that 
it'll be easiest for me to get you shots of the bit you already have, 
the international terminal.

BTW, I'd just like to point out that I saw the terminal model 'first', 
I was just keeping quiet :-P

Incidentally, if anyone fancies doing up EHAM (Amsterdam Schipol), I 
could try and get some shots of that too, though similar issues apply.

HH
James

--
We are all in the gutter, but some of us are looking at the stars.


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] Displaced thresholds

2003-01-18 Thread James Turner

That looks pretty similar to what I've been aiming for (screenshot of
current progress at http://www.nottingham.ac.uk/~eazdluf/taxidraw.jpg 
- and
yes I know its currently windoze only - its just a fast prototype
proof-of-concept and I'll port it to a multiplatform toolkit if it 
works).


It would certainly make sense to be able to import AFCAD files.  
However,
there may be issues concerning whether the airports are placed in 
exactly
the same location in FS2K2 and FGFS, and as regards the files, even if
permission could be obtained from some authors to use their files, I 
would
have thought that we would have to make absolutely sure that these
represented their original creation, and were not an 
extension/modification

Just wanted to provide some ideas based on the Fly! Taxiways Editor 
(which is an excellent tool, once you get over the learning curve..). 
Basically, you can import an airport diagram (bitmap), and define the 
lat/lon of two points on it (usually the start and end of major runways 
are easiest), and then trace over the image.

Where the tool gets smart is in laying out the graph structure (i.e one 
line per-taxiway), it automatically handles the generation of curved 
sections of tarmac, intersection markings on the centre-line, and so 
on. Basically it's doing a little bit of trig, and using some 
modifiable constants for radius of turns, but the end result looks much 
more 'real' than what FG has right now, with a fairly minor amount of 
work. (and from nearly identical data, I think)

I'd like to have a go at implementing the 'joining' algorithm, but I'm 
totally lost where to begin (at least that's my excuse).

Oh, and, as a random thought that's been bugging me in this area for 
ages, I think it'd be really cool (but virtually pointless from a 
simulation point of view) to support roads (and a accompanying AI 
graph) in any such editor too  nothing like having an errant 
baggage-truck zip or busload of passengers shooting over a taxiway to 
wake you up in the morning :-)

Hmm, having said it's pointless, it occurs to me it may have 
safety-training implications for pilots to teach them there's other 
things besides aircraft they need to watch out for. I'll leave such 
considerations to the real pilots though.

HH
James

--
We are all in the gutter, but some of us are looking at the stars


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


Re: [Flightgear-devel] main.cxx: glXGetProcAddressARB undeclared, and warnings

2003-01-04 Thread James Turner

On Saturday, January 4, 2003, at 05:01  pm, Curtis L. Olson wrote:


Carsten Hoefer writes:

Am Sam, 2003-01-04 um 00.19 schrieb Julian Foad:

That works for me, adding it just before the #include, like this:

   #define GLX_GLXEXT_PROTOTYPES
   #include GL/glx.h


However, defining internal symbols like this seems like a completely
wrong approach that will probably break things other places or for
other platforms ... there's got to be a right way to do this.  I'm
really going to drag my heels on adding this unless someone can show
me that this is the right way to do it.


I'm also on Suse 8.1, and I'd just point out that, from reading the 
GL/glx headers (which may the nVidia ones, I'm unsure), it looks like 
we might want to be using glXGetProcAddr instead of the ARb version if 
it's present. Maybe that's complete nonsense though.

HH
James

--
That which does not kill me has poor aim


___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel


  1   2   >