Hi,
this is my latest in the neverending series of dumb questions. I have
a Radeon 8500 that does a great job for most of my work. I currently
use the ATI binary driver (since XFree86 hasn't quite got good 3D
support, but it's getting there).
I updated the driver from the fglr200-1.4.3 to the un
Major A <[EMAIL PROTECTED]> said:
> - the 747-yasim panel is not drawn at all -- all I get is the beige
> background, no instruments. Running the same CVS build without DRI,
> I get all instruments (at 0.3fps though). All worked fine with the
> older driver.
There is no 747 panel...yet. :-)
> > - the 747-yasim panel is not drawn at all -- all I get is the beige
> > background, no instruments. Running the same CVS build without DRI,
> > I get all instruments (at 0.3fps though). All worked fine with the
> > older driver.
>
> There is no 747 panel...yet. :-)
Sorry, I only said 7
Major A wrote:
> Sorry, I only said 747 because that was the only one I could run in
> the broken build I used. I now fixed that one, it happens with all
> 2D panels, 172, 182, 747 (press P), etc.
I can confirm this. Layers on the 2D panels (but oddly, only the 2D
panels) aren't drawing over the
I wrote:
> I can confirm this. Layers on the 2D panels (but oddly, only the 2D
> panels) aren't drawing over the background with the current ATI
> drivers.
OK, this turns out to be a trivial fix, although I still think it's a
driver bug. There are two calls to glPolygonOffset in the panel
render
> Another ATI bug I've noticed is that they seem to have trouble with
> texture border. It's sampling the border color even when there is no
> border width defined, with the result that the runway tiles have dark
> shadows between them. Screenshot at:
>
> http://www.plausible.org/andy/ati-tex
> OK, this turns out to be a trivial fix, although I still think it's a
> driver bug. There are two calls to glPolygonOffset in the panel
> rendering code (shared by both 2D and 3D panels). One is called
> per-layer, and sets up a layer-specific offset. The other is called
> for drawing the bac
Andy,
I could easily be wrong since I've never messed with glPolygonOffset
myself, but it's my understanding that one of the problems with this
function is that the values you need to assign to the parameters can be
different across platforms to accomplish the same thing.
Curt.
Andy Ross writes
Curtis L. Olson wrote:
> I could easily be wrong since I've never messed with glPolygonOffset
> myself, but it's my understanding that one of the problems with this
> function is that the values you need to assign to the parameters can
> be different across platforms to accomplish the same thing.
On 12/1/02 at 1:52 PM Andy Ross wrote:
>I can confirm this. Layers on the 2D panels (but oddly, only the 2D
>panels) aren't drawing over the background with the current ATI
>drivers. I vaguely remember other reports of this kind of symptom.
>Does anyone remember? I'll take a look.
Yes, several
> Yes, several people reported a completely grey 2D panel with Radeon
> 7000/7500 cards with the DRI drivers. I also get this (with XFree86 4.1.0)
> and didn't manage to find a fix posted. The problem goes away when
> software rendering is used. It also affects the 3D panel instrument
> needles
On 12/3/02 at 4:34 PM David Luff wrote:
Oops - a few clarifications to that post...
>
>Yes, several people reported a completely grey 2D panel with Radeon
>7000/7500 cards with the DRI drivers. I also get this (with XFree86
4.1.0)
With a Radeon 7500
>and didn't manage to find a fix posted. T
David Luff wrote:
> Just to clarify - they flicker in and out of view when the view is
> anything other than straight forward and disappear altogether when
> the view is exactly straight forward.
This sounds vaguely like it's related to the glPolygonOffset issue I
mentioned. The offsets for the i
Major A wrote:
> May I suggest a straight-forward solution:
>
> - For 2D panels, disable GL_DEPTH_TEST altogether.
No objections here. It wouldn't even complicate the code much at all.
The only downside is that the traditional 2D panels are essentially
legacy features. All current development ha
> easy to get offsets wrong, the numbers are all magic (does anyone
> really know how far a GS needle is off of the backplate?),
The Narco VOR/LOC instruments I own place the needles about 1/8" inch off
the face of the instrument. Same for the OFF flag.
g.
Andy Ross writes:
>
> Moving
> individual instruments around in a 3D editor is a little scary -- how
> do you get them all onto the same plane?
This is *exactly* the reason *real* modellers have orthographic modes
as well as perspective modes
Norman
__
Andy,
> > - For 3D panels, they should be made "real" 3D panels -- needles
> > should be some 2mm closer to the viewer than the scale.
>
> Opinions differ on this one. While some instruments (like the A-4
> attitude ball) pretty much have to be 3D, I don't think this is the
> right model for
Major A writes:
> > Opinions differ on this one. While some instruments (like the A-4
> > attitude ball) pretty much have to be 3D, I don't think this is the
> > right model for "typical" flat panel instruments. The first problem
> > is of course that having to figure out 3D offsets is a pai
On 12/3/02 at 9:37 AM Andy Ross wrote:
>David Luff wrote:
>> Just to clarify - they flicker in and out of view when the view is
>> anything other than straight forward and disappear altogether when
>> the view is exactly straight forward.
>
>This sounds vaguely like it's related to the glPolygonOf
> >This sounds vaguely like it's related to the glPolygonOffset issue I
> >mentioned. The offsets for the instrument layers would be different
> >from the background offset by a number proportional to the "depth
> >slope" of the polygon. I posted a 1-liner fix, and I think it made it
> >into CVS
Major A wrote:
> There is another issue with the A4 though -- pressing shift-KP8 gives
> a default view which is nicely out of the window, but the instruments
> are no longer on the screen.
You mean that the view is looking too far up, above the level of the
instruments, right? Not that there's a
> You mean that the view is looking too far up, above the level of the
> instruments, right? Not that there's a rendering error preventing
> them from being drawn?
That's right, it's only the direction of view, not rendering itself.
> It's actually a little deeper than that. The keypad "8" vie
Andy Ross writes:
> But it's only a default startup setting -- the keypad bindings change
> the current values. There's no "return to default" binding
> anywhere.
> This can be fixed in XML; but it requires defining a place to put
> "default" settings for the view, getting all the aircraft
23 matches
Mail list logo
