Open mruegenberg opened 8 years ago
It works when doing
bool didUseNormalizedTexCoords = ofGetUsingNormalizedTexCoords();
ofDisableNormalizedTexCoords();
mClient.draw(50, 50);
if(didUseNormalizedTexCoords)
ofEnableNormalizedTexCoords();
This feels kind of hacky though, and doesn't really work for code that expects normalized texture coords.
I "solved" it by rendering the Syphon result to a FBO first. I then use its texture where normalized tx coords are required. Not very efficient, but seems like a somewhat acceptable workaround:
if((! mSyphonFbo.isAllocated()) ||
mSyphonClient.getWidth() > mSyphonFbo.getWidth() ||
mSyphonClient.getHeight() > mSyphonFbo.getHeight()) {
// (re)allocate Syphon target FBO
int w = mSyphonClient.getWidth();
if(w < 10) w = 10;
int h = mSyphonClient.getHeight();
if(h < 10) h = 10;
mSyphonFbo.allocate(w, h); // hope that this doesn't leak the previous texture if called twice
}
// ...
bool didUseNormalizedTexCoords = ofGetUsingNormalizedTexCoords();
ofDisableNormalizedTexCoords();
mSyphonFbo.begin();
ofClear(0);
mSyphonClient.draw(0,0);
mSyphonFbo.end();
Perhaps we're not adequately configuring our ofTexture - still an issue in OF 0.10 RC4. Any ideas @astellato ?
I believe that Syphon requires non-normalized tex coordinates. Don't have access to a Mac at the moment, so I can't test what our new options could be in OF 0.10.
The texture from SyphonClient is GL_TEXTURE_RECTANGLE but OF should be able to cope with that - I'm not familiar enough to know what the intended affect of ofEnableNormalizedTexCoords() is and how an ofTexture should be configured and used when it's enabled - perhaps our calls to ofTexture::draw() should be different?
When I put
ofEnableNormalizedTexCoords
at the start ofofApp::setup
inexample-Basic
, the client no longer renders the texture from the server correctly.The same happens I do
instead.