Re: [Flightgear-devel] CVS question...
* [EMAIL PROTECTED] (Matthew Law) [2002.09.19 17:47]: After many newbie-fied mistakes and misunderstanding I have now setup /home/cvsroot on my linux box and checked out up-to-date copies of the devel releases into: /home/cvsroot/SimGear /home/cvsroot/FlightGear /home/cvsroot/fgfsbase I also have a stable and working FGFS 0.8 which I'd like to keep (to play with if I bugger up the CVS version!). How do you guys compile a development version beside a stable one without it interfering? In other words what do you specify to ./configure when compiling these sources to keep them from starting a fist fight with each other? I don't think anyone replied to you main question, so I'll share with you how I have everything setup. First of all, I never alter my real CVS directories -- I work on copies of them. For example, here's my FG paths: /archive/incoming/flightgear/cvs/fgfs/Makefile /archive/incoming/flightgear/cvs/fgfs/FlightGear/ /archive/incoming/flightgear/cvs/fgfs/local/ /archive/incoming/flightgear/cvs/fgfs/localbuild/ My Makefile looks like this: all: rm -rf ./local ./localbuild cp -a ./FlightGear local mkdir localbuild lndir -silent ../local ./localbuild So, what I do is cd to /archive/incoming/flightgear/cvs/fgfs/FlightGear and update my local CVS checkout. Then go back a directory and run `make` to get a clean development copy. I do all my local work in the localbuild/ directory. If I make changes, I cd back into the real CVS directory and do a diff like so: $ diff -urN . ../local I make no promises about this setup -- no warranty whatsoever. :-) I only do small updates and bugfixes so I never really need to keep a development tree around for a long time. You'll have to talk to some of the other real developers if you want to do that. :-) -- Cameron Moore / One cannot guess the real difficulties \ \ of a problem before having solved it. / ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
From: Curtis L. Olson [EMAIL PROTECTED] Norman Vine writes: Curtis L. Olson writes: We might need to learn more about how the imposters are rendered. I don't think this is an issue of drawing the imposter once it is generated, but in generating the imposter in the first place. The Impostors are generated with regular OpenGL calls just like everything else and then read out of the back buffer into a texture which then serves as an 'impostor' for the real OpenGL object. eg you are substituting a glQuad for the entire set of calls that were made to draw the object initially. hence the name 'impostor'. You can see the impostors getting created after you find and follow the directions in this line in SkyCloud.cpp // Uncomment this swap buffers to visualize cloud illumination computation. Whatching these things get created gives you a GOOD ideaof how much work the 'impostor' is saving you Mark Harris mentioned that the back buffer requires a destination alpha for imposter rendering to work. Perhaps that's why things aren't great with a 16bit color buffer, you probalby aren't even getting an alpha channel there? Perhaps we can create another, 32bpp, context to render imposters instead of using the main one ? Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
Norman Vine writes: YES - because here is what I get if you render with 16 bit buffers http://rockfish.net/~nhv/fgfs/images/fgfs-screen-016.jpg http://rockfish.net/~nhv/fgfs/images/fgfs-screen-017.jpg Might help thinking about 'how' one might get a '3d' volumetric effect from what is essentially a ssgBillBoard :^) I think I understand. What about the suggestion from earlier to switch to a 32-bit buffer when creating an imposter, then back to 16-bit for ordinary rendering. Once the imposter has been created, the 16bpp display should be able to handle it fine (since it's just another texture with an alpha component). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
David Megginson writes: Is it possible to set up two separate contexts and switch between them? I don't know. I was thinking if you had two cpu's, you could have one thread running in it's own context/own cpu just drawing cloud textures, then passing them back to the main application which would take the new image and replace the old with it. But, you have to be a little careful if you only have one 3d card. You don't want two processes competing for that scarce resource ... the 2nd thread would need to do software rendering, or you'd need two cards and sort things out to make sure each process ended up on the right card, etc. etc. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
David,
We have a checken and egg problem here. We can query the depth buffer
bits. But we can't do that until the display is init'd and we already
have a valid opengl context. But, we need to know this info in order
to do the glut intialization properly.
We may need to fall back to a command line option and have the user
tell the application what to do.
Curt.
David Megginson writes:
Curtis L. Olson writes:
Mark Harris mentioned that the back buffer requires a destination
alpha for imposter rendering to work. Perhaps that's why things
aren't great with a 16bit color buffer, you probalby aren't even
getting an alpha channel there?
That's possible, but currently the problem is that FlightGear will not
start at all at 16bpp with --enable-clouds, because of this:
if ( fgGetBool(/sim/rendering/clouds3d) ) {
glutInitDisplayMode( GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE | GLUT_ALPHA );
} else {
glutInitDisplayMode( GLUT_RGB | GLUT_DEPTH | GLUT_DOUBLE );
}
Here's what I get:
GLUT: Fatal Error in fgfs: visual with necessary capabilities not found.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
Curtis Olson IVLab / HumanFIRST Program FlightGear Project
Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED]
Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] CVS question...
Matthew Law writes: I also have a stable and working FGFS 0.8 which I'd like to keep (to play with if I bugger up the CVS version!). How do you guys compile a development version beside a stable one without it interfering? In other words what do you specify to ./configure when compiling these sources to keep them from starting a fist fight with each other? I don't, personally. If I did, I would use a separate --prefix argument to each one and install it into an entirely different subtree. BTW, well done on the clouds guys they're coming along nicely and will look pretty sweet when they're done :-) I agree, but I'd be happier if they'd work with 16bpp as well as 32bpp (32bpp is too slow at 1600x1400 on my notebook). I guess I'd better pitch in soon rather than complaining. I think we might end up with a combination of the current texture approach and 3D clouds. For overcast, 3D probably doesn't make sense, since there's no hole to fly through anyway. Cirrus is a separate problem we'll have to address. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
Norman Vine writes: I doubt if any amount of fiddling would make the 3D clouds work well in anything less then 32 bit color, as the eye is VERY sensitive to grey. I'm looking for work-at-all, not work-well. I don't care if they're pretty, as long as I can scud around them. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
David Megginson writes: I don't understand enough about OpenGL, but why would alpha work at 16bpp in textures (like panel instruments or propeller disks) and not in clouds? We might need to learn more about how the imposters are rendered. I don't think this is an issue of drawing the imposter once it is generated, but in generating the imposter in the first place. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
Curtis L. Olson writes: We might need to learn more about how the imposters are rendered. I don't think this is an issue of drawing the imposter once it is generated, but in generating the imposter in the first place. The Impostors are generated with regular OpenGL calls just like everything else and then read out of the back buffer into a texture which then serves as an 'impostor' for the real OpenGL object. eg you are substituting a glQuad for the entire set of calls that were made to draw the object initially. hence the name 'impostor'. You can see the impostors getting created after you find and follow the directions in this line in SkyCloud.cpp // Uncomment this swap buffers to visualize cloud illumination computation. Whatching these things get created gives you a GOOD ideaof how much work the 'impostor' is saving you Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question...
Norman Vine writes: Curtis L. Olson writes: We might need to learn more about how the imposters are rendered. I don't think this is an issue of drawing the imposter once it is generated, but in generating the imposter in the first place. The Impostors are generated with regular OpenGL calls just like everything else and then read out of the back buffer into a texture which then serves as an 'impostor' for the real OpenGL object. eg you are substituting a glQuad for the entire set of calls that were made to draw the object initially. hence the name 'impostor'. You can see the impostors getting created after you find and follow the directions in this line in SkyCloud.cpp // Uncomment this swap buffers to visualize cloud illumination computation. Whatching these things get created gives you a GOOD ideaof how much work the 'impostor' is saving you Mark Harris mentioned that the back buffer requires a destination alpha for imposter rendering to work. Perhaps that's why things aren't great with a 16bit color buffer, you probalby aren't even getting an alpha channel there? Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS question
Curt, thanks for your help. I must be doing something wrong because after I do a cvs update, when I run make, it seems to recompile *everything* (which is of course very time consuming). It must touch all the cxx files or something for that to happen, even if they have not changed. I'll see if I can figure out why this is happening. Mark -Original Message- From: Curtis L. Olson [mailto:[EMAIL PROTECTED]] Sent: Wednesday, March 06, 2002 3:33 PM To: [EMAIL PROTECTED] Subject: Re: [Flightgear-devel] CVS question Boslough, Mark B writes: Now that I am modifying code, I have the need to keep it updated. I am a beginner at CVS, so I'm not sure I am doing things properly. Should I be doing CVS updates every day? That requires that I completely recompile and relink every day, is that correct? I want to make sure that I am organizing thinks in a way that doesn't cause me a lot of extra work at some point. Mark, There is a mailing list (flightgear-cvslogs) so you can get notified when ever the cvs repository has new changes committed to it. You may (or may not) want to take advantage of that depending on how closely you want to track what's going on. I'd think that if you ran cvs update once every day you'd be likely to get new changes just about time you ran it. Also, don't forget to check out a copy of the base package (via cvs) and run cvs update there as often as you run it on the source tree. If you are using our unix style makefile system (automake/autoconf) then it should track all the code dependencies and only rebuild code that changes (or depends on something that has changed.) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS question
Curt, You are right. Yesterday it recompiled so many files I thought it was recompiling everything. I updated again today after only one day and it only recompiled one file and re-linked, which is of course much faster! Do I need to rerun the scripts every time I update, or just rerun make? (sorry if this has been answered somewhere I should already have seen). Mark -Original Message- From: Curtis L. Olson [mailto:[EMAIL PROTECTED]] Sent: Thursday, March 07, 2002 10:39 AM To: [EMAIL PROTECTED] Subject: RE: [Flightgear-devel] CVS question Boslough, Mark B writes: Curt, thanks for your help. I must be doing something wrong because after I do a cvs update, when I run make, it seems to recompile *everything* (which is of course very time consuming). It must touch all the cxx files or something for that to happen, even if they have not changed. I'll see if I can figure out why this is happening. What happens if you just run make twice in a row? Also make sure that you aren't just compiling a *lot* of files instead of *all* the files. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS question
Boslough, Mark B writes: Curt, You are right. Yesterday it recompiled so many files I thought it was recompiling everything. I updated again today after only one day and it only recompiled one file and re-linked, which is of course much faster! Do I need to rerun the scripts every time I update, or just rerun make? (sorry if this has been answered somewhere I should already have seen). If the configure.in changes or you add new subdirectories, it's a good idea to run the autogen.sh script again. But otherwise, you should just be able to do a cvs update -d followed by make. Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question
Hi Mark, What I do is update occaisonally (once or twice a week sometimes more) and keep an eye on the logs (the web based ViewCVS is handy too) in order to know what others are working on. Before sending in code I'll update to current CVS again and make sure things still work. It is much easier for Curt and Dave if you've taken care of any merges and send in code that works with latest CVS. Best, Jim Boslough, Mark B [EMAIL PROTECTED] said: Now that I am modifying code, I have the need to keep it updated. I am a beginner at CVS, so I'm not sure I am doing things properly. Should I be doing CVS updates every day? That requires that I completely recompile and relink every day, is that correct? I want to make sure that I am organizing thinks in a way that doesn't cause me a lot of extra work at some point. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question
Boslough, Mark B writes: Now that I am modifying code, I have the need to keep it updated. I am a beginner at CVS, so I'm not sure I am doing things properly. Should I be doing CVS updates every day? That requires that I completely recompile and relink every day, is that correct? I want to make sure that I am organizing thinks in a way that doesn't cause me a lot of extra work at some point. Mark, There is a mailing list (flightgear-cvslogs) so you can get notified when ever the cvs repository has new changes committed to it. You may (or may not) want to take advantage of that depending on how closely you want to track what's going on. I'd think that if you ran cvs update once every day you'd be likely to get new changes just about time you ran it. Also, don't forget to check out a copy of the base package (via cvs) and run cvs update there as often as you run it on the source tree. If you are using our unix style makefile system (automake/autoconf) then it should track all the code dependencies and only rebuild code that changes (or depends on something that has changed.) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS question
Paul Deppe writes: A related question - after rebuilding with the makefile system, is there a way to make install only the files which have changed? For example, suppose there is only a change to a .cxx file in plib/ssg. I do a make, which rebuilds only libplibssg.a. But when I do a make install, all the header files are also installed with new dates. Then when I rebuild SimGear and FlightGear, make thinks that the header files have changed and recompiles everything which depends on the header files (which is just about everything). This effect ripples down from plib to SimGear to FlightGear to Atlas. It would save a lot of compile time if one could make install only the files which have changed. Is there a way to do this? Beyond identifying and copying just the changed files individually yourself by hand, I've never seen a way in unix to do this. If you know that there were changes only to a particular subdirectory, you could cd into and run make; make install from there. You don't have to run make or make install only from the top level directory. That's one way you can often somewhat limit the number of changed install files and contain the cascading dependency effect. Otherwise, it's a good time to go refill your cup of coffee or maybe poke your head out into the living room and confirm to your family that you still exist. (Expect some surprised looks the first few times you do this though.) :-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question
Paul Deppe wrote: A related question - after rebuilding with the makefile system, is there a way to make install only the files which have changed? For example, suppose there is only a change to a .cxx file in plib/ssg. I do a make, which rebuilds only libplibssg.a. But when I do a make install, all the header files are also installed with new dates. Are you sure? I was under the impression that the install program (and CVS, for that matter) preserved the date stamps on files. The stamps on the installed files should be the modification times in the archive. I might be wrong... Then when I rebuild SimGear and FlightGear, make thinks that the header files have changed and recompiles everything which depends on the header files (which is just about everything). This effect ripples down from plib to SimGear to FlightGear to Atlas. It would save a lot of compile time if one could make install only the files which have changed. Is there a way to do this? The existing build stuff, frankly, is designed for the simple case where a user wants to compile and install something once for use in the future. If you're doing development, it's probably not optimal. A little elbow grease to match your private habits is probably unavoidable. For example, I always use a custom --prefix for all my FlightGear stuff, never install the shared metakit library, and often write 1-liner build run and link scripts for whatever focused feature I'm playing with. For your specific situation (if it turns out that timestamps really are your problem), you might try making symlinks from the install tree to the source tree, and skipping the make install step entirely. The core point being that you're never likely to find things packaged quite the way you want them. One of the central characteristics of being a geeky hacker type is a strongly held conviction that the rest of the world are idiots and are doing things all wrong. :) Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com Men go crazy in conflagrations. They only get better one by one. - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question
On Wed, Mar 06, 2002 at 05:17:42PM -0600, Curtis L. Olson wrote: Paul Deppe writes: A related question - after rebuilding with the makefile system, is there a way to make install only the files which have changed? For example, suppose there is only a change to a .cxx file in plib/ssg. I do a make, which rebuilds only libplibssg.a. But when I do a make install, all the header files are also installed with new dates. Then when I rebuild SimGear and FlightGear, make thinks that the header files have changed and recompiles everything which depends on the header files (which is just about everything). This effect ripples down from plib to SimGear to FlightGear to Atlas. It would save a lot of compile time if one could make install only the files which have changed. Is there a way to do this? Beyond identifying and copying just the changed files individually yourself by hand, I've never seen a way in unix to do this. If you know that there were changes only to a particular subdirectory, you could cd into and run make; make install from there. You don't have to run make or make install only from the top level directory. That's one way you can often somewhat limit the number of changed install files and contain the cascading dependency effect. Otherwise, it's a good time to go refill your cup of coffee or maybe poke your head out into the living room and confirm to your family that you still exist. (Expect some surprised looks the first few times you do this though.) :-) You wouldn't have any personal experience, here, would you? ;-) Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel -- Tony Peden [EMAIL PROTECTED] We all know Linux is great ... it does infinite loops in 5 seconds. -- attributed to Linus Torvalds ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question
On Wednesday 06 March 2002 07:17 pm, you wrote: snip quite the way you want them. One of the central characteristics of being a geeky hacker type is a strongly held conviction that the rest of the world are idiots and are doing things all wrong. :) Andy Hahahah! Quick somebody notify Bartletts ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] CVS question
A related question - after rebuilding with the makefile system, is there a way to make install only the files which have changed? For example, suppose there is only a change to a .cxx file in plib/ssg. I do a make, which rebuilds only libplibssg.a. But when I do a make install, all the header files are also installed with new dates. Are you sure? I was under the impression that the install program (and CVS, for that matter) preserved the date stamps on files. The stamps on the installed files should be the modification times in the archive. I might be wrong... Andy, I checked the file modification dates and confirmed that make install does not preserve the dates on installed files (sure wish it did) at least on my Cygwin setup. Please correct me if I'm wrong, but the make install appears to use the script install-sh which is part of the automake package. The script is fairly complicated (to me) but buried in it is the cp command which does the actual installation. I think that the cp command is passed in using the make variable CPPROG. Perhaps the install-sh script (or the make variable) could be modified to use cp -p which preserves the file date and other attributes. Thanks to all who responded to my question! Paul Paul R. Deppe Veridian Engineering (formerly Calspan) Flight Aerospace Research Group 150 North Airport Drive Buffalo, NY 14225 (716) 631-6898 (716) 631-6990 FAX [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS question
Now that I am modifying code, I have the need to keep it updated. I am a beginner at CVS, so I'm not sure I am doing things properly. Should I be doing CVS updates every day? That requires that I completely recompile and relink every day, is that correct? I want to make sure that I am organizing thinks in a way that doesn't cause me a lot of extra work at some point. Personally, when I'm working on something, I stop doing CVS updates because I want the code I'm developing against to be stable. However, when I've made progress, I grab a cvs diff to a separate file as a patch. Now that I've grabbed a context sensitive backup of my work, in case something terrible happens, I do the update and bring in everybody else's work. Then I look to see whether they broke what I was working on. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
