Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Results 1 to 8 of 8

Thread: Catalyst 3.8 bug - glDrawPixels

  1. #1
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,256

    Catalyst 3.8 bug - glDrawPixels

    I was doing some testing and I noticed this weird behavior with glDrawElements.

    render()
    {
    I set modelview matrix to identity
    I set projection matrix to ortho.
    I call glRasterPos
    I call DrawPixels.
    }

    It renders fine when all the pixels fall inside the window, but when I resize the window and make it smaller, instead of the pixels that fall outside the viewport getting clipped, the whole DrawPixels rectangle is scaled so that it fits in the window.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  2. #2
    Member Regular Contributor
    Join Date
    Nov 2000
    Posts
    370

    Re: Catalyst 3.8 bug - glDrawPixels

    Have you tried the new 3.9 hotfixed drivers ? They have a updated opengl version in those.

  3. #3
    Senior Member OpenGL Pro
    Join Date
    Feb 2002
    Location
    Bonn, Germany
    Posts
    1,633

    Re: Catalyst 3.8 bug - glDrawPixels

    That's weird. I somewhat assume they've internally switched to texture rectangles (which are worth considering as a generic replacement for glDrawPixels btw).

    Maybe you can work around the problem by calling glPixelZoom(1,1) after glViewPort (reshape handler?). I didn't test it, but it could work ...

  4. #4
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,256

    Re: Catalyst 3.8 bug - glDrawPixels

    I havent tried 3.9 cause things are going fine with 3.8

    The Dawn demo doesnt run anymore with the hacked opengl32.dll
    Something about NV_point_sprite missing.

    I assumed DrawPixels is using a textured quad. It's hard to tell cause each call to DrawElements would cause a texture update which would still be slow.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  5. #5
    Senior Member OpenGL Guru
    Join Date
    Mar 2001
    Posts
    2,411

    Re: Catalyst 3.8 bug - glDrawPixels

    DrawPixels() cannot use a textured quad, because DrawPixels() generates fragments that pass through the fragment pipeline (if I recall correctly).

    Anyway, if your image shrinks when you resize the window, isn't that because your viewport shrinks, and all the GL matrix operations are relative to the viewport?
    "If you can't afford to do something right,
    you'd better make sure you can afford to do it wrong!"

  6. #6
    Senior Member OpenGL Guru
    Join Date
    Feb 2000
    Location
    Sweden
    Posts
    2,982

    Re: Catalyst 3.8 bug - glDrawPixels

    Originally posted by jwatte:

    Anyway, if your image shrinks when you resize the window, isn't that because your viewport shrinks, and all the GL matrix operations are relative to the viewport?
    Pixel transfers are not affected by any matrices (except the color matrix). So the image should stay the same if the viewport and/or window is changed. The raster position is affected by the matrices, but that only affects the position of the image, not it's shape.

  7. #7
    Super Moderator OpenGL Guru
    Join Date
    Feb 2000
    Location
    Montreal, Canada
    Posts
    4,256

    Re: Catalyst 3.8 bug - glDrawPixels

    Originally posted by jwatte:
    DrawPixels() cannot use a textured quad, because DrawPixels() generates fragments that pass through the fragment pipeline (if I recall correctly).
    Yes, according to the schema of the pipeline, but that's SGI's reference.

    I beleive that you are free to implement the way you want. The important thing is the end result (the buffers, and stacks, and so on)

    With a texture quad, with NEAREST filtering and the *right* tex coordinates,
    it should be possible to reproduce DrawPixels perfectly.

    If NVidia says they render lines with 2 triangles, then I figure anything is possible.
    ------------------------------
    Sig: http://glhlib.sourceforge.net
    an open source GLU replacement library. Much more modern than GLU.
    float matrix[16], inverse_matrix[16];
    glhLoadIdentityf2(matrix);
    glhTranslatef2(matrix, 0.0, 0.0, 5.0);
    glhRotateAboutXf2(matrix, angleInRadians);
    glhScalef2(matrix, 1.0, 1.0, -1.0);
    glhQuickInvertMatrixf2(matrix, inverse_matrix);
    glUniformMatrix4fv(uniformLocation1, 1, FALSE, matrix);
    glUniformMatrix4fv(uniformLocation2, 1, FALSE, inverse_matrix);

  8. #8
    Senior Member OpenGL Pro
    Join Date
    Feb 2002
    Location
    Bonn, Germany
    Posts
    1,633

    Re: Catalyst 3.8 bug - glDrawPixels

    Me too
    Originally posted by jwatte:
    DrawPixels() cannot use a textured quad, because DrawPixels() generates fragments that pass through the fragment pipeline (if I recall correctly).
    It works, under certain constraints
    You need at least one unused texture unit, and enough free texture memory to buffer the incoming pixel data.
    ... umm ... nothing else AFAICS.

    Then you just replace all references to primary color w the texture sampler (especially easy if you have a texture crossbar), render a screen aligned quad w the proper tex coords, voila, DrawPixels fully emulated.

    Anecdotal evidence: a certain rather smallish IHV told me something very interesting when I asked about why DrawPixels starts to fail when I exceed 1024 pixels width and/or height

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •