Re: [Flightgear-devel] CVS for OpenAL
I give up... could someone save me the suffering and mail me a tarball of openal they have to this address? I've decided cvs hates me lol... kind of reminds me of Martin's signature on all his posts!! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
On June 28, 2005 12:06 am, Ampere K. Hardraade wrote: On June 27, 2005 04:26 am, Erik Hofman wrote: Harald at one point added a check to make sure the RenderTexture context was actually available. It almost looks like this was a bit too drastic. Erik Interesting. I happen to keep getting an error regarding RenderTextuer context -- in both 16bits and 24bits color. I have done apt-get install --reinstall for XFree and Mesa already, but the error still presists. I have begun doing searches on Google for this error, but I haven't find anything helpful so far. Do you guys know what cause this error? Thanks in advance, Ampere hmm... I have tried removing, purging and reinstalling everything related to Mesa, but the error message about RenderTexture is still there. Mathias is the only other person who has the same problem as I have, and he/she is also using the r200 driver: http://baron.flightgear.org/pipermail/flightgear-devel/2005-June/037272.html I guess something in RenderTexture.cpp is incompatible with Radeon driver? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS for OpenAL
* bass pumped -- Wednesday 29 June 2005 08:46: I give up... could someone save me the suffering and mail me a tarball of openal they have to this address? I'll send you a *.tar.gz of my unmodified OpenAL dir including all CVS dirs. So you should (theoretically :-) be able to cvs up in there. Of course, you need to be logged in for that, but I'll also send my login line from ~/.cvs. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Ampere K. Hardraade wrote: hmm... I have tried removing, purging and reinstalling everything related to Mesa, but the error message about RenderTexture is still there. Mathias is the only other person who has the same problem as I have, and he/she is also using the r200 driver: http://baron.flightgear.org/pipermail/flightgear-devel/2005-June/037272.html I guess something in RenderTexture.cpp is incompatible with Radeon driver? That could be, or a driver problem (although I would expect it catch up earlier since the RenderTexture code is used by more projects. The funny thing is that I couldn't get pbuffers to work on my O2 myself, until I started using the RenderTexture class. Everything works like a charm now ... Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Ampere K. Hardraade wrote: Mathias is the only other person who has the same problem as I have, and he/she is also using the r200 driver: http://baron.flightgear.org/pipermail/flightgear-devel/2005-June/037272.html No, he isn't the only one. Did you try the same setup with XOrg instead of XFree86 ? I run XOrg-6.8.2 with the r200 driver most of the time and I can't remember expieriencing trouble that somehow matches your description. Probably I didn't create a comparable setup - would you like to describe in detail via private EMail which 'tuning' you choose to trigger this error ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Regarding buildings (was Shadows)
Am Dienstag 28 Juni 2005 18:42 schrieb Harald JOHNSEN: Martin Spott wrote: Frederic Bouvier wrote: Quoting Martin Spott : Look by yourself : http://terraserver.microsoft.com/image.aspx?T=4S=12Z=10X=706Y=5191W= 3 Oh, nice I think we urgently need a way to inject user-submitted landcover details into the process of scenery generation Curt, do you see a chance to accept geo-referenced shapefiles from users ? Martin. Since we are talking about scenary generation... Has no one wrote a converter from Taxidraw output to .btg ? Am I the only one frustrated because I can not (simply) edit a few airports and use the result imedialty ? From the terragear source I find it quite easy to do that, so if nothing exists I will write the converter. Mind that also the surrounding scenery tile .btg has to be edited, because it has to contain a hole exactly fitting the airport... Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..multi-X trick ideas,
Josh Babcock wrote: The only problem I had when trying this was keeping one from loading the other's libraries. Do you mean userland libraries or X server modules ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Ampere K. Hardraade wrote: On June 28, 2005 12:06 am, Ampere K. Hardraade wrote: On June 27, 2005 04:26 am, Erik Hofman wrote: Harald at one point added a check to make sure the RenderTexture context was actually available. It almost looks like this was a bit too drastic. Erik Interesting. I happen to keep getting an error regarding RenderTextuer context -- in both 16bits and 24bits color. I have done apt-get install --reinstall for XFree and Mesa already, but the error still presists. I have begun doing searches on Google for this error, but I haven't find anything helpful so far. Do you guys know what cause this error? Thanks in advance, Ampere hmm... I have tried removing, purging and reinstalling everything related to Mesa, but the error message about RenderTexture is still there. Mathias is the only other person who has the same problem as I have, and he/she is also using the r200 driver: http://baron.flightgear.org/pipermail/flightgear-devel/2005-June/037272.html I guess something in RenderTexture.cpp is incompatible with Radeon driver? Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d I also get this error, and am using the OS radeon driver with an r200 chip. No clouds either. In a possibly unrelated problem, when I turn on the new shadow code the entire view from the cockpit gets dimmer, but there is not appreciable effect outside the aircraft. Probably not related, but who knows. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Regarding buildings (was Shadows)
Thomas Förster wrote: Mind that also the surrounding scenery tile .btg has to be edited, because it has to contain a hole exactly fitting the airport... Thomas ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d How about blender importers for .btg and .dat files? I guess the ideal would be for a program that could take a .btg and .dat file and merge them regardless of there being a pre-existing airport-shaped hole in the btg and without having to use/preprocess any of the GIS data. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ..multi-X trick ideas,
Martin Spott wrote: Josh Babcock wrote: The only problem I had when trying this was keeping one from loading the other's libraries. Do you mean userland libraries or X server modules ? Martin. Mostly the userland libraries. IIRC it was easy to get Xorg to look at it's own directory for modules, but something about startx (I think) was mucking with LD_LIBRARY_PATH and a lot of the X enabled programs were crashing because they were loading libraries from the Xfree distribution. So is wasn't strictly an X problem, but still ... Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Josh Babcock wrote: Ampere K. Hardraade wrote: hmm... I have tried removing, purging and reinstalling everything related to Mesa, but the error message about RenderTexture is still there. Mathias is the only other person who has the same problem as I have, and he/she is also using the r200 driver: http://baron.flightgear.org/pipermail/flightgear-devel/2005-June/037272.html I guess something in RenderTexture.cpp is incompatible with Radeon driver? I also get this error, and am using the OS radeon driver with an r200 chip. No clouds either. In a possibly unrelated problem, when I turn on the new shadow code the entire view from the cockpit gets dimmer, but there is not appreciable effect outside the aircraft. Probably not related, but who knows. Josh No 3D clouds on an r200(9200) with the latest ATI(8.14.13) driver : No suitable pixel format. Shadows work nicely though : Simon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] Fedora Core 4 x86-64 and FlightGear
Pete Buelow wrote: I'm trying to build FlightGear for FC4 on an nifty new amd64 game machine. I used to fly on a slightly slower Athlon, but want to step up to the plate and see if things are that much better with my new video card and 64 bit processor. Here's the issue. [... a spot where a pointer is cast to an int ...] Yes, gcc 4.0 will not allow you to directly cast a pointer to an integer on systems where their sizes differ, due to the information loss problem (which is real in this case, as the value is used as an ID). I think I posted this a while back, but maybe I just remember thinking about doing it. On my build, I just hacked the casts (I think there are two, actually) to be of the form: (int)(long)pointerValue This double cast construction compiles and works. At least on my system, you can verify using pmap that there is no heap memory mapped to addresses that are equal modulo 2^32, so there is no possibility of collision. It really isn't an appropriate permanent solution, though. The ID values should be guaranteed to be unique on all platforms. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Airport LICJ disappeared from scenery files!!!
Hi, I downloaded scenery file e010n30.tgz which contains Italy terrain and airports but as soon as I zoom in the area surrounding airport LICJ, I don't see it any more ... it simply disappeared. There's no trace of LICJ.btg.gz either! LICJ is still present in apt.dat.gz There's something wrong with the scenery creation phase :-( Should this be reported to Curtis Olson? Well, I guess so :-( Btw LICJ is the main airport near Palermo city. There's LICP (very near the city center) too but it's a very small airfield, not for liners like LICJ, mainly used for tourist flights and helicopters. Roberto -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport LICJ disappeared from scene ry files!!!
Hi Martin :-) Could you post an MD5 checksum of the downloaded file ? Did you experience any strange messages while unpacking ? Of course I can, this is it: 55cefe52d8d2a6f573764fce46927e8a Source is ftp://ftp.flightgear.org/pub/fgfs/Scenery-0.9.8/e010n30.tgz BTW, I can confirm that LICJ is _not_ part of the e010n30 scenery area, How is it LICJ is not part of the e010n30 scenery area? Of course, the scenery area which contains LICJ is e013n38 which is contained in the e010n30.tgz file. I assure you LICJ is right in that :-) ICAO: LICJ 38°10'55N 13°05'58E Roberto -- 5 GB Mailbox, 50 FreeSMS http://www.gmx.net/de/go/promail +++ GMX - die erste Adresse für Mail, Message, More +++ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SGPropertyNode::removeChildren()
[cc'd to flightgear-devel, as this is clearly an architectural issue and not a bug report.] The basic issue as I understand it is that apparently SGPropertyNode::removeChild() has been (incorrectly, AFAICT) modified to ignore nodes that have a reference count greater than one, which interacts badly with the case where a Nasal script has created a Node object (which includes a refcounted pointer, obviously) that has yet to be garbage-collected. Melchior FRANZ wrote: removeChild() doesn't remove nodes with refcount != 1, nor their children (independent of their counter). After destroying the SGPropertyNode_ptr you return to count == 1 (i.e. only referenced by parent). Same state as before calling removeChild(). Nothing will be deleted by that. Why not? This sounds like a bug to me. What is wrong with removing a node that someone else is holding a reference to? When they free their reference, then it gets deleted. No. removeChild/ren() is correct. Just don't take guarded pointers from nodes that you want to remove. That's not possible in Nasal. You create the refcount in getNode(), and have no way to know whether the script intends to delete it or not. Let me put it more forcefully: if proper reference counting semantics are going to be removed from the property system, then the current Nasal props.Node interface WILL NOT WORK, and all code will have to be ported to the stateless getprop()/setprop() interface instead. Seriously: what is the bug being fixed by the ignoring the refcount thing? The whole idea behind reference counting is to *remove* the requirement for this kind of logic. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport LICJ disappeared from scene
Roberto Inzerillo wrote: Could you post an MD5 checksum of the downloaded file ? Did you experience any strange messages while unpacking ? Of course I can, this is it: 55cefe52d8d2a6f573764fce46927e8a Source is ftp://ftp.flightgear.org/pub/fgfs/Scenery-0.9.8/e010n30.tgz Looks good ! BTW, I can confirm that LICJ is _not_ part of the e010n30 scenery area, How is it LICJ is not part of the e010n30 scenery area? Of course, the scenery area which contains LICJ [...] I meant: I can confirm that LICJ is actually not covered by the scenery file that belongs to the e010n30 area :-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport LICJ disappeared from scene
BTW, I can confirm that LICJ is _not_ part of the e010n30 scenery area, How is it LICJ is not part of the e010n30 scenery area? Of course, the scenery area which contains LICJ [...] I meant: I can confirm that LICJ is actually not covered by the scenery file that belongs to the e010n30 area :-) I was already cool with the first answer :-) Anyway, I did post a msg in Terragear-devel ML. I hope I get some feedback there; I guess that is the right place to post the msg. I'm shure Curtis will take a look at that ... or is someone else paying attention to such kind of issues by now? Roberto -- Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie! Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SGPropertyNode::removeChildren()
* Andy Ross -- Wednesday 29 June 2005 19:49: The basic issue as I understand it is that apparently SGPropertyNode::removeChild() has been (incorrectly, AFAICT) modified No. The only modification was a name change. It's now called detachChild(). A new function has been added that does really remove a node with all children. You can still use detachChild() and get exactly the same buggy behavior as before. What is wrong with removing a node that someone else is holding a reference to? Well, the theory is that the property tree is there to inspect/access values. And the idea is that a remove function shouldn't only detach property nodes that are then secretly used behind the users back. If you want them to stay, don't remove them. If you want to remove them, don't tie a reference to them. I see your point, but you don't see mine. Should there be an option bool really = true? The current behavior is (if I understood Fred correctly) the way David had planned. The old removeChild() was just a (misnamed) solution for a different demand. When they free their reference, then it gets deleted. But it doesn't. That's the whole point. The SGPropertyNode_ptr destructor doesn't remove the node's children. Of course, it would have been possible to let it do that. But see above. No. removeChild/ren() is correct. Just don't take guarded pointers from nodes that you want to remove. That's not possible in Nasal. OK. So we are actually talking about a Nasal problem? :-} m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Regarding buildings (was Shadows)
On June 28, 2005 04:47 am, Frederic Bouvier wrote: On June 27, 2005 05:00 pm, Frederic Bouvier wrote: In the first, an oracle building cast its shadow on another one http://frbouvi.free.fr/flightsim/fgfs-shadow-1.jpg If I go forward a bit, the shadow disappear : http://frbouvi.free.fr/flightsim/fgfs-shadow-2.jpg Would it make sense to give the building a base (such as a parking lot) for future models? What do you mean ? http://ccrma.stanford.edu/~salauns/Oracle_building.jpg -Fred I mean the surroundings of the buildings within Oracle's property. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
On June 29, 2005 09:24 am, Simon Hollier wrote: No 3D clouds on an r200(9200) with the latest ATI(8.14.13) driver : No suitable pixel format. Shadows work nicely though : Simon I don't see any evidence of a shadow with my graphic card (ATI 9200SE). May be my graphic card doesn't support it. I don't see any Enable Shadow option either. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: SGPropertyNode::removeChildren()
Melchior FRANZ wrote: Well, the theory is that the property tree is there to inspect/access values. And the idea is that a remove function shouldn't only detach property nodes that are then secretly used behind the users back. If you want them to stay, don't remove them. Reference counting isn't about removal or detachment. It is a low level API convention that deals with *allocation*. This argument seems to be confusing the two. In this particular case, no one wants [the node] to stay. But some parts of the code may need to hold a *pointer* to the node in a place that is not accessible to the code making the removeChild() call. So you decrement the refcount instead during detachment (not destruction!), and the *library* decides when to destroy (not detach!) the object. Again: destroy (low level C++ concept) is not the same thing as remove (high level property concept). Think about it this way and things should be clearer. When they free their reference, then it gets deleted. But it doesn't. That's the whole point. The SGPropertyNode_ptr destructor doesn't remove the node's children. Again, the disconnect: I'm talking about deletion (i.e. whether the memory is freed or leaked), and you are talking about logical property stuff like where the node appears in the tree. These aren't the same concept. It might not be desirable to have SGPropertyNode objects that are detached from the property but still be live in the sense that reachable pointers can find them. You might hate this concept. It might be bad design. BUT IT MUST BE LEGAL! Otherwise you cannot have garbage collected property references. Otherwise you cannot have automatic deletion across C++ exceptions. Otherwise you cannot put a property node pointer on the stack at all and expect it not to leak. Otherwise you get NO VALUE WHATSOEVER from the nice refcounting implementation that David Megginson gave us. That's not possible in Nasal. OK. So we are actually talking about a Nasal problem? :-} It's not possible. It can't be fixed. You can blame me personally if you want, but nothing will make the current removeChild() implementation compatible with garbage collected Nasal nodes. The latter depends on the reference counting semantics*, while the former depends on a special case side effect** of our implementation. These are fundamentally incompatible metaphors. Pick one to eject, you can't have them both. * A standard concept that David Megginson implemented in the standard way; I had no trouble understanding what a SGPropertyNode_ptr was or how to use it, for example. As a result, Nasal has access to leak-proof and garbage-proof handles to property nodes (something that would basically be impossible without the refcount mechanism or something like it). This, I argue, is a feature and not a bug. ** Specifically, it assumes that the parent/child relationship in the property try is the *only* context in which the reference counting will be used, which is silly and breaks the really nice features that refcounting gives you. It is also false; if that were the case SGPropertyNode_ptr would not be a public API. Note all the other places that use it. Seriously: the removeChild() method is just buggy. It should never have cared about refcounting at all. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Attaching Views to Other Objects
-Original Message- From: Jim Wilson [mailto:[EMAIL PROTECTED] Hope this helps. Best regards, Jim Yes it does, Jim. Thanks. I'll see what I can make happen. Jim A. winmail.dat___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SGPropertyNode::removeChildren()
This can be changed by just removing two checks. And it's still far less buggy than the old version ... that you can still use (I can send you a patch that replaces removeChild with detachChild. ;-) I'm happy with everything except reverting to the zombie generator. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SGPropertyNode::removeChildren()
* Melchior FRANZ -- Wednesday 29 June 2005 21:48: it's still far less buggy than the old version ... that you can still use (I can send you a patch that replaces removeChild with detachChild. ;-) This is not entirely fair. The old version wasn't buggy. It did correctly what it wanted to do. It just didn't do what it implied it would do, at least not what 100% of its users in fgfs thought it would do. It left the whole removed subtree in memory, only detached from the tree. That's not what we want when we throw away all the unused joystick driver information. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: SGPropertyNode::removeChildren()
Andy Ross wrote: Seriously: the removeChild() method is just buggy. It should never have cared about refcounting at all. Andy, I have to agree with Melchior here. If you call removeChild you have the intention that it will stay in the tree until refcount becomes zero and then it will be deleted. If you call removeChild() and it just detached from the tree (without cleaning it up at some point) you won't even be allowed to access it using the property tree, even after the first call to removeChild(). It's just a matter of properly naming functions anyhow, and therefore the old behavior is available under a different function call: detachChild(). It makes clear to everybody who uses it that it actually detached a node from the tree, but not removes it from memory when calling it. If Nasal relies on that behavior it's just as easy as calling the proper function again and all should be set. If that's not the case then detachChild() should be modified, but as far as I know it does exactly what you are asking for. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: SGPropertyNode::removeChildren()
Erik Hofman wrote: Andy, I have to agree with Melchior here. If you call removeChild you have the intention that it will stay in the tree until refcount becomes zero and then it will be deleted. If you call removeChild() and it just detached from the tree (without cleaning it up at some point) you won't even be allowed to access it using the property tree, even after the first call to removeChild(). I have no objection to either of these scenarios. My objection is improperly overloading the reference count (which has *nothing* to do with trees or property values at all!) to implement it. If you guys need or want a bit that says leave in tree until condition X has occurred, then that's fine. But you can't use the refcount to do it, that's not what it's for. Reference counting is used to make sure that (a) memory is never freed when there are live pointers to it, and (b) live pointers never point to freed memory. Any other usage* is just wrong, and causes bugs**. * In this case: using the reference count to tell whether or not the node is in the tree or detached. ** In this case: Nasal can keep a refcounted pointer for a short time until it gets garbage collected and deleted, which make the node undetachable until the collector runs. Just call it something else, and leave the refcount value alone. What you guys are doing is not reference counted allocation. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SGPropertyNode::removeChildren()
* Andy Ross -- Wednesday 29 June 2005 23:42: Reference counting is used to make sure that (a) memory is never freed when there are live pointers to it, and (b) live pointers never point to freed memory. Any other usage* is just wrong, and causes bugs**. * In this case: using the reference count to tell whether or not the node is in the tree or detached. That's not what it's used for. Actually, it prevents nodes from disappearing from our property node memory representation -- which is the property tree. The old method was broken, and reverting to it is out of the question. Fixing the new one is, of course, desirable *if* it's broken. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: SGPropertyNode::removeChildren()
Melchior FRANZ wrote: Andy Ross wrote: * In this case: using the reference count to tell whether or not the node is in the tree or detached. Actually, it prevents nodes from disappearing from our property node memory representation -- which is the property tree. It sounds to me like these are saying exactly the same thing. Guys, please: The reference count is a count of pointers to an object. Nothing more. Making it mean anything else is *not* a reference count. Reference counting is a well-established idiom. Plib uses it. The auto_ptr uses it. It apperas in pretty much every textbook on C++. When I saw that the David's SGPropertyNode class implemented a refcounted pointer, I knew *exactly* how to use it, because it worked like all the other ones I have seen. And guess what? It worked. The new reference count semantics are not the same as the ones plib uses. They are not the same as auto_ptr, or the treatments in textbooks. And therefore they are confusing, and cause bugs. Changing the meanings of well-established idioms in critical infrastructure like the property system is just really bad design. Sorry, but it is. If you insist on re-purposing the reference count, then please rename it to something else (that is, after you've removed the props.Node interface from Nasal). Fixing the new one is, of course, desirable *if* it's broken. Huh? This whole discussion started when you reported that after the new changes, removing property nodes from Nasal was broken. The reason is that the change broke the refcount semantics that Nasal is relying on. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Tower view configuration
Hey All, I'm trying to configure a tower view in FlightGear that is offset in pitch such that the airplane appears above the center of the screen, but still tracks the position of the aircraft. I can't figure out how this is done, as the 'offset-pitch-deg' property seems to have no effect. Here is what I have in preferences.xml. If anyone knows what I'm doing wrong, please let me know. Thanks, Drew view nameHeads Up/name typelookat/type config eye-lat-deg-path/sim/tower/latitude-deg/eye-lat-deg-path eye-lon-deg-path/sim/tower/longitude-deg/eye-lon-deg-path eye-alt-ft-path/sim/tower/altitude-ft/eye-alt-ft-path eye-roll-deg-path/sim/tower/roll-deg/eye-roll-deg-path eye-pitch-deg-path/sim/tower/pitch-deg/eye-pitch-deg-path eye-heading-deg-path/sim/tower/heading-deg/eye-heading-deg-path at-model type=booltrue/at-model at-model-idx type=int0/at-model-idx pitch-offset-deg-0.944272/pitch-offset-deg ground-level-nearplane-m type=double9.0/ground-level-nearplane-m default-field-of-view-deg type=double8.0/default-field-of-view-deg x-offset-m type=double0/x-offset-m y-offset-m type=double0/y-offset-m z-offset-m type=double0/z-offset-m /config /view ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Tower view configuration
From: Drew [EMAIL PROTECTED] Hey All, I'm trying to configure a tower view in FlightGear that is offset in pitch such that the airplane appears above the center of the screen, but still tracks the position of the aircraft. I can't figure out how this is done, as the 'offset-pitch-deg' property seems to have no effect. Here is what I have in preferences.xml. If anyone knows what I'm doing wrong, please let me know. That negative 9 tenths of a degree offset-pitch-deg value is going to be hardly noticable. If I recall correctly, the offsets in lookat mode still manipulate the angle of the camera, but the target is always constant. Thus it gives you the impression that the camera is teathered to the target, and rotates around as if on the inside of a sphere where the target is the center of the sphere. Try some larger numbers (e.g. 35 degrees) and you should see something change. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Tower view configuration
Thanks, I'll try that, but I don't understand your description. The view origin is fixed in space as it is. Since the field of view is only 8 degrees horizontally, I figured the .9 degrees would shift the target upwards by about 1/6 the height of the image. That's what I'm trying to do, anyway. In any case, I'll try what you suggested tomorrow when I'm at my computer, and see for myself what it does. Drew On 6/29/05, Jim Wilson [EMAIL PROTECTED] wrote: From: Drew [EMAIL PROTECTED] Hey All, I'm trying to configure a tower view in FlightGear that is offset in pitch such that the airplane appears above the center of the screen, but still tracks the position of the aircraft. I can't figure out how this is done, as the 'offset-pitch-deg' property seems to have no effect. Here is what I have in preferences.xml. If anyone knows what I'm doing wrong, please let me know. That negative 9 tenths of a degree offset-pitch-deg value is going to be hardly noticable. If I recall correctly, the offsets in lookat mode still manipulate the angle of the camera, but the target is always constant. Thus it gives you the impression that the camera is teathered to the target, and rotates around as if on the inside of a sphere where the target is the center of the sphere. Try some larger numbers (e.g. 35 degrees) and you should see something change. Best, Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About 3D Clouds
Hi, On Mittwoch 29 Juni 2005 08:45, Ampere K. Hardraade wrote: hmm... I have tried removing, purging and reinstalling everything related to Mesa, but the error message about RenderTexture is still there. Mathias is the only other person who has the same problem as I have, and he/she is also using the r200 driver: http://baron.flightgear.org/pipermail/flightgear-devel/2005-June/037272.htm l I guess something in RenderTexture.cpp is incompatible with Radeon driver? Note that I get the same error with ati's binary driver! I went to a computer store last week and bought a radeon 9800 since they sold that one out. Installed the ati driver hoped to see clouds and shadows. No joy, apart from the fact that you need to dig for patches to the kernel driver before you can compile and even then I still cannot shut down X cleanly. I get a kernel oops ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
