Jump to content
  • Advertisement
Sign in to follow this  
_the_phantom_

OpenGL New Extension Spec Released!

This topic is 4925 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Oh happy day! The final spec for the EXT_framebuffer_object extension has been released [grin] For those who dont know what it is, its a spec to give OpenGL a sane render to texture interface, none of this fighting with pbuffers lark, instead it provides a cleaner interface, removes the need for context switching AND the rendered data sticks with the texture (or other buffer) and thus doesnt remain part of another buffer. The spec is supported by both NV and ATI, both of whom have been very commited to this spec as its had over 100 revisions and 29 people working on it, and while currently no driver support exists (last revision was dated the 17th Jan 05, so I think they can be let off, my current feeling is March for driver support at the soonest) I'd urge everyone to take a look at it coz its the future of render-to-texture. It also includes a function to generate mipmaps, so finer control can be granted over that operation (as much as I love the automagical mipmap generation I can see the advantages of knowing when your mipmaps are updated). Extension spec a power point presentation from the group who made it, detailing infomation on the extension This has been a phantom public service broadcast.

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by Ademan555
YAY!!!!
Hrm though, what ever happened to über buffers?... or am i all mixed up? :-D glad to hear it though.
-Dan


Uberbuffers has been pushed back a bit (probably coming OGL3.0), something todo with it being overly complex to impliment in the drivers, not everyone agreeing on it and hardware not supporting it. This extension is more or less a subset of the Uberbuffers system, turned out by the same working group, because the functionality is so needed

Share this post


Link to post
Share on other sites
I got an insider tip a few days ago that it would be out "within the next couple of days", so I wanted to be the first to post a thread about it - Gah, apparently I've been a little slow [grin]

Anyway, very good news indeed. Hopefully the first implementations will follow shortly, so that we can test it in practice and get the bugs out. This phase took some time with VBO, so I fully expect some awkward behaviour in the first driver releases supporting this. But since the specs are fixed, we can now all trash the old pbuffer paths in our engines - Yay !

This made me laugh though:
Quote:

Status

Ubercomplete

Share this post


Link to post
Share on other sites
Well, from an initial read this looks like a great extension.
Any ideas what the minimum level of hardware will be for supporting it?


This made me laugh though

Quote:

Issues

(1) We obviously won't call this "ARB_compromise_buffers", so
what name should we use?

Share this post


Link to post
Share on other sites
Quote:
Original post by noisecrime
Well, from an initial read this looks like a great extension.
Any ideas what the minimum level of hardware will be for supporting it?

Hopefully it'll also be available on older hardware. I don't see why this wouldn't be supported on GF2/3/4/5 level hardware. At the very worst, it can always fall back to an internal copy pass.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!