mesa3d-dev

[Mesa3d-dev] GL_INTENSITY as a base format for texture images?

[Gareth H. <ga...@va...>]

Brian, this is in relation to the demo program I sent you earlier.

I've adapted one of the old GLUT demos to test all the different texture
environment modes for all texture formats.  The problem I'm seeing is
textures with GL_INTENSITY as a base or internal format.  It appears
that GL_INTENSITY is an illegal base format for an image (as it's not
valid for glDrawPixels) and thus is rejected in the format/type test in
Mesa (can't remember where that test is).  Perhaps I'm just missing
something, but my quick reading of the spec and the Red Book seem to
indicate that this is in fact true, but it really doesn't make sense to
me.  

The GL_INTENSITY texture combine functionality will surely never be
invoked if you can't make a GL_INTENSITY texture image, right?  From
looking at the implementation of the apply_texture (or whatever)
function, we need to be able to assign the base format to GL_INTENSITY
to get the correct texturing functionality inside the software
rasterizer, which is what I would have expected.  This is causing an
error at the moment.

Caveat: I'm kinda working really hard at the moment and haven't slept
much lately.  Don't be too cruel if I'm an idiot :-)

-- Gareth

Re: [Mesa3d-dev] GL_INTENSITY as a base format for texture images?

[Brian P. <br...@pr...>]

Gareth Hughes wrote:
> 
> Brian, this is in relation to the demo program I sent you earlier.
> 
> I've adapted one of the old GLUT demos to test all the different texture
> environment modes for all texture formats.  The problem I'm seeing is
> textures with GL_INTENSITY as a base or internal format.  It appears
> that GL_INTENSITY is an illegal base format for an image (as it's not
> valid for glDrawPixels) and thus is rejected in the format/type test in
> Mesa (can't remember where that test is).  Perhaps I'm just missing
> something, but my quick reading of the spec and the Red Book seem to
> indicate that this is in fact true, but it really doesn't make sense to
> me.
> 
> The GL_INTENSITY texture combine functionality will surely never be
> invoked if you can't make a GL_INTENSITY texture image, right?  From
> looking at the implementation of the apply_texture (or whatever)
> function, we need to be able to assign the base format to GL_INTENSITY
> to get the correct texturing functionality inside the software
> rasterizer, which is what I would have expected.  This is causing an
> error at the moment.
> 
> Caveat: I'm kinda working really hard at the moment and haven't slept
> much lately.  Don't be too cruel if I'm an idiot :-)

You're right.  GL_INTENSITY wasn't being error checked correctly.
I've checked in the fix to the Mesa CVS trunk.  Thank!

It's kind of frustrating how the image formats accepted by glTex{Sub}Image,
glDraw/ReadPixels, glColorTable, glConvolutionFilter, etc. aren't uniform.

-Brian

[Mesa3d-dev] Inconsistent scan conversion in XOR mode

[Howard <ho...@me...>]

Has anyone else observed a problem with the scan conversion of vertical and
horizontal lines while in XOR mode. We have consistently observed that there
are:
a) Irregularities in vertical and horizontal line, i.e. 4 - 10 pixel spans
that are offset by a pixel.
b) Non repeating patterns, i.e. the same vertical or horizontal line
coordinates plot these irregularities differently. This is especially
visible/troublesome in the XOR case, because the 2nd, (erase) draw does not
cover the same pixels, and consequently leaves scars. This only seems to
happen in the vertical/horizontal cases and does not happen when in a
normal, (non XOR) mode.

Thanks,
--
Howard Luby     Fax:248 540-3138 Tel:248 540-2251
ho...@me... http://www.mediascape.com

Re: [Mesa3d-dev] Inconsistent scan conversion in XOR mode

[Brian P. <br...@pr...>]

Howard wrote:
> 
> Has anyone else observed a problem with the scan conversion of vertical and
> horizontal lines while in XOR mode. We have consistently observed that there
> are:
> a) Irregularities in vertical and horizontal line, i.e. 4 - 10 pixel spans
> that are offset by a pixel.
> b) Non repeating patterns, i.e. the same vertical or horizontal line
> coordinates plot these irregularities differently. This is especially
> visible/troublesome in the XOR case, because the 2nd, (erase) draw does not
> cover the same pixels, and consequently leaves scars. This only seems to
> happen in the vertical/horizontal cases and does not happen when in a
> normal, (non XOR) mode.

I've seen a problem in which a clipped, vertical, wide line will "wiggle"
left/right by a pixel.  When I looked into it it was a case where one
endpoint was at X=5 and the other at x=4.999 (for example).

Are your endpoints being clipped?

-Brian

Re: [Mesa3d-dev] Inconsistent scan conversion in XOR mode

[Howard <ho...@me...>]

----- Original Message -----
From: "Brian Paul" <br...@pr...>
To: "Howard" <ho...@me...>
> >
> > Has anyone else observed a problem with the scan conversion of vertical
and
> > horizontal lines while in XOR mode. We have consistently observed that
there
> > are:
> > a) Irregularities in vertical and horizontal line, i.e. 4 - 10 pixel
spans
> > that are offset by a pixel.
> > b) Non repeating patterns, i.e. the same vertical or horizontal line
> > coordinates plot these irregularities differently. This is especially
> > visible/troublesome in the XOR case, because the 2nd, (erase) draw does
not
> > cover the same pixels, and consequently leaves scars. This only seems to
> > happen in the vertical/horizontal cases and does not happen when in a
> > normal, (non XOR) mode.
>
> I've seen a problem in which a clipped, vertical, wide line will "wiggle"
> left/right by a pixel.  When I looked into it it was a case where one
> endpoint was at X=5 and the other at x=4.999 (for example).
>
> Are your endpoints being clipped?
>
No, there is no clipping. There must a round-off of some kind. The data
points are the same, but the view matrix could be slightly different. The
funny thing is, the start and end points will be level, but the path, as you
say, "wiggles", when in XOR mode. The problem is not present with the same
code on Irix. We will try to distill this down to a small example if no one
else is experiencing it.

Thanks,
--
Howard Luby     Fax:248 540-3138 Tel:248 540-2251
ho...@me... http://www.mediascape.com