ofTexture.loadScreenData(...) inverting screen when using bind()

I’m jumping back and forth between the openFrameworks shaders tutorial and the GLSL wiki in order to get started with shaders. I’m running into some trouble with ofTexture though - specifically with the texture getting inverted. I’m trying to grab the screen (post-shader) and save it to an ofTexture, which then gets fed into the shader on the next draw() call. (For context, it’s just conway’s game of life run on the GPU, so the ofTexture contains the current step of the simulation.)

I’ve stripped down my code to find that the issue results from using loadScreenData(...) after bind(). So, if I have an ofTexture tex and an ofMesh that are set up like this:

img.loadImage("cat.jpg"); //  This is just a test image
tex = img.getTextureReference();

int w = ofGetWidth();
int h = ofGetHeight();

// Mesh that covers the screen
quad.addVertex(ofVec2f(0, 0));
quad.addVertex(ofVec2f(w, 0));
quad.addVertex(ofVec2f(w, h));
quad.addVertex(ofVec2f(0, h));
ofIndexType indicies[6] = {0, 1, 2, 2, 0, 3};
quad.addIndices(indicies, 6);
quad.addTexCoord(ofVec2f(0, 0));
quad.addTexCoord(ofVec2f(w, 0));
quad.addTexCoord(ofVec2f(w, h));
quad.addTexCoord(ofVec2f(0, h));

And I have a draw() that looks like this:

tex.loadScreenData(0, 0, tex.getWidth(), tex.getHeight());

I end up with the texture being flipped vertically on every frame. I’m guessing something is happening it different between the UV coordinate systems when I draw quad and when I loadScreenData(...)?

System info: Windows 7 (64x), Code::Blocks 12.11, 0.8.0, openGL supported up through 4.3

I’ve found this to be the case as well with oF v0.8.3, even without calling ofTexture::bind(). Using ofImage::grabScreen() and then ofImage::getTextureReference() does not seem to flip the texture.

1 Like

Ah thanks! Yeah, that’s the fix I ended up using in the project:

ofImage tmpImg;
tmpImg.grabScreen(0, 0, tex.getWidth(), tex.getHeight());
tex = tmpImg.getTextureReference();

I remember digging around in the source for ofTexture::loadScreenData() and ofImage::grabScreen(), seeing that they read the screen in two different ways, but I don’t remember if I ever felt satisfied that I understood why the vertical flipping was occurring. Guess I should dive back into that sometime.

Perhaps we can dig into it on Thursday and see if we need to draft a bug report.