mesa3d-dev

[Mesa3d-dev] Bitmap and Pixmap Positioning

[Allen B. <ba...@lo...>]

Hi,

In the routine _mesa_DrawPixels in the file src/drawpix.c, the current
raster position is converted to integer coordinates through the IROUND
function (round to nearest, I think?). However, in the routine
_mesa_Bitmap, the raster position is just cast to a GLint. At least on
my system (RedHat 7.1/i386, gcc 2.96), these occasionally give different
values, which I can see as inconsistencies in the positioning of bitmaps
and pixmaps. I was wondering what the reason was for treating these
conversions differently? (_mesa_CopyPixels gets the IROUND, too.)

Also, I downloaded the tar file of MesaLib-3.5 from SourceForge and
tried to build it from scratch, but it would not complete its
./configure run unless src-glut/ was installed from MesaDemos, too.
Perhaps this is worth a note in the documentation? The other minor
glitch I noticed was that RH 7.1 installs the Glide libraries by
default, which causes ./configure to pick up them up and compile the
Glide driver. This treats you to the message: WARNING: This Mesa Library
includes the Glide driver... when you first run a program. Maybe Mesa
could be configured w/o Glide by default now that DRI is the way to go?

Thanks,
Allen

Re: [Mesa3d-dev] Bitmap and Pixmap Positioning

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

Allen Barnett wrote:
> 
> Hi,
> 
> In the routine _mesa_DrawPixels in the file src/drawpix.c, the current
> raster position is converted to integer coordinates through the IROUND
> function (round to nearest, I think?). However, in the routine
> _mesa_Bitmap, the raster position is just cast to a GLint. At least on
> my system (RedHat 7.1/i386, gcc 2.96), these occasionally give different
> values, which I can see as inconsistencies in the positioning of bitmaps
> and pixmaps. I was wondering what the reason was for treating these
> conversions differently? (_mesa_CopyPixels gets the IROUND, too.)

Sounds like a bug.  glBitmap should use rounding as well.



> Also, I downloaded the tar file of MesaLib-3.5 from SourceForge and
> tried to build it from scratch, but it would not complete its
> ./configure run unless src-glut/ was installed from MesaDemos, too.
> Perhaps this is worth a note in the documentation? The other minor
> glitch I noticed was that RH 7.1 installs the Glide libraries by
> default, which causes ./configure to pick up them up and compile the
> Glide driver. This treats you to the message: WARNING: This Mesa Library
> includes the Glide driver... when you first run a program. Maybe Mesa
> could be configured w/o Glide by default now that DRI is the way to go?

Try ./configure --without-glide

-Brian

Re: [Mesa3d-dev] Bitmap and Pixmap Positioning

[Allen B. <ba...@lo...>]

Brian Paul wrote:
> 
> Allen Barnett wrote:
> > Maybe Mesa
> > could be configured w/o Glide by default now that DRI is the way to go?
> 
> Try ./configure --without-glide

(OK. I just meant to make --without-glide the default.)

Also, about raster images: I see that you added a glWindowPosMESA
extension which doesn't suffer from the viewport clipping effect of
glRasterPos. However, the units of glWindowPos are the direct window
coordinates. I think I need something somewhere in between, i.e., to
draw an image at coordinates which are transformed by the
projection/modelview matrices but whose origin may be outside the
viewport. I know about the glBitmap(0,0,0,0,xmove,ymove,NULL) trick, but
the xmove/ymove coordinates are in pixels, not model units. The
following seems to work OK:

glGet viewing matrices
gluProject( mx, my, mz, viewing matrices, &wx, &wy, &wz);
glWindowPosMESA( wx, wy );
glDrawPixels(...);

but this seems inefficient (as well as requiring a MESA extension). Is
there some better trick I'm missing?

Thanks,
Allen

Re: [Mesa3d-dev] Bitmap and Pixmap Positioning

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

Allen Barnett wrote:
> 
> Brian Paul wrote:
> >
> > Allen Barnett wrote:
> > > Maybe Mesa
> > > could be configured w/o Glide by default now that DRI is the way to go?
> >
> > Try ./configure --without-glide
> 
> (OK. I just meant to make --without-glide the default.)

That'll probably be the default in the future.  I don't know if many
people are still using the Glide driver.


> Also, about raster images: I see that you added a glWindowPosMESA
> extension which doesn't suffer from the viewport clipping effect of
> glRasterPos. However, the units of glWindowPos are the direct window
> coordinates. I think I need something somewhere in between, i.e., to
> draw an image at coordinates which are transformed by the
> projection/modelview matrices but whose origin may be outside the
> viewport. I know about the glBitmap(0,0,0,0,xmove,ymove,NULL) trick, but
> the xmove/ymove coordinates are in pixels, not model units. The
> following seems to work OK:
> 
> glGet viewing matrices
> gluProject( mx, my, mz, viewing matrices, &wx, &wy, &wz);
> glWindowPosMESA( wx, wy );
> glDrawPixels(...);
> 
> but this seems inefficient (as well as requiring a MESA extension). Is
> there some better trick I'm missing?

Take a look at this:
http://oss.sgi.com/projects/ogl-sample/registry/IBM/rasterpos_clip.txt

I could pretty easily implement this extension if you want it.

-Brian

[Mesa3d-dev] Bug in affine triangles?

[Klaus N. <kl...@ma...>]

Hi,

I modified the 'fire'-demo, because I wanted to see how it worked with the
affine_triangle function, basically I used 'GL_NEAREST' for Min and Max
and I set GL_PERSPECTIVE_CORRECTION_HINT to GL_FASTEST and the results I
get are pretty strange. I know that texturing can look wrong, but here
half of the trees at the border of the screen are just missing and the
ground at the bottom seems to be foggy, though I switch fog off (yes, if I
switch fog off, the fog disappears, but only for the polygons that are not
close to the border of the screen).

This problem is related to 'GL_MODULATE', because if I switch to
'GL_REPLACE' everything looks o.k.

I was using the CVS-version of the week before last week for my tests and
software-rendering.

Bye

	Klaus

Re: [Mesa3d-dev] Bitmap and Pixmap Positioning

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

Brian Paul wrote:
> 
> Allen Barnett wrote:
> >
> > Hi,
> >
> > In the routine _mesa_DrawPixels in the file src/drawpix.c, the current
> > raster position is converted to integer coordinates through the IROUND
> > function (round to nearest, I think?). However, in the routine
> > _mesa_Bitmap, the raster position is just cast to a GLint. At least on
> > my system (RedHat 7.1/i386, gcc 2.96), these occasionally give different
> > values, which I can see as inconsistencies in the positioning of bitmaps
> > and pixmaps. I was wondering what the reason was for treating these
> > conversions differently? (_mesa_CopyPixels gets the IROUND, too.)
> 
> Sounds like a bug.  glBitmap should use rounding as well.

Hmmm, I'm not so sure now.  If I change glBitmap to round off the
coordinates then the conformance test fails.  Similarly, if I change
glDraw/CopyPixels to truncate the coordinates then conformance fails
too.

When I have more time I'll look closer at this.  I'll leave things
as-are for now (conformant).

-Brian