Re: [AD] Possible issue with the way allegro uses FBOs? |
[ Thread Index |
Date Index
| More lists.liballeg.org/allegro-developers Archives
]
- To: "Coordination of admins/developers of the game programming library Allegro" <alleg-developers@xxxxxxxxxx>
- Subject: Re: [AD] Possible issue with the way allegro uses FBOs?
- From: Thomas Fjellstrom <tfjellstrom@xxxxxxxxxx>
- Date: Sun, 27 Jun 2010 11:50:52 -0600
On June 21, 2010, Thomas Fjellstrom wrote:
> Somewhat recently the intel-gfx linux drivers received FBO support, and
> it seems to work.
>
> Unfortunately with allegro's ex_bitmap_target example it gets a whopping
> 8-10fps, 2 more than the forced bitmap locking.
>
> I found an gl fbo example on the web which seems to render at 50-60fps
> just fine. Here is the actual fbo code it uses:
>
> // init:
> // create a framebuffer object, you need to delete them when program
> // exits.
> glGenFramebuffersEXT(1, &fboId);
> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fboId);
>
> // create a renderbuffer object to store depth info
> // NOTE: A depth renderable image should be attached the FBO for
> depth // test. If we don't attach a depth renderable image to the FBO,
> then // the rendering output will be corrupted because of missing depth
> // test. If you also need stencil test for your rendering, then you //
> must attach additional image to the stencil attachement point, too.
> glGenRenderbuffersEXT(1, &rboId);
> glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, rboId);
> glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT,
> TEXTURE_WIDTH, TEXTURE_HEIGHT);
> glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, 0);
>
> // attach a texture to FBO color attachement point
> glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
> GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, textureId, 0);
>
> // attach a renderbuffer to depth attachment point
> glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT,
> GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, rboId);
>
> // draw:
>
> // set the rendering destination to FBO
> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fboId);
>
> // clear buffer
> glClearColor(1, 1, 1, 1);
> glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
>
> // draw a rotating teapot
> glPushMatrix();
> glRotatef(angle*0.5f, 1, 0, 0);
> glRotatef(angle, 0, 1, 0);
> glRotatef(angle*0.7f, 0, 0, 1);
> glTranslatef(0, -1.575f, 0);
> drawTeapot();
> glPopMatrix();
>
> // back to normal window-system-provided framebuffer
> glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0); // unbind
>
> // trigger mipmaps generation explicitly
> // NOTE: If GL_GENERATE_MIPMAP is set to GL_TRUE, then
> // glCopyTexSubImage2D() triggers mipmap generation automatically.
> // However, the texture attached onto a FBO should generate mipmaps
> // manually via glGenerateMipmapEXT().
> glBindTexture(GL_TEXTURE_2D, textureId);
> glGenerateMipmapEXT(GL_TEXTURE_2D);
> glBindTexture(GL_TEXTURE_2D, 0);
>
> ....
>
> // draw rotating cube here
>
>
> Is there something allegro is or isn't doing that might explain the
> difference? If there is something we're doing wrong, it could improve
> performance on a /lot/ of integrated intel gpus.
Apparently ex_opengl uses an FBO in the same way the ex_bitmap_target
example does. ex_opengl shows 350fps, where as ex_bitmap_target in "Direct"
mode still shows 7-10fps
I /REALLY/ think this should be fixed. If I knew what was wrong, I'd fix it,
but I don't. Someone who knows GL should look into this.
--
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx