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.

Without sunglasses, Ashley Greene has no dazzling image. But his plain prada handbags on sale appearance seems not very bad. Cute handbag and snug Jeans, brown hair gave us a very usual image. To some degree, we should appreciate the paparazzi as they have the real life of celebrities got to know to us. Otherwise, we always indulge into the imagination how luxurious their life is. If it were not their glasses, brand outfits, sneakers, and brand handbag, say hermes handbag, they all share the appearance of publics. prada bags on sale The signature style which Prada pioneered is simple, understated and decent yet chic, elegant and cutting edgy. Prada handbag hints at the Italian vogue that is "sexy and spoke of confidence without revealing too much skin.” With their sturdy simple designs, Prada gets the job done that makes bags focusing on edgy fashion, rather than adding too many additions to distract from its core fashion spirit.

Immense compliment has been placed on Prada, the Italian high-fashion company. Even the name Prada alone signifies style, luxury, elegance and extremely glamorous leather goods. Most famous for its unsurpassed quality, exquisite handicraft, uniquely chic design, and great versatility, Prada handbag stands out as a prada handbags classic and timeless fashion icon that outshines other contemporary brands. More importantly, Prada possesses an inborn sense of creativity and innovation which has produced numerous distinctive, stylish and eye-catching handbags. This exclusive characteristic keeps Prada always remaining at the forefront of the fashion industry and obtains countless praises as master works of the cutting edge of fashion prada handbag discount Then again, you have those people who are out looking for a fake Prada handbag and do not care if it is the real deal. Some women have no problem with paying a couple prada handbags on sale hundred dollars for a knockoff that would cost them about a thousand to purchase if they wanted a real one. But when fake handbags are purchased, there are many people who get hurt and companies who have worked hard on their name gain nothing from someone purchasing a purse that copies their design.

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 ?