CEGUI (Crazy Eddie's GUI) Forums

I've just started using CEGUI and it looks pretty good. Well done for the work so far.

One thing I've noticed is it looks like Lua is linked statically, along with tolua, into the scripting module. I think these two should really be DLLs. lua.dll and tolua.dll. This is so the host application can link to Lua if it needs a Lua DLL.

It would also be nice if tinyxml and freetype were DLLs for the same reason. If there is other code in the host that needs tinyxml or freetype these will need to be DLLs.

Cheers.

Another point is: if you are using Lua scripting for the GUI is likely that you are using Lua in your app. You will therefore probably (or should be) be using the same version of Lua. This is another reason why Lua should a DLL that both the app and the GUI module link to. Lua is creates a new state for each usage so the GUI and app can either be completely seperate, or that could be shared.

The Lua scripting module allows you pass in your own Lua state structure, and the linked code for Lua/tolua is pretty small, so linking against your own Lua lib doesn't cost that much in terms of binary size.

In CVS HEAD it's built as a DLL...

Hm, I have the same problem. I discovered tolua thanks to the scriptingmod. It's great, I can even use my own homebrewn string class inside Lua now!

But, I have one problem. I was using LuaPlus as well, it makes it a *lot* easier to go through tables and call Lua functions from C++. Unfortunatly, it refuses to work now. It does work again when I remove the .lib file from the list named lua_tolua++.lib. (or something similar). Right now I'm trying to find a GCC compiler to compile tolua++ standalone. Maybe it works better. After spending a day on this, I feel like it's fighting a losing battle.

And I have no idea why. Both LuaPlus and ToLua are compiled, yet they give problems. The lua function redefinitions are logical though. And I hope that I can get rid of those by compiling tolua separate (if I can get it compile at all).

Maybe someone else has an interesting suggestion how to get ToLua to work, while also using LuaPlus? Then it's really the best of both worlds .

lindquist: Does it have any advantages to use a DLL, could it save my problems maybe?

It's hard to explain what the problem exactly is. Sometimes I get strange source code errors as well, although it seems not to do that anymore - but LuaPlus is still doing 100% nothing. Or the otherway around. I just got all kind of assertions.. Real unfortunate, cause combined it would be awesome. Easy calling of Lua functions from C++, and all your classes (or certain ones) exposed for Lua.

Right now I got it kinda working.. I can call a function from C++ in Lua, using luaPlus.. but the Post() call which the LuaPlus makes gives a big error. Somehow because of a source file confusing I guess.. strange stuff

Enough rambling..

Hm, I think I got it to work now, I installed TortoiseCVs, downloaded the CVS tree, and tried to compile it. Now compiling it was a project on itself . CELua (or something) started to 'whine' about sprintf. Reading the forums, I found that vsprintf or _vsprintf might work. Unfortunately that didn't work, so I simply removed those. Assuming I don't make errors anyway .

Then, got the message "definition of dllimport function not allowed" on the "TOLUA_API int tolua_CEGUI_open (lua_State* tolua_S);" (or something similar) call in the CELua project. Took me a while to track it down, but I managed to override the export/import macro, and it seems to work now. Ditto for my own project, I had to redefine the macro before it to work. (If you need the exact solution, just ask)

Now it seems that Ican still load a texture using toLua, and call a lua function from C++ using LuaPlus, which calls another C++ function again. It seems to work now. I hope it stays like this. I really should keep a diary of what I do with all this compiling stuff .

afaik LuaPlus is not 100% compatible with "vanilla" lua 5.02 which is pretty much what is supplied with CEGUI, and what tolua++ works against.
Sounds very interesting if you made it work

Unfortunately it seems that, indeed, there's always a "but!" when combining these. Somehow they keep mixing each other's .h files and method calls. I'll stick with toLua now (although it seems it has a small bug with a 'number table' which I have to make (because of an int x[16]), and I can't find out how to do that, so I just comment the code out everytime I regenerate my LUA interface.


btw, Is it me, or is the CVS version,.. quite different than the downloadable version? StaticImage* won't work, and I got all kinds of missing things, that I'm going to resort to the original version (0.4?) right now first...

Yeah. CVS HEAD is undergoing major breaking changes for 0.5

Just a a side note, the problem of including the lua static lib twice isn't the size -- it is the fact that (supposedly) global state in the lua machine is altered independently by both DLLs (or EXE + DLL) linking against it.

Causing things to blow up during a garbage collection cycle...

See these discussions on the lua list for more details:

http://lua-users.org/lists/lua-l/2006-06/msg00289.html

http://lua-users.org/lists/lua-l/2010-05/msg00527.html

I'm currently working through this problem now; I'm trying to get both my executable and the CEGUI::LuaScriptModule DLL to use lua in DLL form.


-Nick