That example hasn't been updated yet. Try examples/misc/opengl-array.lisp instead.
Thank you Luis,
The demo works for me and now it is clear how it works (in most aspects). So I can compare the implementation in the cl-opengl-thomas branch with mine. I will use "T" as an alias for the cl-opengl-thomas branch and "D" as an alias for mine.
MEMORY CONTAINERS ----------------- T: Any manipulations on vertex arrays are made in native memory. The arrays are typed in a very nice manner (and I guess this is made thanks to the features from the new CFFI). D: The vertex arrays are stored in memory structures native to LISP (1D and 2D arrays, sequences). The arrays are typed at the point of the actual declaration of arrays to the OpenGL when the implementation implicitly copies the data to the native arrays. A support for direct native arrays can be added, but that's not yet ready.
MEMORY MANAGEMENT ----------------- In both cases the memory management is performed correctly in the sense that the arrays are available for the OpenGL whenever it needs it. However...
T: The memory must be allocated and freed explicitly. D: The memory is allocated and deallocated implicitly unless user requires something else.
CLIENT STATE MANAGEMENT ----------------------- T: The client state is managed using enable/disable-client-state functions. D: The client state is managed automatically. When a vertex array is declared, the respective client state is turned on. When it is declared to be null, the client state is turned off.
SUPPORT FOR DIFFERENT KINDS OF VERTEX ARRAYS -------------------------------------------- T: At least the "vertex array" is supported. It is not clear for me if the rest of arrays like color arrays and edge flag arrays are supported. Probably they are not. D: All kinds of vertex arrays are supported.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
MY CONCERNS ----------- For me, the main concern regarding the approach in cl-opengl-thomas branch is that the speed of memory access for this new kind of native arrays is questionable. You see, before implementing the support for Vertex Arrays I spent a day with the SBCL trying to figure out what is the fastest way to access the native arrays. The disassembled code does not look great even for ordinary typed LISP arrays. For simple 1D native arrays is is slightly worse. And for the memory access like this:
(setf (gl:glaref (vertex-array w) i 'r) 255)
The "disassemble" shows and enormous listing. That's because there is a sequence of function calls just to fill out a cell in the array.
PROPOSED SOLUTION -----------------
I propose a hybrid solution which will allow for both ease of use and efficiency.
MEMORY CONTAINERS & MEMORY MANAGEMENT ------------------------------------- An approach closed to solution D is used, so that it is possible to use data structures native to LISP and provide a fast way of doing things. However, the code is modified in a way that if a user wants to use a native array directly, he can do it. In such case, it is the native arrays passed to the respective function which is declared to the OpenGL. Otherwise, the data structure will be copied to the native array and managed automatically.
This will give benefits of both approaches.
CLIENT STATE MANAGEMENT ----------------------- I'd prefer an automatic one, but I do not insist on it in any way. :-)
Please, let me know what you think.
I am looking forward for the most high-performance 3D in LISP so an effective an usable support for Vertex Arrays / shaders / etc. is very interesting for me.
Thank you, Denys Rtveliashvili
P.S. And by the way, can the new features from cffi-newtypes be merged into the main CFFI?