* [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/fgfs
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 co
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 w
Curtis L. Olson writes:
> I've never tried switching the bit level of the rendering buffers in
> OpenGL, but this is something you typically set when you initialize
> your opengl context. I've never heard of anyone changing this on the
> fly ... especially not every frame. I can't say with
David Megginson writes:
> 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
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 w
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 t
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
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 firs
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 regula
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 everyth
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 impos
David Megginson
>
> Unfortunately, that's not an option -- to my knowledge, I have the
> most powerful GPU available in a notebook
the newer ATI Radeon Mobility and the GeForce4 440
are much faster but AFAIK this one smokes em all
http://www.dell.com/us/en/bsd/products/model_precn_precn_m50.htm
Norman Vine writes:
> The problem is there is not much room for an alpha chanel in 16 bits
> so AFAIK the card manufacturers and the OpenGL board aren't
> spending much effort making this kind of thing work well
I don't understand enough about OpenGL, but why would alpha work at
16bpp in text
David Megginson
> 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
On Thu, 2002-09-19 at 15:53, David Megginson wrote:
> 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
> > interferin
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 Megginson
> Matthew Law writes:
>
> > 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
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
> com
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
? (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 t
ee 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
> > 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
On Wednesday 06 March 2002 07:17 pm, you wrote:
> 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 Bartl
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/
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 d
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
> 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.)
A related question - after rebuilding with the makefile system, is there a
way to "make install"
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
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 easie
32 matches
Mail list logo
