Re: Extending LuaJIT ffi.load library?

[Adam Strzelecki <ono@...>]

Michal,

Thanks a lot for the suggestion, it works like a charm now with:

local g = require('glut')
local ffi = require('ffi')
local M = {}
local glFloatv = ffi.typeof('GLfloat[?]')
M.glFloatv = function(...)
  return glFloatv(select('#', ...), ...)
end
M.glMaterial = function(face, type, ...)
  return g.glMaterialfv(face, type, glFloatv(select('#', ...), ...))
end
M.glLight = function(face, type, ...)
  return g.glLightfv(face, type, glFloatv(select('#', ...), ...))
end
setmetatable(M, { __index = g })
return M

I can now call in my code:

g.glMaterial(g.GL_FRONT, g.GL_SPECULAR,  1, 1, 1, 1);
g.glMaterial(g.GL_FRONT, g.GL_SHININESS, 5);
g.glLight(g.GL_LIGHT0, g.GL_POSITION, 10, 10, -10, 0);

Probably putting to few params in the function will blow the app, but I don't care for now.

Cheers,
-- 
Adam Strzelecki

Wiadomość napisana przez Michal Kottman w dniu 21 gru 2011, o godz. 18:20:

> 2011/12/21 Adam Strzelecki <ono@java.pl>:
>> Hi,
>> 
>> I am trying to do some OpenGL via LuaJIT FFI. I've made 'gl' module that does cdef from gl.h file and and returns ffi.load('GL'). One can use it via `local gl = require('gl')`. Everything works great so far (using GLUT as well).
>> 
>> Now I want to provide some convenience functions for OpenGL functions expecting non-simple pointer types, such as glMaterialfv, so instead calling:
>> 
>>  gl.glMaterialfv(g.GL_FRONT, g.GL_SPECULAR,  ffi.new('GLfloat[4]', 1, 1, 1, 1));
>> 
>> One can call without using ffi (hiding ffi internals):
>>  gl.glMaterial(g.GL_FRONT, g.GL_SPECULAR, 1, 1, 1, 1)
>> 
>> When I try to make my wrapped using:
>>  gl.glMaterial = function(where, type, …)
>> 
>> I get missing declaration for symbol 'glMaterial' in function '__newindex'. This is expected as 'gl' isn't a table. But then alternatively to have single namespace I could just remap all functions into new table:
>>  M.function = glffi.glFunction
>> 
>> Such table could be extended with new entries for convenience functions and will make code look clear & pretty and be extensible, but will kill probably lookup overhead elimination as well (not recommended in http://luajit.org/ext_ffi_tutorial.html#cache).
>> 
>> So what would be the best solution? Anyone of you had similar problem? What was the solution in your case?
> 
> I had a similar problem with OpenCL. I am using the OpenCL FFI
> bindings created by Dimiter Stanev [1]. There are some Lua functions
> that I would like to export from the module, but for the rest I want
> to use the C functions from the OpenCL library.
> 
> I solved it by creating the Lua functions in an extra table and
> setting metatable __index to lookup in OpenCL namespace:
> 
> local ffi  = require( "ffi" )
> local cl   = ffi.load( "OpenCL" )
> local ext = {} -- this will be the returned module
> 
> -- extra function go into the `ext` table
> function ext.GetPlatforms() ... end
> function ext.GetDevices(platform_id) ... end
> 
> -- setup metatable with __index on `ext` to look up functions in the
> `cl` namespace
> setmetatable(ext, {__index=cl})
> 
> -- return `ext` as the module
> return ext
> 
> 
> [1] https://github.com/malkia/ufo
>