glTexSubImage2D() and Windows Overlapping problem?

Hello,

I’m using glTexSubImage2D() to copy a generated background image to a texture in order to create procedural clouds on the fly. I found that if another window is partially overlapping my render window, the part where the overlap occurs does not get rendered. An artifact of the prior background is there in its place.

This happens in Windows XP. Or, more precisely, on the machine I’m programming on it doesn’t happen, but on another machine it does happen. Both are running XP.

Apparently, wherever a window is covering my OpenGL render window one machine is saying “don’t paint that region at all.” Does anyone know the solution to this problem?

Thanks for any feedback! :slight_smile:

…John

Does anyone know the solution to this problem?
Yes. Stop covering your windows when you’re doing important copies.

OpenGL says that rendering to pixels that are not owned (because they are being covered by another window, for example) is undefined. Maybe it works, maybe it has something from last frame, maybe it’s garbage. It’s undefined.

The only redress is to move the overlapping window. Or render to a private FBO/pbuffer. In fact, since you’re basically doing a render-to-texture operation, you should be using an FBO anyway.

Originally posted by Korval:
OpenGL says that rendering to pixels that are not owned (because they are being covered by another window, for example) is undefined. Maybe it works, maybe it has something from last frame, maybe it’s garbage. It’s undefined.

Hey, thanks for the quick and to the point answer and the advice.

The only redress is to move the overlapping window. Or render to a private FBO/pbuffer. In fact, since you’re basically doing a render-to-texture operation, you should be using an FBO anyway.
FBO appears to be quite limited to the number of cards it will work on. I’m using GeForce4 MX and it’s not recognized.

I’ve been experimenting with pbuffer as an alternative. I tried the demos here , on the topic ‘Off-screen Rendering Using Pixel Buffers’. I tried “version 1” and “version 2” on at that link, and both returned a memory access violation at “wglCreatePbufferARB()” The error read:

Unhandled exception at 0x695edc42 in ogl_offscreen_rendering_1.exe: 0xC0000005: Access violation reading location 0x00000000
So, my thinking is, if this happens as a rule and requires upgrade of driver and what not for users, it could be a headache.

Comments and suggestions always welcome.

Thanks.
:smiley:

Well … WGL_ARB_pbuffer is available in GF4mx since 2002 …
http://www.delphi3d.net/hardware/viewreport.php?report=547

It is not much to ask to update drivers every 5 years … of course it depends on your intended audience :stuck_out_tongue:

This topic was automatically closed 183 days after the last reply. New replies are no longer allowed.