next »

[lansing]

Amusing read.

http://lua-users.org/lists/lua-l/2011-10/msg00825.html

[MattG]

it just doesnt make alot of sense to me. c++ is a great object oriented language easy to script fast and native.

[starsrift]

I enjoy that the message implies that there isn't right way to mix Lua and C++.

[eclectocrat]

I enjoy that the message implies that there isn't right way to mix Lua and C++.

I don't read that at all. It just seems like a frustrated developer who has seen a lot of crap. IMHO there are war stories like this for every language. Some dev projects are just total cluster*hugs*.

EDIT: I just posted a C++ -> Lua tutorial in the tutorial board. Mixing C++ and Lua works great for me 

[BorisTheBrave]

I enjoy that the message implies that there isn't right way to mix Lua and C++.

I implies to me you should write everything in Lua, and then lift to C++ only when profiling dictates you should, probably only your core graphics and physics library.

[Mikademus]

I enjoy that the message implies that there isn't right way to mix Lua and C++.

Could you tell me how you read that from the post? For me it is a normal tale about that morons will make messes where ever they go in the style of The Daily WTF. One example is about C programmers trying to tack on their home-brewed OO scheme on top of C, which is a horrible idea, and the other is about over-architecture and cargo cult programming. I nowhere saw anything directly against C++.

[starsrift]

I enjoy that the message implies that there isn't right way to mix Lua and C++.

Could you tell me how you read that from the post?

Given scenario where developer is trying to mix Lua & C++, poster posits two situations, both end in terribad. Poster does not posit a winning situation.

[Mikademus]

Ok, thanks. I re-read it and when read critically the first story could have a bias against C++ and the second story might be biased against OO in general == C++.

[eclectocrat]

Ok, thanks. I re-read it and when read critically the first story could have a bias against C++ and the second story might be biased against OO in general == C++.

It seems to me that it's just two stories about crappy code. The second story is about binding C with Lua, no C++ in that one.

[dlan]

Given scenario where developer is trying to mix Lua & C++, poster posits two situations, both end in terribad. Poster does not posit a winning situation.

well, the title of the thread is Design mistakes in mixed C/C++ and Lua projects (was : How can I be sure LuaJIT is working?). I read it more as a rant on how sometimes people using lua think it will magically fix all their problems when they don't understand how lua work in the first place.

[mcc]

I do feel like I went in hoping I could learn some useful things about what to do or not do when mixing LUA+C, and didn't learn anything like this.

Turn on LUA assertions? I guess I learned that, that sounds useful.

This was written by the author of LuaJIT?

[Vino]

Just like anything else, Lua is a tool that you use to solve a problem. If you don't have a problem that needs solving, you shouldn't use Lua. Solving problems that don't exist won't get your game done.

[mcc]

Vino: My problem is that game logic (especially logic controlling something small like an animation or a single entity) written in C++ has an unacceptably long iteration cycle to modify (like up to 2 minutes to recompile and return to the point I was at in the program) and is error-prone. Writing non-core parts of my game in LUA seems to address this problem? But I want to know if I'm walking into something that's going to create performance headaches later.

Really rereading this I guess the plotline of both stories is "group follows poor software development practices, then blames LUA when the same thing happens that would have happened with any language".

Similarly this article Google turned up: http://www.lua.org/gems/sample.pdf seems to be pushing the idea that the way to write efficient C+LUA code is "first just get the program working, then run the program in the profiler" which seems like basically the same advice as any language.

But... I guess what worries me is the claim in the lua-users post that calling across the C<->LUA boundary is expensive, which is something I hadn't heard before. Like the entire reason I am interested in LUA is it integrates with C and I want to command C libraries from a LUA script. Similarly my intuition is, write high-performance bits of the program in C and normal bits of the program in LUA but if calling C from LUA is expensive then maybe following this intuition will actually hurt my performance because the cost of the LUA->C calls will overwhelm the performance benefit of my tuned C code.

Is this just like a "don't call a C function from LUA 30,000 times in a loop" sort of thing or something I need to worry about when writing C+LUA software? Like, awhile back I did some work with C#'s "marshal" and later I really wished someone had told me "avoid passing large arrays of data across the CLR/DLL boundary" before I started off by architecting my program around the idea that large arrays of data were being passed between C#/CLR and C DLL...

[PsySal]

Vino: My problem is that game logic (especially logic controlling something small like an animation or a single entity) written in C++ has an unacceptably long iteration cycle to modify (like up to 2 minutes to recompile and return to the point I was at in the program) and is error-prone. Writing non-core parts of my game in LUA seems to address this problem? But I want to know if I'm walking into something that's going to create performance headaches later.

I use Lua with C++. Can't be bothered to read the original article but I get the basic idea. Of course it's possible to create a trainwreck with either Lua, or with C++. Here is my advice, speaking as a veteran:

- Use C++ for your core engine, Lua for game logic
- DO NOT try to create an exact 1:1 relationship between Lua classes and C++ classes-- what would be the point?
- What I do to reference objects, is that objects inside the core engine are simply named; so if the Lua code tries to reference an object that doesn't exist on the C++ side of things, just print an error that it couldn't find "frog_prince_23". This helps with debugging a lot, much better than leaky pointers and/or segfaults because something was removed from the game engine.
- So the api calls (from Lua to C++) just reference those names, and pass in other parameters
- You will probably have a big api with lots of calls! Price of doing business-- there is no way to glue two languages like this together for free. If you are thoughtful in specifically WHERE you need lua code to touch C++ code, it's not that bad.
- Don't try and automate the API creation with a tool-- do you really want to break your Lua code because you need to reorganize some structures on the C++ end? No. The api should make sense from the Lua side of things.
- Use *ONE* Lua state for your entire program; all lua code and objects need to be able to access all other code and lua objects directly.

I use some other more specific tricks, in particular when creating objects in the C++ engine I pass in a lua table (with possible sub-tables.) Then I have certain helper functions for dealing with those tables, pulling integers or vectors or whatnot out of them. So for instance I can do:

R = {
   type = "point",
   center_x = 10, center_y = 15, center_z = -5,
}
set_renderable (SpriteName, R)

The C++ code then has branches to create a type of renderable "point" (based on the type field) and then pulls the position x/y/z out with a little function luahelp_table_getv3d (L, "center")

My advice for writing lua code itself:

Lua's big weakness is also it's strength, which is that it's incredibly freely-typed. So you need to use a class system within lua, and keep your code organized and well-commented. Whereas in C++ you are going to rely on the compiler or code completion to tell you what methods are, or how data structures work, in Lua you are going to use introspection. So write a print_r (Object) that knows how to print out any kind of variables, including sub-values inside of tables.

Well, that's all for now. I love Lua! MOST of the coding I do now is in Lua, in terms of optimization you just need to be clever and put the stuff that matters into C++ but let Lua do basically all of the game logic. Keep your C++ engine like this boring bland thing that seems like it should do nothing except know how to add and remove things, draw them, compute some physics and motion, play sound effects. If your C++ engine knows whether or not you are at the title screen, it's doing too much. Do the rest in Lua!

[eclectocrat]

@mcc: I'm only working from the experience of a single project, so YMMV:

My main render loop is C++. It calls to draw and physics functions written in C++. Everything else is in Lua. My game loop spends about 2% of it's time in Lua calls, and there are probably 2000 calls into Lua per second, and up to 20000 calls from Lua to C per second when active (helluva lot less when idle).

Others write their Game Loops in Lua, ie the LOVE game engine. LOVE runs a little hot on my netbook, where everything is crossing the Lua-C boundary. If you want to have everything running in Lua then you might like to use the LuaJIT compiler with FFI. Maybe.

I think that some of the performance concerns are coming from people working with extremely limited hardware, embedded systems. I'm a lurker on that mailing list and read a lot about Lua performance. One guy had a game running extremely smoothly with the standard Lua interpreter and all game assets in under 1MB of RAM. He used the same design as in my game: let C/C++ run the game engine as a renderer, give Lua input to handle, and pop into Lua every once in a while to let it update game state, etc...

Maybe you can share what kind of design you're thinking of implementing?

[eclectocrat]

- What I do to reference objects, is that objects inside the core engine are simply named; so if the Lua code tries to reference an object that doesn't exist on the C++ side of things, just print an error that it couldn't find "frog_prince_23". This helps with debugging a lot, much better than leaky pointers and/or segfaults because something was removed from the game engine.

This works great for games with few entities. In my case my game has over 100,000 entities, and looking them up by string would be excruciatingly slow. In cases where you have more than a handful of entities, you can use userdata for super fast access, and allow Lua to manage object lifetime with it's garbage collector.

[Vino]

Vino: My problem is that game logic (especially logic controlling something small like an animation or a single entity) written in C++ has an unacceptably long iteration cycle to modify (like up to 2 minutes to recompile and return to the point I was at in the program) and is error-prone. Writing non-core parts of my game in LUA seems to address this problem? But I want to know if I'm walking into something that's going to create performance headaches later.

Yeah I know what problem you mean. If you use code as content you run into this problem where you have to recompile to test out changes, which takes forever. That's a problem to which a scripting system of some sort is definitely a good solution. So the question is, what scripting system? And how will it be integrated into the engine?

Generally when designing things like this I look at my requirements and my constraints. For example:

a) Needs to be reloadable by the game while the game is running (to test without rebooting the game)
b) Needs to be plain text so that it can be modified without tools
c) Needs to be editable by a non-technical users (say you have artists working on your game)
d) Needs to be able to represent any game data that might be required

Once you list these out you get a good idea of what you need. Let's look at some options:

* XML. It doesn't execute, it's just a data storage format. This may be an advantage or a disadvantage. It's kind of cumbersome to edit, it works better when machines are reading and writing it. It can be a bit slow to load.
* Lua. It does execute, (it is programming code) which makes it harder to edit by a non-technical user, but it will be more powerful since it can integrate tightly into your code. Is that power part of your requirements?
* Custom data format. I wouldn't discard this option entirely. You easily can make a rather format that can specify behavior for all entities in your game, given a robust enough inter-entity communication system.

There's other things too. In the end you need to choose whatever works best for your game. You want to choose the simplest system that satisfied all of your requirements. For Digitanks I used the third option, a very simple data format that was loaded into the game's entity IO system and that gave me all of the power I needed.

Lua strikes me more as something a company would use if they have a lot of scripting-savvy designers who need power and tight integration. I don't really see a strong argument for indie developers to use Lua. For all the time you spend integrating Lua, you're not spending that time on design and gameplay, the lifeblood of indie games.

[PsySal]

- What I do to reference objects, is that objects inside the core engine are simply named; so if the Lua code tries to reference an object that doesn't exist on the C++ side of things, just print an error that it couldn't find "frog_prince_23". This helps with debugging a lot, much better than leaky pointers and/or segfaults because something was removed from the game engine.

This works great for games with few entities. In my case my game has over 100,000 entities, and looking them up by string would be excruciatingly slow. In cases where you have more than a handful of entities, you can use userdata for super fast access, and allow Lua to manage object lifetime with it's garbage collector.

Mm-hm. I definitely don't have 100,000 entities, and I agree if you need that kind of granularity you probably don't want to use named referencing. I usually have about a thousand entities or so.

I will say one thing though, in situations that might otherwise create a lot of entities I normally have everything completely inside the C++, and then just send control messages via lua. For instance particle effects, I don't have each particle able to be referenced from Lua, but instead just the particle generator itself. Depending on what I'm doing I can either just set it up and let it run, or possibly send commands to it from time to time to change behaviour.

But I *can* think of other reasons than particular simulators that you would end up with so many entities! Just that for certain situations I structure it more purely inside the C++, which may be helpful for some people.

[Prinsessa]

Where is the love for AngelScript? It's sexy!

[Mikademus]

Perhaps in another thread, since this is about Lua? Please make it, since both AngelScript, Falcon and Chai are scripting languages that should be discussed more!