all: LibGL LibGlut

clean:
rm *.o *.so

%.o: src/%.c
$(CC) $(CFLAGS) -c $< -o $@

LibGL: LuaGL.o
$(LD) $(LFLAGS) -o luagl.so LuaGL.o

LibGlut: LuaGlut.o
$(LD) $(LFLAGS) -o luaglut.so LuaGlut.o

[[/code]]

In the file luagl.c says:

 #include <malloc.h> 

it doesnt work in mac osx (because doesnt come with it), its better to change it to:

 #include <stdio.h> 

that seems to be the main problem at runtime because it keeps telling me the following error:

lua(19956,0xa000ed88) malloc: *** Deallocation of a pointer not malloced: 0x84c28;

anyone has an idea?

In the case that you are on Windows XP, can you sent me the binaries you produced?

However I found it troublesome to use this lib due to weird crashes. I finally found the glitch which is located in get_array2f. The function is not balancing the lua VM stack. I fixed the loop that caused a stackoverflow that lead to a crash somewhat later (thus hard to track down the error).

 for(i = 0; i < n; i++) { lua_rawgeti(L, index, i+1); if(!lua_istable(L, -1)) { lua_pop(L,1); // undo the change to the stack, normally not necessary return -1; } for(j = 0; j < *size; j++) { lua_rawgeti(L, -1, j + 1); (*array)[i*(*size) + j] = (GLfloat)lua_tonumber(L, -1); lua_pop(L, 1); // lua_remove(L,-1) equivalent } lua_pop(L,1); // pop the row off } 

I also saw during examination that there is a memory leak in the texture function gl_tex_image.
The function returned without freeing the pixels array, i.e.

 if((height = get_array2f(L, 4, &pixels, &width)) != -1) { glTexImage2D(GL_TEXTURE_2D, (GLint)lua_tonumber(L, 1), iformat, width/iformat, height, 0, e, GL_FLOAT, pixels); free(pixels); // I added this line return 0; } 

In other places existed the same glitch.

—zet

1. Create a GLUT project through the codeblocks project wizard and make sure that it compiles and runs.
2. Then Rename main.cpp to LuaGL.c and replace the contents with the ones found in the fabiowguerra/svn/src/LuaGL.c
3. Add a File->New->File..->C/C++ Header File, LuaGL.h paste the contents of the respective file from fabiowguerra/svn/include/LuaGL.h
4. Continue the same process for the rest of the files. LuaGlu, LuaGlut, LuaGlAux.
5. Create a new Dynamic Library build target from the menu File -> New.
6. Add the liblua5.1.lib to the linker tab for the whole project in the Build Options dialog.
7. Press built for the dll built target and watch the errors go!

At the moment I am having a lot undefined references from LuaGlu.c on the Lua API functions.

Thanks for the info. I did end up getting it to work.

Cheers

I'm currently working on an engine that supports opengl and lua and i found your project most helpful. I miss the glu function in the 1.01 release so i now use the trunks 1.02-beta release. Currently the trunk has a few problems compiling on Windows.

I would like to know if there will be a new release coming that i can incorporate in my application and when we can expect it.

Regards,
Leon

I do not have experience with OS X.

But if you are just extending an OpenGL application, you can simply include LuaGL.c in your project and add LuaGL headers to your include path, that should work.

If you need to use glut, you can create a dynamic library, linking LuaGL.c and LuaGlut.c (and LuaGlu.c and LuaGLAux.c, if using the SVN version). The dependencies are on Lua, OpenGL, GLU and GLUT.

I'm using the following makefile on linux, but I think it is not very portable. I'm accepting suggestion on how to build a more portable makefile…

CC = gcc
LD = ld
INC = -Iinclude -Isrc -I/usr/include/lua5.1
LIB = -lGLU -lGL -lm -llua5.1
CFLAGS = -Wall -fPIC -c $(INC)
LFLAGS = $(LIB)
LGLUT = -lglut

all: luagl luaglu luaglut

luagl: LibLuaGL
luaglu: LibLuaGlu
luaglut: LibLuaGlut

clean:
rm *.o *.so

LuaGLAux.o: src/LuaGLAux.c
$(CC) $^ $(CFLAGS) -o $@

LuaGL.o: src/LuaGL.c
$(CC) $^ $(CFLAGS) -o $@

LuaGlu.o: src/LuaGlu.c
$(CC) $^ $(CFLAGS) -o $@

LuaGlut.o: src/LuaGlut.c
$(CC) $^ $(CFLAGS) -o $@

LibLuaGL: LuaGL.o LuaGLAux.o
$(LD) $(LFLAGS) -shared -o LuaGL.so LuaGL.o LuaGLAux.o

LibLuaGlu: LuaGlu.o LuaGLAux.o
$(LD) $(LFLAGS) -shared -o LuaGlu.so LuaGlu.o LuaGLAux.o

LibLuaGlut: LuaGlut.o
$(LD) $(LFLAGS) $(LGLUT) -shared -o LuaGlut.so LuaGlut.o

Hope this helped you.

Fabio

Cheers,
Scott

Fabio

I copied my SVN branch to trunk. It has a lot of improvents, bugfixes and is more stable than LuaGL 1.01.
I recommend everyone to use this version.

It can be downloaded using the followin command:

svn co https://luagl.svn.sourceforge.net/svnroot/luagl/trunk

For those who don't have SVN installed, it can be downloaded at <subversion.tigris.org>.

The new LuaGL version will be released probably on March. It will be backward compatible with the previous versions.
It need only some small changes and a Makefile, probably using autoconf and automake to configure OpenGL, GLU and Glut libs.

I'm accepting help to build this Makefile, since i'm out of time to work on LuaGL until March.

Fabio

Please test with the trunk version on SVN. It is compatible with luagl 1.01 and has a lot of bugfixes and the a lot better tests and samples.

Fabio

which compiles just fine, but when I try to load test2.lua I get:

lua5.1.exe: error loading module 'luagl' from file '.\luagl.dll':
The specified procedure could not be found.

stack traceback:
[C]: ?
[C]: in function 'require'
test2.lua:1: in main chunk
[C]: ?

Thanks for your suggestion I implemented glut.DestroyWindow in my SVN branch. It will be on the next release.
But my implementation is a little different from yours.

I changed glut.CreateWindow to return the window identifier. And the glut.DestroyWindow will receive the identifier.
This way it will be possible to handle multiple windows.

I recomend everyone to use the SVN version, there are lots of improvements and bug fixes there..

PS: The next release will happen only on March or April, because I will defend my MSc Dissertation on March. But it is almost done, but I still need to create a makefile to it. Any suggestions for the makefile? Need to use autoconf/automake?

Fabio

So the main question is: where the glut window number will be stored and how will be accessed?

To quickly add glut.DestroyWindow function do the following:

• Edit luaglut.c file.
• Add new line after all #include directives, such as:

 int window; 

• Prepend line in function glut_create_window with window= so it look like this:

 window = glutCreateWindow((const char *)lua_tostring(L, 1)); 

• Add new function glut_destroy_window:

 static int glut_destroy_window(lua_State *L) { glutDestroyWindow(window); return 0; } 

• Add new constant into glutlib at the end of file

 {"DestroyWindow", glut_destroy_window} 

That is it.

Another thing I noticed in the source is that you've made functions to call gl functions that don't take arguments and don't give returns, like glEnd. In this case can't you just use a pointer to the original gl function instead? I don't know much about C but I've tried it in FreeBasic and it does work

gl.Clear("DEPTH_BUFFER_BIT | COLOR_BUFFER_BIT")
gl.Clear(gl.DEPTH_BUFFER_BIT + gl.COLOR_BUFFER_BIT)

We provide first notation cause there is a possiblity that bitwise oprations can give other results some times.
Second one gives better performance.

Best.

As a bit of a challenge to myslef however, I've just started an attempt to translate the source code into FB

Now, I know that adding them isn't the same as doing a bitwise or, but it works just fine in lua player so why can't it work here?

I think it's a little waste of time, two people doing the same work…

But anyway I'll create a small performance test to this feature. The fastest patch (that compiles in ANSI C without warnings) will be on the next release.

In my branch I modified the unit test to use a modified version of luaunit (original version was not working with lua5.1), i will try to commit a get_enum test in end of this week.

gl.Clear("DEPTH_BUFFER_BIT,COLOR_BUFFER_BIT")
gl.Clear("DEPTH_BUFFER_BIT, COLOR_BUFFER_BIT")
gl.Clear("DEPTH_BUFFER_BIT ,COLOR_BUFFER_BIT")
gl.Clear("DEPTH_BUFFER_BIT , COLOR_BUFFER_BIT")
gl.Clear("DEPTH_BUFFER_BIT|COLOR_BUFFER_BIT")
gl.Clear("DEPTH_BUFFER_BIT| COLOR_BUFFER_BIT")
gl.Clear("DEPTH_BUFFER_BIT |COLOR_BUFFER_BIT")
gl.Clear("DEPTH_BUFFER_BIT | COLOR_BUFFER_BIT")

 15a16,19 > > #if defined (__APPLE__) || defined (OSX) > #include <stdlib.h> > #else 16a21,25 > #endif > > #ifdef __cplusplus > extern "C" { > #endif 19a29,36 > #ifdef __cplusplus > } > #endif > > #include <string> > > using namespace std; > 21a39,41 > #define LUA_GL_STRING_TO_ENUM_TABLE "LuaGL_string_to_enum_table" > #define LUA_GL_ENUM_TO_STRING_TABLE "LuaGL_enum_to_string_table" > 32c52 < static GLenum get_enum(const char *str, int n) --- > GLenum get_enum(lua_State *L, const char *key) 34c54 < int i = 0; --- > GLenum val; 36,39c56,57 < while(gl_str[i].str != 0) < { < if(strncmp(str, gl_str[i].str, n) == 0 && gl_str[i].str[n] == 0) < return gl_str[i].value; --- > lua_getfield(L, LUA_REGISTRYINDEX, LUA_GL_STRING_TO_ENUM_TABLE); > lua_getfield(L, -1, key); 41c59,60 < i++; --- > if(lua_isnil(L, -1)) { > val = ENUM_ERROR; 43c62,63 < return ENUM_ERROR; --- > else { > val = (GLenum)lua_tointeger(L, -1); 45,49c65 < static GLenum get_gl_enum(lua_State *L, int index) < { < unsigned int i; < const char *str = lua_tostring(L, index); < GLenum temp = 0, ret = 0; --- > lua_pop(L, 2); //pop value and enum table 51c67,70 < for(i = 0; i < strlen(str); i++) --- > return val; > } > > GLenum get_gl_mask_enum(lua_State *L, const char *key, char token) 53c72,77 < if(str[i] == ',') --- > GLenum val = 0; > string mask(key); > size_t pos = 0, substr_start = 0, last_pos = 0; > > pos = mask.find(token, substr_start); > while(last_pos != string::npos) 55,57c79,90 < temp = get_enum(str, i); < if(temp != ENUM_ERROR) < ret |= temp; --- > int end_off = 0; > > //check for leading and trailing spaces > if(mask[substr_start] == ' ') { > substr_start++; > } > > if(mask[pos - substr_start - 1] == ' ') { > end_off = 1; > } > > string bit = mask.substr(substr_start, pos - substr_start - end_off); 59,60c92,96 < str += i+1; < i = 0; --- > val |= get_enum(L, bit.c_str()); > > substr_start = pos+1; > last_pos = pos; > pos = mask.find(token, substr_start); 61a98,99 > > return val; 63d100 < temp = get_enum(str, strlen(str)); 65c102 < if(temp == ENUM_ERROR) --- > LUAGL_API GLenum get_gl_enum(lua_State *L, int index) 67,69c104,116 < if(ret == 0) < return ENUM_ERROR; < return ret; --- > const char *key = lua_tostring(L, index); > GLenum val = 0; > char token1 = ',', token2 = '|' ; > > //detect if multiple enums as a bit mask > if(strchr(key, token1)) { > val = get_gl_mask_enum(L, key, token1); > } > else if(strchr(key, token2)) { > val = get_gl_mask_enum(L, key, token2); > } > else { > val = get_enum(L, key); 72c119 < return ret | temp; --- > return val; 75c122 < static const char *get_str_gl_enum(GLenum num) --- > LUAGL_API const char *get_str_gl_enum(lua_State *L, GLenum num) 77c124 < unsigned int i = 0; --- > const char *val; 79,82c126,130 < while(gl_str[i].str != 0) < { < if(num == gl_str[i].value) < return gl_str[i].str; --- > lua_getfield(L, LUA_REGISTRYINDEX, LUA_GL_ENUM_TO_STRING_TABLE); > lua_pushnumber(L, num); > lua_gettable(L, -2); > val = lua_tostring(L, -1); > lua_pop(L, 2); //pop value and enum table 84,86c132 < i++; < } < return NULL; --- > return val; 202c248 < static int get_array2d(lua_State *L, int index, GLdouble **array, int *size) --- > static int get_array2d(lua_State *L, int index, GLdouble **array, GLint *size) 215c261 < *size = luaL_getn(L, -1); --- > *size = (GLint)luaL_getn(L, -1); 238c284 < static int get_array2f(lua_State *L, int index, GLfloat **array, int *size) --- > static int get_array2f(lua_State *L, int index, GLfloat **array, GLsizei *size) 251c297 < *size = luaL_getn(L, -1); --- > *size = (GLsizei)luaL_getn(L, -1); 526,529d571 < const char *arg; < const char *delims = "|,"; < char arg_buffer[256]; < char *result = NULL; 532,549c574,576 < // test argument type < if(lua_type(L, 1) != LUA_TSTRING) { < script_error(L, "incorrect argument to function 'gl.Clear'"); < } < < arg = lua_tostring(L, 1); < < if(strlen(arg) > 256) { < script_error(L, "incorrect argument to function 'gl.Clear'"); < } < < strcpy(arg_buffer, arg); < result = strtok(arg_buffer, delims); < while( result != NULL ) { < printf("result: %s\n", result); < result = strtok(NULL, delims); < } < --- > /* test argument type */ > if(!lua_isstring(L, 1)) > luaL_error(L, "incorrect argument to function 'gl.Clear'"); 553,556c580,582 < // test argument < if(e == ENUM_ERROR) { < script_error(L, "incorrect string argument to function 'gl.Clear'"); < } --- > /* test argument */ > if(e == ENUM_ERROR) > luaL_error(L, "incorrect string argument to function 'gl.Clear'"); 557a584 > /* call opengl function */ 1418c1445 < static gl_front_face(lua_State *L) --- > static int gl_front_face(lua_State *L) 1503c1530 < int mask; --- > GLint mask; 1641c1668 < str = get_str_gl_enum(params[i]); --- > str = get_str_gl_enum(L, params[i]); 1766c1793 < lua_pushstring(L, get_str_gl_enum(error)); --- > lua_pushstring(L, get_str_gl_enum(L, error)); 1950c1977 < int size; --- > GLint size; 2020c2047 < glGetPointerv(e, (void *)&flags); --- > glGetPointerv(e, (GLvoid **)&flags); 2035c2062 < glGetPointerv(e, (void *)&params); --- > glGetPointerv(e, (GLvoid **)&params); 2096c2123 < int e2; --- > GLint e2; 2113c2140 < lua_pushstring(L, get_str_gl_enum(e2)); --- > lua_pushstring(L, get_str_gl_enum(L, e2)); 2142c2169 < int e3; --- > GLint e3; 2160c2187 < lua_pushstring(L, get_str_gl_enum(e3)); --- > lua_pushstring(L, get_str_gl_enum(L, e3)); 2183c2210 < int width, height, level; --- > GLint width, height, level; 2258c2285 < int e; --- > GLint e; 2293c2320 < lua_pushstring(L, get_str_gl_enum(e)); --- > lua_pushstring(L, get_str_gl_enum(L, e)); 2412c2439 < static gl_is_list(lua_State *L) --- > static int gl_is_list(lua_State *L) 2425c2452 < static gl_is_texture(lua_State *L) --- > static int gl_is_texture(lua_State *L) 4108a4136,4139 > #ifdef __cplusplus > extern "C" { > #endif > 4110a4142,4172 > > //make sting_to_enum table > lua_pushstring(L, LUA_GL_STRING_TO_ENUM_TABLE); > lua_newtable(L); > { > int i=0; > while(gl_str[i].str) > { > lua_pushstring(L, gl_str[i].str); //strings as enum keys > lua_pushinteger(L, gl_str[i].value); //enum value as values > lua_settable(L, -3); //set table with (key, value) pair > i++; > } > } > lua_settable(L, LUA_REGISTRYINDEX); > > //make enum_to_string table (not unique) > lua_pushstring(L, LUA_GL_ENUM_TO_STRING_TABLE); > lua_newtable(L); > { > int i=0; > while(gl_str[i].str) > { > lua_pushinteger(L, gl_str[i].value); //enum value as keys > lua_pushstring(L, gl_str[i].str); //strings as enum values > lua_settable(L, -3); //set table with (key, value) pair > i++; > } > } > lua_settable(L, LUA_REGISTRYINDEX); > 4112a4175,4178 > > #ifdef __cplusplus > } > #endif 

I will create some tests for the enumerations. A patch must pass all tests.

The functon get_gl_enum wouldn't be called very often on most OpenGL applications. So I was not very worried about the performance at the original version.

Both solution (from wes and gwpl) are very good. In practice there will be no big difference between them.

For me it is not backward compatible, cause I can't see support for notation OR operation , I mean : "STH1,STH2" , what means in C: STH1 | STH2.

If I'm wrong let me know, Then will delete this post

 #define LUA_GL_STRING_TO_ENUM_TABLE "LuaGL_string_to_enum_table" #define LUA_GL_ENUM_TO_STRING_TABLE "LuaGL_enum_to_string_table" LUAGL_API GLenum get_gl_enum(lua_State *L, int index) { const char *key = lua_tostring(L, index); GLenum val; lua_getfield(L, LUA_REGISTRYINDEX, LUA_GL_STRING_TO_ENUM_TABLE); lua_getfield(L, -1, key); if(lua_isnil(L, -1)) { val = ENUM_ERROR; } else { val = (GLenum)lua_tointeger(L, -1); } lua_pop(L, 2); //pop value and enum table return val; } LUAGL_API const char *get_str_gl_enum(lua_State *L, GLenum num) { const char *val; lua_getfield(L, LUA_REGISTRYINDEX, LUA_GL_ENUM_TO_STRING_TABLE); lua_pushnumber(L, num); lua_gettable(L, -2); val = lua_tostring(L, -1); lua_pop(L, 2); //pop value and enum table return val; } 

And then add to luaopen_opengl

 lua_pushstring(L, LUA_GL_ENUM_TO_STRING_TABLE); lua_newtable(L); { int i=0; while(gl_str[i].str) { lua_pushinteger(L, gl_str[i].value); //enum value as keys lua_pushstring(L, gl_str[i].str); //strings as enum values lua_settable(L, -3); //set table with (key, value) pair i++; } } lua_settable(L, LUA_REGISTRYINDEX); 

It's completely backward compatible as all it is doing is replacing the while loop with a lua_gettable.

wes

Just look

 static GLenum get_enum(const char *str, int n) { gl_str_value *res, key; char *buf = malloc(n+1); strncpy(buf,str,n); buf[n]='\0'; key.str = buf; res = bsearch( &key, gl_str, gl_str_size, sizeof(struct gl_str_value), comp_gl_str_value ); free(buf); return (res!=NULL) ? res->value : ENUM_ERROR; } 

9 lines of code , where 1 is function prototype and is common, ~4 lines are data declaration and allocation, and rest : only ~5 lines are crucial…

1. I propose to make now new stable version of LuaGL as fast as possible.
2. This patch does not implement searching algorithm but uses one from library…
3. I've read your version of get_enum and I'm not sure if it is 100% backward compatible (I'm not sure to OR operation in your algorithm "," … we have to discuss this point on private…)
4. Please prepare small clear patch to trunk version to show us how do you want to merge your procedures with current trunk. If patch will be as small and as clear and 100% backward compatible with previous version of LuaGL it could be good thing.
5. I'm not sure if in that case Lua hashtable makes significant difference
6. Once again… as far as we make some cleanings (I mean fixing version 1.01 to make new as fast as possible and as most stable as possible ) in LuaGL , I think that smaller, and more clear patch == better patch.

I like more sophisticated concepts connected with get_enum function. Some time ago I was testing my own hashtables with hash functions specially prepared to that static set of data… but finally I realized that LuaGL need now small and stable solutions.
In next setps I think that your solution after performance tests have a big chance to be the winner as best balance between sophistication and performance… by I'm not sure if your solutions are ready to be merged into stable tree of LuaGL, as I didn't see standalone parch that makes that think.

This patch changes implementation of "static GLenum get_enum(const char *str, int n)". In previous implementation it was O(gl_str_size*n). Now it has complexity O(lg2(gl_str_size)*n).

I propose to make this implementation as temporary for 1.02 version of LuaGL,
cause it's:

• simple and small patch
• stable (uses well tested lib function bsearch)
• backward compatible
• it makes algorithm complexity much better

in effect it increases performance without stability cost and risk ;) (but it's my opinion).

GLU support (this would be nice to finish off. We're missing the gluSphere and other primitive calls. These are pretty trivial to bind. The NURBS stuff is more difficult)

Add an alternative semantic: "gl.Begin(gl.Point);" (This doesn't really bother me, but could be take care of with with the enum table so is not difficult)

Add OpenGL constants in LuaGL (I have code for this in my branch)
Improve get_enum function (same as above)
Add GLSL support. (I have code for this but maybe could come later)

Here's what my roadmap would look like:

1) Clean up headers by removing duplicate declarations from the gl and glu header files, consolidated in a single shared header. The shared header would also contain platform detection macros for choosing the proper gl, glu, and glut system headers

2) fix the enum/string conversion

3) remove as much malloc/free stuff as possible without too much trouble

4) finish up glu wrappers

5) develop a system for extensions

6) start work on a x-platform windowing system

… There are more but this can do for now. What do you all think?

For me most important ones are:

1. 2007-09-01-gw-LuaGlut_InitDisplayPatch_and_Include_of_GLUT
2. 2007-08-31-gw-0-sorted-values-in-tables
3. 2007-09-01-gw-tests_files_to_make_them_standalone

A description about each patch is in description file "-desc.txt" , here is a commit description:
http://luagl.wikidot.com/viewsvn/?view=rev&revision=15

Just a part…

This commit includes a set of most important patches to trunk and scripts that helps me in developing that patches. Each patch has description in PATCHNAME-desc.txt file. Scripts are self explaining, so just run it without parameter to see help info.

Commit includes following files:

• patch_trunk_with_current_gw-patches.sh

Use this script to patch directory with trunk version of LuaGL with Grzegorz Wierzowiecki's current patches.
(…)

• patches_to_trunk/2007-08-31-gw-0-sorted-values-in-tables.patch
• patches_to_trunk/2007-08-31-gw-0-sorted-values-in-tables-desc.txt

Puts values in tables in lexicographical order.

• patches_to_trunk/2007-08-31-gw-temporary-patch--that-adds-temporary-makefiles.patch
• patches_to_trunk/2007-08-31-gw-temporary-patch--that-adds-temporary-makefiles-desc.txt

Adds Makefiles… temporary thing.
See txt file for more info.

• patches_to_trunk/2007-09-01-gw-LuaGlut_InitDisplayPatch_and_Include_of_GLUT.patch
• patches_to_trunk/2007-09-01-gw-LuaGlut_InitDisplayPatch_and_Include_of_GLUT-desc.txt

Fixes glut.h inclusion problem and Display initialization on some platforms.
See txt file for more info.

• patches_to_trunk/2007-09-01-gw-tests_files_to_make_them_standalone.patch
• patches_to_trunk/2007-09-01-gw-tests_files_to_make_them_standalone-desc.txt

Make tests lua files runnable as standalone.
See txt file for more info.
(…)

to read more go here

So I think that we should now choose one API or create our own… and try to port it to as much platforms as we can.

Cause of that there have to be :

• simple
• small
• fully x-platform

What propositions, what ideas ?

Design notes on OpenGL bindings:
- Wrapper functions should have as few return paths as is reasonable as this creates unnecessary complexity and overhead

- Under the hood, we don't need to call each type of equivalent function. The Scripting bindings are abstactions to a certain degree of the low-level OpenGL API functions. If there are many function signatures offering the same functionality we should combine them where possible. The bindings are nicely abstracted this from within Lua but in the current trunk design are not necessarily so. For example, gl.Vertex maps to glVertex2f, glVertex3f, glVertex4f, glVertex2fv, glVertex3fv, and glVertex4fv. In the C wrapper function, we only need one set of these functions, with or without 'v', not both.

- LuaGL will probably be used in many contexts since Lua is an embedding language. We should not try to predict how people will want to report errors but instead provide a default function that handles the most typical use-case scenario. For most apps this will involve calling luaL_error but other apps might have very different needs. As an example, a computer game might have it's own custom console that it would like scripting errors reported to. The authors of the game should be able to recompile LuaGL (or perhaps set it from a script at runtime?) by switching one line of code to put in place a different error function.

- We should start auto-documenting LuaGL with doxygen style comments

- the function lua_isstring coerces non-string types if it can. In wrapped functions where an actual string is the only logical input as is the case with enums in LuaGL scripts, we should instead use the idiom lua_type(L, index) == LUA_TSTRING is this will match only strings instead of strings in addition to coerces types

- LuaGL has a lot of gratuitous (i.e. obvious) comments. It's a bit messy. Also, the comments are within multiline C stye comment tokens which prevents someone working with the source from using such comments to block out large chunks of code. If a comment is a one-liner, we should use one line comments '//' instead of '/* */'. I know the Lua authors prefer the multi-line style, but I find it hurts coding efficiency when modifying source files

- To help readability, in many places we should have brackets after if/for/while loops, especially in if/else if/else blocks with more than one branch. In addition to preventing coding errors, this will eliminate potential issues from macros that expand to multiple lines from breaking when not contained in a pair of brackets.

- I personally prefer tabs for indenting as opposed to spaces as it makes navigation with the arrow keys faster

- In many places, LuaGL uses (int)lua_tonumber when it should use the built-in Lua function lua_tointeger

- Use of malloc and free should be phased out as fast as possible, especially for small amounts of memory like vectors of floats. It's much faster for a function that could have 2, 3, or 4 values in a vector to just declare a vector of the maximum size statically and pass it's pointer in to the appropriate function instead of malloc'ing the exact amount.

- Sometimes the use of malloc and free are unavoidable when the vector is of unkown size as it is for images and buffers of points. In these cases we should try to come up with some kind of buffer object to avoid constant re-/deallocation and to speed up the transfer of data from Lua to C. Possible solutions are a buffer user data class or the use of a global memory pool within Lua

- The design goals and priorities of Lua should be the following
1) Provide robust bindings to as much of OpenGL as makes sense on a nearly 1 to 1 basis with low-level functions, including most of the OpenGL extensions. This way script authors and put low-level functions together to build higher-level abstractions for dealing with complex parts of the API like textures and framebuffer objects.
2) Once the low-level bindings are in place, development should focus on constructing high-level C++ classes for encapsulating parts of the OpenGL API that make sense grouped as objects to relieve some of the burden of script authors and increase performance by moving more of the processing to C/C++. Such high-level objects should be as platform agnostic and use-case agnostic as possible provuding robust and flexible functionality. Examples would be a Texture class, Shader class, FBO class
3) In parallel to 2), developement should also bring in related APIs for 3D graphics such as Cg if it makes sense in building abstractions like a Shader object. We should not, however, include projects for model or image loading for example as these are related sister proejcts but do not have to do directly with controlling the GPU like Cg does.
4) In addition to GLUT, it would be nice to provide native OpenGL windowing bindings as an option for users. In this way, LuaGL could provide x-platform windowing with a single interface

it's very important that eventual changes must be backward compatible!

Yes Fabio, indeed, LuaGL have to be a stable and backward compatible :).

The original solution that I have implemented is #2.

An alternative is #3, maybe we can use GLUT_VERSION definition or other definition.

A #4 solution is to not include glut at all. Leave it as responsability to who is using the lib.

#include <GLUT/glut.h>

will always work and is the prefered method of including this header. I think the inclusion of GLUT should be handled inside the OS detection macros.

wes

1. Follow by Opengl.org examples and use #include <GL/glut.h> .

2. Use #include <glut.h> (or even #include "glut.h") and then use more sophisticated "configure" script to set proper compiler parameters.

3. Fabio's solution with preprocessor constants like __glut_h .

*1 - Assuming that opengl.org is a kind of standard makes sens for me… examples: http://www.opengl.org/resources/code/samples/glut_examples/
http://www.opengl.org/resources/code/samples/glut_examples/examples/examples.html

*2 - I mean "-I" in gcc. In this way we can adjust to current configuration without any interference into sources. Additionally on specific configurations (when compilation FAILs :( … ) user can simply create file "glut.h" in project directory just by "echo '#include <XXX/glut.h>' > glut.h" to adjust project to his specific configuration (like "OpenGL/glut.h").

*3 - It can be a another option between two previous ones.

There is no standard place to put 'glut.h', specially
in windows. Many people put it in <GL/glut.h>, others
in <GLUT/glut.h> and others in <glut.h>. We could
use:

#ifndef glut_h
… glut inclusion here …
#endif

So if the user put 'glut.h' in another place he can
include by himself before including 'luaglut.h' with
no errors..

 #if defined (__APPLE__) || defined (OSX)  #include <GLUT/glut.h> #elif defined (__LINUX__) || defined (UNIX) || defined(WIN32)  #include <GL/glut.h> #endif 

but after some searching I found that it's platform independent thing were GLUT files are located.
So I thing we should think about another options…

Zakładajcie śmiało wątki, wyrażajcie opisnie, życzenia, pomysły…