Hey
You're the man!
That is it.
Setting bits-per-pixel to 32 makes the models throw phantastic well looking
shadows! At least for my box with the binary ati driver.
But doing that kills performance totaly on both machines I develop on.
Switching on shadows halves the framerate with the ati bina
Hi,
On Montag 27 Juni 2005 20:03, Curtis L. Olson wrote:
> For what it's worth, on my 16bit depth buffer laptop, the new 3d clouds
> used to work, but sometime around this time frame they stopped working.
> I now get a no valid render buffer message. I wonder if this check is
> actually too agre
Hello,
I'm having a problem with sound in FlightGear 0.9.8. When I rename my
.asoundrc to .asoundrc-bak, fgfs works fine and sounds great. But when I
try to use my .asoundrc I get line after line of "native_blitbuffer:
select error occured" and intermittent sound (kind of a stuttering sound).
Hi Matthias,
On Freitag 01 Juli 2005 13:22, Matthias Boerner wrote:
> I'm pretty new to this list. I subscribed to this list several days ago
> after Mathias Froehlich encouraged me to do so.
:)
Hehe, my dear collegue!
Welcome doing helicopters.
... looking forward to that EC145.
Greetings
Dave Culp wrote:
Anyone know the altitude of the approach lights in FlightGear? They should
be the same as the threshold, about 13 feet. They seem to be much lower
here, so they're covered by the light structures.
The altitude of the approach lights vary based on viewer distance
(and/or a
On Samstag 02 Juli 2005 09:40, Erik Hofman wrote:
> Dave Culp wrote:
> > Anyone know the altitude of the approach lights in FlightGear? They
> > should be the same as the threshold, about 13 feet. They seem to be much
> > lower here, so they're covered by the light structures.
>
> The altitude of
Mathias Fröhlich wrote:
> I traced that down yesterday for the binary ati driver.
The SGIX Pbuffer Extension just returns no configurations, but the glx Pbuffer
code does. I guess that ati phases out support for that extension in favour
to the newer standard glx implementation.
Does somebody
On Friday 01 Jul 2005 21:51, Curtis L. Olson wrote:
> I had an interesting day today. As I've mentioned before, I'm
> helping out with a University of MN UAV project. My main
> capacity was to assemble the airframe, and now I am the
> primary test pilot. We are just now starting to add
> instrum
Mathias Fröhlich wrote:
Hey
You're the man!
That is it.
Setting bits-per-pixel to 32 makes the models throw phantastic well looking
shadows! At least for my box with the binary ati driver.
After things going pop on my machine it's now back working - I dropped
the nvidia driver back to the pr
I am trying to compile FG on MSVC.net (7.0) on a Windows platform. I have
been sucessful through plib, simgear and now FG is providing me with a "fatal
LNK error 1104: cannot open file 'glut32.lib' ". The 'glut32.lib' file
exists in the C:\windows\system32 folder...
Can anyone suggest a
> > > Anyone know the altitude of the approach lights in FlightGear? They
> > > should be the same as the threshold, about 13 feet. They seem to be
> > > much lower here, so they're covered by the light structures.
> >
> > The altitude of the approach lights vary based on viewer distance
> > (and
Jon Foster wrote:
> I'm having a problem with sound in FlightGear 0.9.8. When I
> rename my .asoundrc to .asoundrc-bak, fgfs works fine and sounds
> great. But when I try to use my .asoundrc I get line after line
> of "native_blitbuffer: select error occured" and intermittent
> sound (kind of a st
Vivian Meazza wrote:
> Meanwhile, you are distracting Andy from updating the awaited
> supercharger code.
Heh, fair enough. This is checked in now, with a general rewrite
to clarify things and fix the bug where MP was reported "before"
the wastegate application.
The only new property is "boost-g
On Sat, 2 Jul 2005 09:00:52 +0200, Mathias wrote in message
<[EMAIL PROTECTED]>:
> That is it.
> Setting bits-per-pixel to 32 makes the models throw phantastic well
> looking shadows! At least for my box with the binary ati driver.
..AFAIK, ATI cards cannot do 32bpp. They use 24 bit hardware.
"Roberto Inzerillo" wrote:
> So I guess, using more photoreal scenery into FGFS would give a more
> realistic result with less human effort then using default terrain textures,
> vector roads/lakes/rivers/railroads...
I believe the most promising effort of this sort is 'osgPlanet' where
you appar
Martin Spott wrote:
"Roberto Inzerillo" wrote:
So I guess, using more photoreal scenery into FGFS would give a more
realistic result with less human effort then using default terrain textures,
vector roads/lakes/rivers/railroads...
I believe the most promising effort of this sort is
Martin Spott writes:
>
> "Roberto Inzerillo" wrote:
>
> > So I guess, using more photoreal scenery into FGFS would give a more
> > realistic result with less human effort then using default terrain textures,
> > vector roads/lakes/rivers/railroads...
>
> I believe the most promising effort of th
"Norman Vine" wrote:
> Because it has only recently been released see
> http://radar.oreilly.com/archives/2005/06/os_gis_conferen.html
Yep, I talked to Jan-Oliver Wagner who attended your presentation and
was deeply impressed ;-)
Martin.
--
Unix _IS_ user friendly - it's just selective about
"Curtis L. Olson" wrote:
> He's mentioned it here and there ... but there's way too many good ideas
> and not nearly enough time. And as good as osgPlanet is, that
> particular approach has some of it's own limitations,
I suspect it might fall behind when crusing at high speed, an argument
tha
Martin Spott writes:
>
> "Norman Vine" wrote:
>
> > Because it has only recently been released see
> > http://radar.oreilly.com/archives/2005/06/os_gis_conferen.html
>
> Yep, I talked to Jan-Oliver Wagner who attended your presentation and
> was deeply impressed ;-)
It is a neat 'toy' (1) and
20 matches
Mail list logo
