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.

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 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

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]: ?

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.

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

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

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

I'm a Lua newbie looking to quicly explore the full extent of Lua capabilities. In particular, I'm looking for the quickest and easiest way to prototype OpenGL output. I've been playing with POGL (Perl+OpenGL), but Perl is a mess. Lua looks better, but I've been unable to find a working Lua environment in which to run the test1.lua and test2.lua scripts.

Releasing binaries for a couple of platforms (Windows, x86 Linux) would be VERY useful to me. Keeping them in the SVN tree would be fine (no installer needed, yet).

Since I'm presently using wxLua under Windows, it would be best if a LuaGL wrapper script and DLL were released for Windows, so then I could then use LuaGL with any Windows Lua interpreter. See (http://wxlua.sourceforge.net/docs/wxlua.html#How_to_run_the_samples) for how wxLua does this for a generic Lua interpreter.

Thanks,

-BobC

cheers,
wes