Hello all, I searched for current efforts on adding EXT_framebuffer_object support to HOpenGL but was unable to locate anything. I've added the very beginnings of EXT_framebuffer_object support. Attached (in theory) is the current patch. I've only added the bare minimum required to render to a 2D texture and am not sure if the style matches the current style. If the patch was stripped from this email the changes can be pulled from: http://www.tothepowerofdisco.com/repo/OpenGL Cheers, Corey O'Connor
Hello, Actually I did the exact same thing. My "EXT_framebuffer_object" support is fairly complete, and I tried to match the existing style, but it is not really tested apart from a simple example. I also attached a patch which adds support for using Vertex Attributes in Vertex Arrays (which is standard OpenGL, not an extension, but was missing), but that one is completely untested; and also a bugfix (uniformLocation and friends). Balazs On Wed, Dec 17, 2008 at 9:32 AM, Corey O'Connor <coreyoconnor@gmail.com>wrote:
Hello all, I searched for current efforts on adding EXT_framebuffer_object support to HOpenGL but was unable to locate anything. I've added the very beginnings of EXT_framebuffer_object support. Attached (in theory) is the current patch. I've only added the bare minimum required to render to a 2D texture and am not sure if the style matches the current style.
If the patch was stripped from this email the changes can be pulled from: http://www.tothepowerofdisco.com/repo/OpenGL
Cheers, Corey O'Connor
_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl
Excellent stuff! I like having the framebuffer texture functions check the status as well. That's a handy addition. So how do we get your patch into the mainline repo? I'd hate to have another person duplicate the same work again. Cheers, Corey O'Connor On Wed, Dec 17, 2008 at 4:19 AM, Balazs Komuves <bkomuves@gmail.com> wrote:
Hello,
Actually I did the exact same thing. My "EXT_framebuffer_object" support is fairly complete, and I tried to match the existing style, but it is not really tested apart from a simple example. I also attached a patch which adds support for using Vertex Attributes in Vertex Arrays (which is standard OpenGL, not an extension, but was missing), but that one is completely untested; and also a bugfix (uniformLocation and friends).
Balazs
On Wed, Dec 17, 2008 at 9:32 AM, Corey O'Connor <coreyoconnor@gmail.com> wrote:
Hello all, I searched for current efforts on adding EXT_framebuffer_object support to HOpenGL but was unable to locate anything. I've added the very beginnings of EXT_framebuffer_object support. Attached (in theory) is the current patch. I've only added the bare minimum required to render to a 2D texture and am not sure if the style matches the current style.
If the patch was stripped from this email the changes can be pulled from: http://www.tothepowerofdisco.com/repo/OpenGL
Cheers, Corey O'Connor
_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl
_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl
I think we should have some testing and code review before trying to merge it with the official repository (there is a reason I did not publicised this before, though the FBO stuff is fairly new). For example I just discovered two (very minor) bugs by trying to generate Haddock documentation. The API isn't set into stone either; I hope it's reasonable enough, but some changes may be beneficial. After that, well, Sven Panne reads this mailing list, and he is the maintainer. It would be nice to hear his opinion. Balazs On Wed, Dec 17, 2008 at 6:58 PM, Corey O'Connor <coreyoconnor@gmail.com>wrote:
Excellent stuff! I like having the framebuffer texture functions check the status as well. That's a handy addition. So how do we get your patch into the mainline repo? I'd hate to have another person duplicate the same work again.
Cheers, Corey O'Connor
On Wed, Dec 17, 2008 at 11:12 AM, Balazs Komuves <bkomuves@gmail.com> wrote:
I think we should have some testing and code review before trying to merge it with the official repository (there is a reason I did not publicised this before, though the FBO stuff is fairly new). For example I just discovered two (very minor) bugs by trying to generate Haddock documentation. The API isn't set into stone either; I hope it's reasonable enough, but some changes may be beneficial.
Hm. I certainly agree that testing and API review is required for release. However I'd prefer other developers to have easy access to these patches through a main development repository than not. If API stability is a concern with the main repository then I suggest having two repositories: One for development and another for stable use. Cheers, Corey
On Wed, Dec 17, 2008 at 6:58 PM, Corey O'Connor <coreyoconnor@gmail.com> wrote:
Excellent stuff! I like having the framebuffer texture functions check the status as well. That's a handy addition. So how do we get your patch into the mainline repo? I'd hate to have another person duplicate the same work again.
Cheers, Corey O'Connor
Having a separate public development repo for the experimental stuff is a good idea. Maybe we can ask for project space on the code.haskell.org community server? They have all the infrastructure in place already. Balazs
Hm. I certainly agree that testing and API review is required for release. However I'd prefer other developers to have easy access to these patches through a main development repository than not. If API stability is a concern with the main repository then I suggest having two repositories: One for development and another for stable use.
Cheers, Corey
On Wed, Dec 17, 2008 at 6:58 PM, Corey O'Connor <coreyoconnor@gmail.com> wrote:
Excellent stuff! I like having the framebuffer texture functions check the status as well. That's a handy addition. So how do we get your patch into the mainline repo? I'd hate to have another person duplicate the same work again.
Cheers, Corey O'Connor
participants (2)
-
Balazs Komuves -
Corey O'Connor