Re: [HOpenGL] News from my coding front

Hi, I have to think about how non-square matrices fit in, but I'm not fundamentally opposed to adding them. In general, I have been musing about an API reorganization for a while now, so if you have suggestions I'm happy to hear about them. Balazs On Fri, Jul 1, 2011 at 10:45 PM, L Corbijn wrote:

I just forgot one major point, we NEED matrices as you can load them into shader objects and the current Matrix class is only meant to be used in the OpenGL 1-2 state machine. Balazs Komuves' package (mentioned in [2], hackage [3]) looks good, but is missing support for non square matrices as far as I can see. But a good implementation (In the OpenGL package or some other) is really needed.

Lars Corbijn

[2] http://www.haskell.org/pipermail/hopengl/2011-May/001016.html [3] http://hackage.haskell.org/package/vect

http://www.haskell.org/pipermail/hopengl/2011-May/001016.html

On Fri, Jul 1, 2011 at 10:19 PM, L Corbijn wrote:

...

Hello,

My work on implementing extra functions to make the OpenGL library compattible with version 3 of the spec is quite far. But completing the work quite depends on what to do with the API with regard to texturing. The OpenGL 3 spec adds quite a few targets for textures, and as I've pointed out in [1] it needs some breaking changes to make it scaleable. So my first question is what to do with the texturetarget api, there are as far as I can see three options 1 leave it as is and implement the dependencies (framebufferobjects) analogous. 2 make a new one a side from the current (extra user import). 3 make a breaking change to a new api.

Apart from that there is some extra work I've still to do - TexParameterI{i ui}v (for integer lookup for TEXTURE_BORDER_COLOR) - Some framebuffer operations (4.1-4.3)

And I want to rewrite some framebufferobject (FBO) related code, I'm not happy with the way FBO-attachment-points are defined. There are some several functions that take framebuffer(object)s as argument, and the allowed type of buffers depend on the function. As far as I see it now it probably leads to having all the FBO-attachments to be defined in BufferMode, and a second time for use by FBO specific functions. If people have better ideas on how to restrict what type of drawbuffers can be passed to functions I would be very interested. (Mind you, some of these need to be unmarshalled).

The third and last question is how much testing there has to be done on the code. Most, if not all, code I've generated is only tested to compile. Actual run time testing is quite some work (generating test examples, setting up redendering, etc.). I've been working on a little framework but I doubt it will finish (as with more of my ideas ;), if somebody is interested let me know.

Greetings, Lars Corbijn

[1] http://www.haskell.org/pipermail/hopengl/2011-June/001025.html

_______________________________________________ HOpenGL mailing list HOpenGL@haskell.org http://www.haskell.org/mailman/listinfo/hopengl