0

I created a low-resolution framebuffer object which has a retro-style display.

The framebuffer seems to display itself, causing a mess of pixels at the bottom of the screen.

This is how it looks when framebuffer is drawn completely overlapping the viewport

This is how it looks when framebuffer is drawn in overlapping the quarter of the viewport

This is how I made the Framebuffer and the Renderbuffer

FBO = glGenFramebuffers(1)
DBO = glGenRenderbuffers(1)

glBindRenderbuffer(GL_RENDERBUFFER, DBO)
glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT, 1280, 720)

glBindFramebuffer(GL_FRAMEBUFFER, FBO)
glFramebufferRenderbuffer(GL_FRAMEBUFFER, GL_DEPTH_ATTACHMENT, GL_RENDERBUFFER, DBO)
glBindFramebuffer(GL_DRAW_FRAMEBUFFER, 0)

And this is the code in mainloop

    glDrawElements(GL_TRIANGLES, len(indices), GL_UNSIGNED_INT, None) # Drawing Stuff

    ###

    glBindFramebuffer(GL_FRAMEBUFFER, 0)
    
    glBlitFramebuffer(
        640 - 128,
        360 - 72,
        640 + 128,
        360 + 72,
        0,
        0,
        1280,
        720,
        GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT,
        GL_NEAREST
    )

I am using Python 3 with PyOpenGL

genpfault
  • 51,148
  • 11
  • 85
  • 139
  • What happens if the source and destination rectangles of the `glBlitFramebuffer` call don't overlap? Does that give the expected result? – G.M. Nov 11 '20 at 15:52
  • I didn't quite understand what you meant. I am new to OpenGL and I am learning it. –  Nov 11 '20 at 17:33
  • 2
    First, why are you coying the framebuffer instead of just plainly rendering to the screen directly? Second you need to modify the viewport through glViewport https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/glViewport.xhtml – Makogan Nov 11 '20 at 17:43
  • What is referred as "copying" the framebuffer? Do you mean that I am blitting the framebuffer twice? If so, the reason is that I am trying to reduce the size of the cube with the first blit, and then increase it back in the second blit. If I only do the second one, it works fine (it still repeats itself), but in that case I need to add additional translation as the cube is zoomed. –  Nov 11 '20 at 17:49
  • @G.M. I understood now, it does indeed work. But that does not solve my problem. Is there any workaround to this? –  Nov 11 '20 at 18:45
  • I have not done OGL in a while so I am a little rusty, but instead of copying the data like that, just make the actual FB smaller: `glRenderbufferStorage(GL_RENDERBUFFER, GL_DEPTH_COMPONENT, 1280, 720)` Change those dimensions – Makogan Nov 11 '20 at 18:54
  • 1
    Also, could this be a driver issue? This post (https://stackoverflow.com/questions/41413021/opengl-scale-single-pixel-line) says that Intel Drivers have issues with it. I am using an Intel driver too. Also, changing the renderbuffer dimensions didn't bring any change. –  Nov 11 '20 at 19:01
  • @KaustabhChakraborty `"could this be a driver issue?"`: exactly, that's what I was thinking. The [documentation](https://www.khronos.org/opengl/wiki/Framebuffer#Blitting) states `"The read and draw framebuffers can be the same."` and I can't find any docs. that impose any caveats/restrictions on that to the effect that the source and destination regions mustn't overlap. So very possibly a driver issue. Just a guess though. – G.M. Nov 11 '20 at 19:24
  • I found a solution for this. I used `glViewport` to reduce the Viewport size, then copying the whole viewport area in the framebuffer and rendered in full screen. It worked pretty well. Thanks for helping! Here is a peek: https://i.imgur.com/2SkZIdP_d.webp?maxwidth=1520&fidelity=grand –  Nov 12 '20 at 14:25
  • Which framebuffer are you trying to copy to, and copy from? – user253751 Nov 13 '20 at 15:18

1 Answers1

1

In the comments to this question, there are speculations about driver bugs. This is not the case. The one definitive source of correct OpenGL behavior is the OpenGL specification, and the current GL 4.6 spec states in section 18.3 "Copying Pixels" (emphasis mine):

Several commands copy pixel data between regions of the framebuffer (see section 18.3.1), or between regions of textures and renderbuffers (see section 18.3.2). For all such commands, if the source and destination are identical or are different views of the same underlying texture image, and if the source and destination regions overlap in that framebuffer, renderbuffer, or texture image, pixel values resulting from the copy operation are undefined.

Note that the binding target GL_FRAMEBUFFER is a shortcut for both GL_READ_FRAMEBUFFER *which defines the source for the blit) and GL_DRAW_FRAMEBUFFER (which specifies the destination), so you are creating the feedback loop on purpose here.

However, it remains totally unclear what you are doing. The blit from default framebuffer to default framebuffer means it will not show the contents of your FBO at all, and since your FBO idoes not have a color attachment, you can't render color data to it anayway.

derhass
  • 43,833
  • 2
  • 57
  • 78