Why would glBindFramebuffer(GL_FRAMEBUFFER, 0) result in blank screen in cocos2D-iphone?
Asked Answered
S

1

10

[iPad-3]-[iOS 5.0]-[Objective-C]-[XCode 4.3.3]-[Cocos2D]-[openGL|ES 2.0]

I'm learning how to use openGL|ES 2.0 and have stumbled on Frame Buffer Objects (FBO)s

Info: I'm working with Cocos2D which has a lot of extra-fancy handling for drawing. I imagine that this may be linked with the issue. If the 'default' frame buffer for cocos is different from the actual default frame buffer that draws to the screen, this could result in a mis-draw

My Problem: in the init function of my "helloworld.m" class, if I place "glBindFrameBuffer(GL_FRAMEBUFFER, 0);" anywhere, I simply get a blank screen!

-(id) init
{
if( (self=[super init])) 
{

CGSize winSize = [CCDirector sharedDirector].winSize;

glBindFramebuffer(GL_FRAMEBUFFER, 0);


CCSprite * spriteBG = [[CCSprite alloc] initWithFile:@"cocos_retina.png"];
spriteBG.position = ccp(512,384);
//[self addChild:spriteBG z:1];

[self scheduleUpdate];
_mTouchDown = NO;


_mSprite = [CCSprite spriteWithTexture:_mMainTexture];
_mSprite.position = ccp(512,384);
[self addChild:_mSprite];

self.isTouchEnabled = YES;

} return self;}

Am I missing something basic and obvious?

As far as I've learned, the function "glBindFramebuffer(GL_FRAMEBUFFER, 0);" simply just setting the Framebuffer to 0 applies the default framebuffer that draws to the screen.

Shea answered 23/7, 2012 at 16:58 Comment(3)
I see you're new here. Welcome! The way to indicate that your problem has been solved is to accept an answer, not to put the answer in the question and add the word "Solved" to the title. It's perfectly ok to post and accept an answer to your own question. (You may have to wait a few hours to do this; there are some temporary restrictions on new users.)Crayton
I was not aware that it was poor etiquette to do the (solved) thing. I've seen it done so many times already like this so I assumed it was how pplz just did it for themselves. I tried to answer myself, 8 hour wait. and I'm at work and have no patience for such things. I'll edit now and try again tomorrow for making the answer. if it still doesn't work, then i'll just leave it.Shea
I've edited your last line; as written, it implied that you don't have a solution for the problem.Crayton
S
27

The Problem was that either iOS or Cocos2D (or both) can have a unique framebuffer. The handle of that unique frame buffer would be different than 0, and may be different each time.

To solve this, I have to grab the current FBO's handle, do my custom Framebuffer stuff and then re-apply the FBO's handle after I'm done.

Creates a variable to reference the original Frame Buffer Object

GLint oldFBO;

Assigns the currently used FBO's handle (which is a 'GLint') to the variable 'oldFBO'

glGetIntegerv(GL_FRAMEBUFFER_BINDING, &oldFBO);

//here is when you would create or manipulate custom framebuffers.//

After that, You set the original FBO as the current Framebuffer

glBindFramebuffer(GL_FRAMEBUFFER, oldFBO);
Shea answered 24/7, 2012 at 17:17 Comment(2)
GAH! Lost half a day to this idiocy... many thanks for the vital clue.Lissner
Wow, this does not seem to be just a Cocos2D issue. I was struggling with using FrameBuffer (FBO) in LibGdx while porting my game to iOS. While FrameBuffer in LibGdx worked w/o any problems on Desktop and Android, continuously rendering to FBO caused that I could not render to the screen anymore in the same render cycle. Using Gdx.gl.glGetIntegerv(GL_FRAMEBUFFER_BINDING, oldFbo) before fbo.begin() and Gdx.gl.glBindFramebuffer(GL_FRAMEBUFFER, oldFbo.get()) after fbo.end() solved that problem on iOS. Thanks a lot!Lampkin

© 2022 - 2024 — McMap. All rights reserved.