Re: News from my coding front

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 <[email protected]> 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
[email protected]
http://www.haskell.org/mailman/listinfo/hopengl