Re: 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 <[email protected]> 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 <[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
>
>

_______________________________________________
HOpenGL mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/hopengl