Eduardo Cavazos wrote:
The type of the second parameter of gl function glGetDoublev is GLdouble*. So, I'd like to be able to pass an f64vector as that argument.
The declaration of glGetDoublev is:
void glGetDoublev( GLenum pname, GLdouble *params )
So something along these lines I guess:
(define glGetDoublev (c-lambda (GLenum scheme-object) void " glGetDoublev ( ___arg1 , UNPACKTHEVEC( ___arg2 ) ) ; "))
Except with the proper unpacking of ___arg2. Any suggestions as to what macro to use there? I'm looking through gambit.h...
Marc Feeley wrote:
There is no builtin Scheme to C converter for homogeneous vectors (u8vector, f64vector, ...). A converter for these types is conceivable but a couple of issues makes it non-trivial:
- A Scheme vector has a length, and often the length of the vector may
vary from one call to another (i.e. the length is a dynamic property). How is the length of the vector passed to C? When a C array is passed to Scheme, how does the converter determine how long the array is?
- To avoid GC problems (and in keeping with the other Scheme to C
converters) a copy of the vector would have to be made in a C array. Unfortunately, for some functionality, the extra cost of doing the copy may cancel the benefit of performing the computation in C.
- Sometimes the vector is supposed to be mutated by the C function, and
the result of the mutations must be available to the Scheme code. If the vector is copied the C function's mutations aren't preserved.
I have given some thought about various solutions to these problems, but nothing definite yet.
In the meantime you can use the ___BODY(vect) macro in your code, it returns a pointer to the first element of the vector:
(define glGetDoublev (c-lambda (GLenum scheme-object) void " glGetDoublev ( ___arg1 , ___CAST(___F64*,___BODY(___arg2)) ); "))
But beware... this assumes that the GC doesn't get invoked during the call glGetDoublev (because a GC might move the vector). Even if the GC isn't called explicitly, it is conceivable a GC could be invoked asynchronously in a (real) multithreaded implementation of Gambit (impossible in the current runtime system, but who knows... maybe a multithreaded GC will be added in the future).
Thanks for the help Marc; it worked perfectly.
One of my stress tests for Scheme/OpenGL is an implementation of ContextFreeArt. A few moments ago Gambit completed it's first rendering:
http://proteus.freeshell.org/spirales-gambit-2009-03-23.png
I'm having a good time with Gambit! Very interesting system.
Ed