Other Language Wrappers/Bindings

I just came across this in my google voyages:


Never been a fan of C++, so I was searching to see if someone had written an Urho wrapper in one of the more recent system languages (preferably D). Sure enough, someone wrote a Nim wrapper for Urho.

Here is the Git link.

I’m not familiar with Nim, and frankly I don’t know if it has much of a future. But I’m almost tempted to use that as a template for creating D wrapper. I love the idea of writing a game using Urho and D.

Curious if anyone knows about any other projects along similar lines?

Completely missed this thread, but just two notes:

[li]Nim is awesome. Do take a look at it, its evolving quite nicely.[/li]
[li]Urhonimo is 95% automatically generated by c2nim, a tool written by Andreas Rumpf (main author of Nim).[/li][/ul]
And… Andreas (Araq) will push the update of Urhonimo to 1.4 soon, we have just been busy busy with working on our client that still uses 1.32.

I talked with one man on habrahabr.ru and it appears that will soon be wrapper for C# :slight_smile:

I talked with one man on habrahabr.ru and it appears that will soon be wrapper for C# :slight_smile:
Wow, good news) I’m also think about this, instead AS use C# for scripting )

Urhonimo is a cool project but the language looks more like it can be used for scripting…


[code]import ui, urhomain, processutils, color, urstr, stringHash, variant, text,

include urholink

enable auto-deref for this module:


proc onKeyDown(userData: pointer; eventType: StringHash;
eventData: var VariantMap) {.cdecl.} =

proc main =


subscribeToEvent(“KeyDown”, onKeyDown)

let text = cnew constructText(getContext())
text.setText(“Hello Cruel World!”)
text.setFont(getFont(“Fonts/BlueHighway.ttf”), 42)

let exitCode = runMainLoop()
quit exitCode


also looks like python code.

Hello authors of Urho3d, do you plan to support Python as sqript language ?
With project kivy python can compile for Android and iOs, and also works on windows, linux and MacOs.
Python have nice syntax and a lot of scientific library, python and Urho3d can be a powerfull visualisation scientific tool )

Sorry, we have no plan to add Python script.

ok thank you for the answer )

To elaborate a bit, there’s nothing that prevents you from integrating Python in your own application that uses Urho3D. I’m sure the library can be useful outside games, but the built-in script bindings reflect a game development focus, where small footprint of the script runtime is essential.

How about integrating support for javascript? like Duktape is a nice candidate. It meets the requirement of small footprint and Javascript is quite popular. I am sure that will add attraction to Urho3D if it officially supports Javascript.

Any thoughts on the Javascript official support?

At least one thing is certain, we shouldn’t add a third manually generated binding. Rather the existing bindings should be converted to autogenerating, and after that it’d be easier to add more languages. However we’re talking about a substantial effort. If someone wants to work on that front they’re welcome.

My personal opinion is that one or few good script bindings is better than multiple poor or flaky ones. So far the Lua binding suffers from memory management mismatches and some potential devious performance drop due to the wrapper library (tolua++) being poor. I’m also not a fan of garbage collection, either, because it forces you to think about it the whole time, and possibly apply ugly workarounds, if you care about performance.

As a full stack web developer guy that is accustomed and used to working with a lot of Javascript code, this was my first thinking of why not have Javascript instead of Angelscript. Eventually by doing some prototypes, I got used to Angelscript code examples and other user guides, now I don’t see any big difference (syntax) and have never looked back. :slight_smile:

There’s no question about Javascript’s popularity and it may attract other game developers to check out the engine (Duktape is a good choice) but as Lasse said and the “age old” question is, who will do the port to Urho3D? :wink:

Duktape indeed looks like a library integrator’s best friend, no JIT or other machine-specific things. However the downside is that the performance is left lacking compared to the big engines. I don’t have personal experience so don’t know how bad the perf is compared to e.g. AngelScript or Lua. That said, I’d still rather integrate Duktape than trying to cram V8 or SpiderMonkey in; any JIT-ing is out of the question for iOS at least.

Atomic Game Engine is using Duktape. If we can talk them into porting that back to Urho3D then we can have the official support for Javascript.

I just have a crash course on the Lua C API a few weeks ago and I have had a quick glance on the Duktape API just now. They look awfully similar to me, although most probably I just talking non-sense. It is definitely doable. In fact I would say we can reuse most of the classes in the LuaScript subsystem (or at least its basic design) to make this new JavaScript subsystem. However, like Lasse said, I think it is the Urho3D API binding in JavaScript that we should worry about. Until we have a better tool to auto-generate those bindings, I suppose we should just keep this in view. The potential win is too huge to be ignored, IMHO.

I like Duktape, especially that the C api is modeled on Lua’s api.

We do use it and are planning to MIT Atomic’s runtime. This is where the bulk of the Urho code in Atomic resides and will include our modifications and additions. This also includes the JavaScript subsystem, however this is a different take on scripting the engine than the AngelScript/Lua systems which we have removed. So, it would probably make more sense to use it for some ideas on a JavaScript scripting subsystem which works with the AngelScript/Lua ones in Urho3D.

That is great news to hear that you are planning to MIT atomic’s runtime. When do you think that will happen?

About the tool to auto-generate the bindings, I have long wanted to have a closer look on libclang. And you know what, it has been available to us all this while since we have made the build environment for the Emscripten port. We actually now build the fastcomp clang frontend tool for our CI build server and store the build artifacts in this github.com/urho3d/emscripten-sdk repository. Currently we just store the “bin” directory which contains the “clang” and “clang++”, among others. And we through away “lib” directory currently. That “lib” directory actually would have contain “libclang.so” in it! So, I think it should be in theory possible to use this shared library to produce the AST for each of our class and traverse the AST nodes to generate the bindings. My two cents.

even greater news! :smiley: