Comparison of scripting engines (Just for fun)

Found an interesting page on github:
https://github.com/r-lyeh/scriptorium

lua is faster than angelscript in this tests… (Fibonacci tests for now)
It will be interesting to see the results of more tests. Although I still like Angelscript.

Please no holywars))

UPD:
Forgot to say that it is in the repository a bunch of useful code.

Thanks for that good to see things like this.

Something involving also calls to C / C++ side bound objects would be more realistic for a game scripting scenario.

I’ve always seen it this way. Lua is the champion of being easier to use by scripters (tables for days) and just really damn fast in execution and small in size, while Angelscript has always been the champion of being easy to bind to C++ code and in being more familiar to C++/C#/Java users at the cost of size. It’s what made it my scripting language of choice in college since I was that crazy bitch who implemented a damn game engine as her senior project (admittedly it was pretty garbage, but it worked… sorta… :unamused:) and trust me, I looked into pretty much every scripting language there is… even scheme… don’t judge me. Each has their own merits and it’s always going to be slower to execute than C++ (unless the code is JIT compiled, in which case Lua has them beat… unless Andreas merged an x32/x86_64 JIT compiler implementation into the mainline. Not sure. Haven’t checked in on them in a while. I know there’s an ARM JIT implementation floating around somewhere for Angelscript.)

In the modern engines now they are using the script to C++ and compiled C++ for the packaged games, for example Unity is doing that and Unreal Engine 4 will be the next with that ready the Blueprints code convert to C++ and then is compiled and included in the game.

While Lua is faster and easier to learn, AngleScript offers safety and structure.
Considering that the purpose of scripting languages in games is rapid development and not performance, AS is the winner for me since it will be easier to avoid and deal with bugs.

1 Like

My thoughts on scripting these days:

I might have mentioned this before, but something akin to the blueprints system in UE4 and runtime-compiled C++ sounds interesting. Especially if you make some kind of node network-to-C++ conversion tool, with the ability to just drop-in hand-crafted C++ where needed and just make some reflection info to integrate in said node network tool. Events can be registered and tapped into for node networks and such. Have a build button which just does RC++ hot-reload management of game components, stuff like that. The end result can all be just static linked so it just works in emscripten/IOS where shared libs or jits are prohibitive, or bytecode would be too slow.

I didn’t know of micropython being used for an embeddable scripting engine but it makes sense. For me the python bind wouldn’t be for the run-time but for pipeliney stuff to integrate into a DCC package or talk to PyQt/PySide, asset management packs, etc. So there would just be an import Urho3D module to an existing python runtime. I’m such a fanboy of python, coming from a vfx background… :stuck_out_tongue:

I compared lua and angelscript samples with “-nolimit” option. On average, the angelscript has x1.5 - x2 FPS than LUA (without LuaJIT and with LuaJIT, no big differrence because no heavy mathematics in script I think).

Our current implementation of LuaScript subsystem is not as optimal as AngelScript subsystem due to tolua++ binding. The binding produces tons of warnings/errors from the static analyzer, does not do reference counting, and has a few pitfalls when converting values between Lua/C++ languages, just to name a few. I also observe that in some cases, although renders just fine, produces different overall outcome than its Angelscript counterpart. Take the PhysicsStressTest, for example, near the end of the program run you can clearly see something is wrong with LuaScript subsystem when under stress. The LuaScript subystem is a contributed code. Aster has contributed the code and left us to maintain it :slight_smile:. There is a stale branch to change the Lua binding from tolua++ but it has not seen the light of day. If you are using Lua or plan to use Lua in your game, probably you want to evaluate that stale branch. A new maintainer for the LuaScript subystem is needed.

PhysicsStressTest just use differrent methods for drop objects (AS use offsets for pos, LUA - time delay)

I’ve thought about taking up the job of redoing the Lua bindings. I’ve been evaluating some of the newer/more actively developed bindings libraries towards that end. The tolua++ based stuff has problems. Bad problems. Problems that have been around for years, and are only likely to get worse as the tolua++ code rots. I love Lua, and just can’t seem to make myself like AngelScript at all, so maybe I’ll try to make some time for this.

Many of the libraries I have been evaluating are C++11, or rely on boost for pre-C++11, which is part of what has held me back.

2 Likes

When we migrate to C++11, it will be possible to use nice Lua binding libraries…

C++11 Lua

facepalm

Huh? Most of nice Lua bindings use variadics and so on to do anything, am I wrong?

Well, I mean… C++11 hasn’t even been the most up to date standard for years. It’s pretty irrational to expect other third-party developers of libraries we want to use to stick to older standards, when the new goodies make some things so much easier. Unless we want to re-write every third party library custom, eventually most of them are going to outpace Urho3D. I’d say going to C++11 is a bare minimum. If I were to rewrite the Lua bindings now, I’d just have the config option force the C++11 flag, rather than include boost or some other heavyweight monstrosity simply to keep from requiring C++11. I’m aware that boost is already a dependency, I just wouldn’t like it to be because of me.

Edit: My personal choice, that I use for non-Urho projects, is sol2. But seeing as that’s at the least C++14, and people already have their knickers in a bind over C++11, I’d have to pick something else.

Well, there is no any C++ code needed to do good bindings for Lua.
If you do a lot of auto-bindings for classes you will end-up with ineffective code.
If you need effectiveness, you need to do some hard work. And C++11 things will not help you with that.

I do lua bindings for about 5 years now, can help if wished. But without manual labor there is no
much sense to do any changes.

It’s true. You don’t need any C++ code to bind to Lua. You could just stick to C. Maybe even go with assembly. No need for that silly C++ at all. I think that if the requirement for the Lua binding were to be to use no C++ binding generators, and just write everything from scratch in the Lua API, I’d have to reevaluate my willingness to redo the Lua bindings. Even with a generator, finding the time to do it will be tough. If you wanted to take on such a beast, though, rather than just obstruct, I’d be inclined to cheer you on.

Do you suggest to either use C++ generators like tolua++ or write those insane stack ops manually?
I think that “one line - one entity” bindings like AS is much better than these two.

1 Like

AS bindings are really insane in size of code path/ I think you would not want to do that. Lua is fit for manual binding,
it works best. Generated bindings are often too verbose and ineffective. So if you don’t want to go manual path,
you better leave things as is.

Anyawy, I don’t want toscare you - if you carefully prepare a set of macros and templates, this still be better than generated binding.