5 replies to this topic

[gram]

I'm trying to achieve a low-resolution effect similar to this:


Observe the jagged edges


I've done it in OpenGL, but only in Linux, and I want to do it in windows. In Linux, these two calls do the job

glBlitFramebuffer(0, 0, 512, 512, 256-rez/2, 256-rez/2, 256+rez/2, 256+rez/2, GL_COLOR_BUFFER_BIT, GL_LINEAR);
glBlitFramebuffer(256-rez/2, 256-rez/2, 256+rez/2, 256+rez/2, 0, 0, 512, 512, GL_COLOR_BUFFER_BIT, GL_LINEAR);

in a 512x512 window where "rez" is the edge length of a square (such as 256) that the scene is reduced to (first call) and then scaled back from (second call).

This works just fine in Linux, but crashes my program in Windows. Any ideas?

[Suds_]

Try replacing

GL_LINEAR with GL_NEAREST.

[mhagain]

First of all, the OS is completely irrelevant here. The deciding factor is your graphics hardware and what it does or doesn't support.

So, my guess here is that your Linux machine has a 3D card that supports GL_ARB_frame_buffer_object or a reasonably recent version of OpenGL (with framebuffer objects in core). Your Windows box does not - the cause of the crash is that the function pointer for glBlitFramebuffer is NULL. Upgrading the graphics card on your Windows box to one that does support this functionality will resolve it.

[gram]

Try replacing

GL_LINEAR with GL_NEAREST.

That changes how nice it looks but shouldn't affect things since it is only a color buffer blit. From the OGL 3.3 docs:

"If the sizes of the source and destination rectangles are not equal, filter specifies the interpolation method that
will be applied to resize the source image , and must be GL_NEAREST or GL_LINEAR.
GL_LINEAR is only a valid interpolation method for the color buffer. If filter is not
GL_NEAREST and mask includes GL_DEPTH_BUFFER_BIT or
GL_STENCIL_BUFFER_BIT, no data is transferred and a GL_INVALID_OPERATION error is generated."

First of all, the OS is completely irrelevant here. The deciding factor is your graphics hardware and what it does or doesn't support.

So, my guess here is that your Linux machine has a 3D card that supports GL_ARB_frame_buffer_object or a reasonably recent version of OpenGL (with framebuffer objects in core). Your Windows box does not - the cause of the crash is that the function pointer for glBlitFramebuffer is NULL. Upgrading the graphics card on your Windows box to one that does support this functionality will resolve it.

It's the same machine...must be the drivers?

Edited by gram, 24 May 2012 - 06:42 PM.

[mhagain]

Sounds like the drivers alright.

For this kind of image, an alternative way might be to render to a smaller viewport (pick, say, 320x200 for a really authentic 1995/1996 grungy pixel look), then glCopyTexSubImage it to a texture, and finally draw that texture on a regular fullscreen quad. There will be a performance penalty compared to using FBOs, but on the other hand it will work on all hardware going back to OpenGL 1.1, and at the lower resolution it should still run more than fast enough.

[gram]

Updated the drivers. Didn't crash, but didn't quite work, either:



Since the read and write buffer are the same, there must be some implementation-specific issues.


To get it to work, I changed

glViewport( 0, 0, 512, 512);

which was only called once, during initialization,

to

glViewport( 0, 0, rez, rez);


and

glBlitFramebuffer(0, 0, 512, 512, 256-rez/2, 256-rez/2, 256+rez/2, 256+rez/2, GL_COLOR_BUFFER_BIT, GL_LINEAR);
glBlitFramebuffer(256-rez/2, 256-rez/2, 256+rez/2, 256+rez/2, 0, 0, 512, 512, GL_COLOR_BUFFER_BIT, GL_LINEAR);

which was called every frame, after drawing, to

glBlitFramebufferEXT(0, 0, 256, 256, 0, 0, 512, 512, GL_COLOR_BUFFER_BIT, GL_LINEAR);

resulting in the desired effect:




But of course we can't stop there. Turning GL_LINEAR to GL_NEAREST, and lowering rez, brings us from the mid-nineties to the mid-eighties:



Thanks guys!

Edited by gram, 24 May 2012 - 09:24 PM.