Unique visits:
View My Stats
George Petsagourakis 1233400339|%e %b %Y, %H:%M %Z|agohover
Good to see somebody hasn't given up on this.
Now all I am waiting for is a new version getting support for OpenGL 3.0 :)
alvaro martínez (guest) 1233373509|%e %b %Y, %H:%M %Z|agohover
after some googleing and errors i managed to build with my following makefile (only for osx, luarocks doesnt build LuaGL because it doesnt give the -frameworks parameters to gcc)
But i still get some memory runtime errors
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?
alvaro martínez (guest) 1232788113|%e %b %Y, %H:%M %Z|agohover
could you post the makefile?
i am also a os x user, but this doesn't compile via luarocks
George Petsagourakis 1228683270|%e %b %Y, %H:%M %Z|agohover
Questions: which source branch? compiler/platform?
In the case that you are on Windows XP, can you sent me the binaries you produced?
Anonymous (82.83.73.x) 1226855982|%e %b %Y, %H:%M %Z|agohover
First thanks for providing this binding for openGL ;)
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
George Petsagourakis 1226516794|%e %b %Y, %H:%M %Z|agohover
Trying to compile on CodeBlocks and mingw I get too many errors.
At the moment I am having a lot undefined references from LuaGlu.c on the Lua API functions.
Anonymous (85.72.151.x) 1226089607|%e %b %Y, %H:%M %Z|agohover
Why isn't LuaGL using another extension manager like Glew or GLEE that seem a lot more efficient?
Also GLUT should be overtaken. GLFW is the project that is more up to date as far as OpenGL Utilities are concerned
Anonymous (96.246.68.x) 1223782433|%e %b %Y, %H:%M %Z|agohover
Hi, it's funny because it's been so long since I've used this. I never did see your reply :)
Thanks for the info. I did end up getting it to work.
Cheers
Anonymous (92.65.156.x) 1222773307|%e %b %Y, %H:%M %Z|agohover
Hi,
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
fabiowguerra 1200284224|%e %b %Y, %H:%M %Z|agohover
Hi Scott,
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 = -lglutall: luagl luaglu luaglut
luagl: LibLuaGL
luaglu: LibLuaGlu
luaglut: LibLuaGlutclean:
rm *.o *.soLuaGLAux.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.oLibLuaGlu: LuaGlu.o LuaGLAux.o
$(LD) $(LFLAGS) -shared -o LuaGlu.so LuaGlu.o LuaGLAux.oLibLuaGlut: LuaGlut.o
$(LD) $(LFLAGS) $(LGLUT) -shared -o LuaGlut.so LuaGlut.o
Hope this helped you.
Fabio
Anonymous (150.101.122.x) 1200192119|%e %b %Y, %H:%M %Z|agohover
Any news on this? If there's no Makefile can anybody give me a bit of a hint for compiling with gcc on OS X?
Cheers,
Scott
fabiowguerra 1200024621|%e %b %Y, %H:%M %Z|agohover
It is not a dead project, since there are big changes on the svn. But it really needs a better documentation and makefile to be more usefull to a lot of people.
Fabio
Anonymous (85.228.127.x) 1199977273|%e %b %Y, %H:%M %Z|agohover
I have no idea where to start, since there are no tutorials or anything. :( Or maybe this is a dead project?
fabiowguerra 1199314473|%e %b %Y, %H:%M %Z|agohover
Hello,
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
fabiowguerra 1199313327|%e %b %Y, %H:%M %Z|agohover
Hi 'Anonymous',
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
Anonymous (84.251.96.x) 1199288134|%e %b %Y, %H:%M %Z|agohover
I compile LuaGL 1.01 with tcc using the command line:
tcc -shared -rdynamic -lopengl32 -lopenglu32 -lopenglut32 -llua -o luagl.dll luagl.c luaglut.c
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]: ?
fabiowguerra 1198982929|%e %b %Y, %H:%M %Z|agohover
Hi 'Anonyous',
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
fabiowguerra, 1198982929|%e %b %Y, %H:%M %Z|agohover
Anonymous (203.173.241.x) 1198380367|%e %b %Y, %H:%M %Z|agohover
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:
int window;
window = glutCreateWindow((const char *)lua_tostring(L, 1));
static int glut_destroy_window(lua_State *L) { glutDestroyWindow(window); return 0; }
{"DestroyWindow", glut_destroy_window}
That is it.
Anonymous (203.173.241.x), 1198380367|%e %b %Y, %H:%M %Z|agohover
wes 1190870093|%e %b %Y, %H:%M %Z|agohover
Yes, that while loop is really inefficienct and this thread is a discussion to make that conversion better. As for your second question, to put a function in lua, it has to have a particular signature ( int func(lua_State *) ) so what you describe is not possible unless it's a userdata which would require another kind of overhead so it doesn't really matter in the end and they way functions like glEnd are wrapped is the most ideal solution for Lua.
Anonymous (24.245.6.x) 1190850190|%e %b %Y, %H:%M %Z|agohover
Ah I see. I was asking because I saw that string flag array in the source and I couldn't help but think that looping through an array like that isn't the most efficient method to check for flags.
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
