There would have to be a large enough demand for the feature, which doesn’t seem to be the case. The last 6 months or so I don’t think I’ve had anyone asking for it.
In my case I was waiting for FBO the last 6 months
The only thing I was hoping for is to finally have a single path on all cards for HDR and other postprocessing. Until now I was using render-to-pot-textures, because no render-to-rectangle/npot was available on ATI cards. This is a waste of videomemory and introduces other complications. NPOT textures are of course well to handle, but rectangle textures might have more advantages like being available on a broader range of gfx cards (especially older ones)and you can address neighbour pixels more easily.
Maybe we should start a poll on this, in order to see what the developers really want…
Originally posted by Humus:
This was a problem in the early stage of development, which is what you have in 5.6, but was fixed soon after. Simply using GL_BGRA instead should fix it.[/QB]
Just tried FBO (on an ATI 9800 / Catalyst 5.6).
I had the same problem ‘Red’ and ‘Blue’ inverted.
I’ve tried ‘internal_format’ set to GL_RGB8 and ‘texture_fromat’ set to GL_BGR_EXT (instead of GL_RGB) and had an ‘GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT_EXT’ then after the glFramebufferTexture2DEXT
I’ve also tried floating point (HDR) cube maps and GLSL with FBO (instead of PBuffer), but the rendering was very broken.
Didn’t test the rectangle textures with FBO yet.
Ah, also depth component FBO was not working (for rendering to depth buffer), but this was expected.
Else, on Catalyst 5.5, nothing was working : status was returning 0, which is not even a standard code.
I hope to see a better version next month.
Also a registry key to enable the GL_EXT_framebuffer_object would be also a good idea.
a reg key isnt really required, most extension loading systems should allow you to force an extension to load (if it can find the right bind points, I know GLee allows you todo this), so just set that up and jobs a goodern.
The reg key trick is usually used by nVidia, and I find it very convenient. Too bad. Also this allow some programs using FBO being tested (could be a good thing for ATI, if they want to test FBO extensively, there is a more and more program using it now).
I’m using glew + the glewExperimental flag that allowed me to load the extension properly.
Ah, also noticed that FBO + Multisampling simply doesn’t work. Seeing that, I think I will wait next year for ATI + FBO now
Ah, also noticed that FBO + Multisampling simply doesn’t work.
FBO doesn’t work with multisampling period. It’s part of the spec that it doesn’t do multisampling. They’re working on some kind of extension to create multisample buffers or somesuch.
Well, you can’t multisample the render target, but it should work to use FBOs when you have multisample on the main framebuffer. Again, in early development (which is what you have in 5.6) there was an issue with this, but was fixed pretty soon.
Yes, it was a multisampled primary buffer and single buffer FBO that I was talking about, and not multisampled FBO. Simply nothing is rendered. But apparently this will be fixed already.
