I just came across this in my google voyages:

forum.nim-lang.org/t/870

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.
github.com/3dicc/Urhonimo

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:

[ul]
[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#

I talked with one man on habrahabr.ru and it appears that will soon be wrapper for C#
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…

Hello.nim

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

include urholink

enable auto-deref for this module:

{.experimental.}

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

proc main =
parseArguments()

openUrho3D(false)

subscribeToEvent(“KeyDown”, onKeyDown)

let text = cnew constructText(getContext())
text.setText(“Hello Cruel World!”)
text.setColor(color.WHITE)
text.setFont(getFont(“Fonts/BlueHighway.ttf”), 42)
text.setHorizontalAlignment(HA_CENTER)
text.setVerticalAlignment(VA_CENTER)

getSubsystemUI().getRoot().addChild(text)
let exitCode = runMainLoop()
quit exitCode

main()[/code]

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.

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?

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.

• Josh
  http://www.atomicgameengine.com

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!

That sounds exciting. How long will it take to have something to try out?

Yushli, I understand you are excited of possible new developments but I would suggest to drop the kind of “when will x happen” questions. Things will happen when (if) they happen, this is a project where people work on their free time, so the answer could be anything.

Got it. Thanks anyway. And will wait for that happen.

I am sorry if I have made anyone too excited. I am merely saying that we already have Clang toolchain readily available in our CI build server. I am not saying I am the right person to do it. However, If I can then I am willing to layout the build infra for others to work together towards the ultimate goal. There is light at the end of the tunnel, but we haven’t even begun the process of entering the tunnel.

Instead of using libclang, I have decided to use libtooling because it provides full AST access. The build environment on our CI server should have everything it needs to build the tool(s) now. At the moment the Clang-Tools project directory only has one tool, but more to come. More contributors are welcome.

Nice to see this being worked on!

I was making some cython bindings by hand (yuck) the other day to get my head around it, but it looks like I’d need to dedicate like 1-2 weeks for that, and then maintaining it each time the codebase changes feels horrible to me.

Are there any good resources to research how you would use these libtooling/libclang libraries to produce bindings? I’m really itching to get python support for Urho3D so that I can make some neat pipeline tools for Maya/standalone and making cython files from this AST data sounds way more fun than by hand.

Cheers!

The documentation resources for LibClang/LibTooling are hard to come by. I only found a few hits from my Google search and those were rather dated materials considering how fast Clang development is. For those would like to try or help our Clang-Tools work, I strongly suggest you use a good IDE. One that would index all the Clang header files readily so that IDE could, at your finger tips, assist to bring up the code completion or brief documentation on the highlighted class/method (without going back and forth to Doxygen-generated Clang reference pages).

Note that Nim is a very powerful language that compiles to efficient C++. It may look a bit like Python because it uses similar indentation based block style, but its NOWHERE CLOSE to Python as a language. I would describe it as more powerful than C++ but still much more usable and with more interesting features like an effects system, AST based macro system and much more.

In that sense Nim is different than the other bindings - its more a substitute for C++. And it works superbly

An article on clang introspection.

reddit.com/r/gamedev/commen … tion_data/

Attributes won’t work in our case. I have also have had entirely too much AOP programming since my enterprise years. I still can’t get the stink off me. Hopefully this can help people get a foot hold.

Note that Nim is a very powerful language that compiles to efficient C++. It may look a bit like Python because it uses similar indentation based block style, but its NOWHERE CLOSE to Python as a language. I would describe it as more powerful than C++ but still much more usable and with more interesting features like an effects system, AST based macro system and much more.

In that sense Nim is different than the other bindings - its more a substitute for C++. And it works superbly [/quote]

Ah ok, I see. sounds great gokr, thanks for the added info.

Yeah I was writing some disgusting code full of string manipulation to generate cython pxd files as I usually get headaches trying to work out regex, but I need to also generate pyx files now so…

The havok guys wrote this one:
https://github.com/sk-havok/clang-extract

Rethinking things right now, I’m about to test this:
https://pypi.python.org/pypi/CppHeaderParser/

See what happens… I really like python Curious to see if using cython for gameplay code is workable and fast enough, I’m guessing yes. It does support wrapping templates and I was making wrappers to Urho3D containers by hand, by looking at cython’s built-in STL wrappers. Unfortunately all the auto-wrappers for cython like cwrap and xdress are dependent on STL containers so it would be an effort to patch those guys.

Automatic bindings, in the context of “adding a bunch of languages” is kind of chasing El dorado. It is fun on the frontend, but then you hit the swamp The devil is the additional per language glue, adding examples, keeping it all running.

Our approach, does lightly use some AST, but there is a ton of glue code and stuff for handling things like variants, events, etc. There is also all the thought and work that goes into making things feel somewhat natural in a given language, generating and maintaining examples in it, etc.

Instead of adding JavaScript as an “option”, we removed AngelScript and Lua. This allowed us to do some stuff that wouldn’t be a fit for the Urho project, though did move us along. We have a schedule to keep

Doubling down on AngleScript and Lua support seems like a good idea. Possibly, using AST to help with maintaining those languages. Though, that seems a bit “heavy”

I am having a hard time envisioning Urho master having a slug of languages, glue code, generators, etc in it… or how this works with the current AngelScript and Lua support? How do contributors and downstream forks factor it in to generate bindings? What are the submission requirements of new features and examples, all languages, some languages?

In any event, a good conversation in this thread

• Josh

Perhaps a C-API shim is in order and then the community just makes/maintains their own wrappers, and not have it stored in Urho3D mainline. Objects just become handles and memory-managed in the shim itself.

It’s how Horde3D got an explosion of wrappers as wrapping plain C99 is very trivial for most languages. You’ll lose flexibility and control you’d get with more closer bindings though.

At the moment CppHeaderParser is fun at least to deal with, it’s a tokenizer and makes an easy python dictionary or json file for me to look into and generate specific cython pxd/pyx files. And I can just fine-tune the more difficult stuff which are the template heavy stuff like the containers, they usually don’t change too often in the codebase at least. I’m curious to see what weitjong is doing with clang-tools in the master branch, though…

I think we have explained why we need an automated binding generator tools in the previous posts. From the beginning we know they are not easy to be developed, but they are necessary to be developed if we would like to support more scripting subsystems in the future. No one made any promise we will get there, but at the very least in the end of the day I could say we have tried regardless of the outcome later.

Use the right tool for the right job. Personnally I like to learn more about them and to master them to fit my own needs. If all you have is a hammer, everything looks like a nail. I use sed or awk for simple global replacement. I use regex for those that need complex pattern matching. And I believe I have found the right tool, Clang, for parsing and/or tokenizing C++ source code. Just imagine how complex a regex expression for matching a partial template specialization declaration would be, if it even possible at all. In the constrast, all the C++ declarations (and statements and more) can be matched declaratively using Clang’s AST Matcher. Furthermore, LibTooling, once mastered, is a tool to make even more useful, targeted, and specialized tools possible. Thus, at the end of my experimentation I will keep the newly acquired tools in my toolbox regardless of the outcome later.

I have personally witnessed clb (author of kNet) writing Doxygen XML-based bindings generators with C# (C++ to QtScript, C++ to AngelScript). These ended up fairly sane and didn’t take an awful lot of work, though they were mostly used to expose value types like math objects, so I’d generally be more on the optimistic side.

The hardest part I imagine is to replicate some of the “human” logic that has gone into the bindings, like knowing that when a C++ function expects a “destination” vector passed as reference, in AS it should return an array object instead. Or how the AS bindings like to expose getters/setters as properties instead. Or some of the refcount / ownership semantics.

The contribution rules as they work currently ( urho3d.github.io/documentation/1 … klist.html ) are such that new features and examples should update all the languages (C++, AS, Lua), which can be a burden. If I had a Men In Black neuralizer gun and could rewrite past, I might zap the codebase free of any script bindings and make them fully the users’ responsibility. But I don’t have one.

When I chose the engine, I really liked that it is possible to write games on a simple scripting language AngelScript. Now I use only C ++, but maybe I would not have stopped at Urho3D if it had no examples on AngelScript

[quote]
When I chose the engine, I really liked that it is possible to write games on a simple scripting language AngelScript. Now I use only C ++, but maybe I would not have stopped at Urho3D if it had no examples on AngelScript [/quote]

Same here as I have mentioned on my previous posts. The scripting part got me interested, it is not exactly Javascript but hey it is not that far.

For me, LUA and Angelscript are perfect as it is. Any additional bindings probably would be a 3rd party fork project or possibly a plugin for Urho3D, like Mogre and PyOgre is to Ogre.

I’m in the process of adding C# support over here and having to juggle managed and native sources, which is another complexity. Lua, AS, etc embed into a host executable “cleanly” in that you only need C/C++ to embed them and there are no external assemblies or scripts necessary.

The hardest thing is making the scripting feeling natural to whatever language environment, integrating with debuggers, etc and addressing all the gotchas that don’t really map.

On the flip side, @cadaver did an amazing job decoupling the script subsystem if you’d rather roll with something else, cheers on that!

• Josh

C# bindings from Xamarin: github.com/xamarin/urho

It looks like they updated the license from the initial fiasco.

It looks like they updated the license from the initial fiasco.[/quote]

License: MIT gamefromscratch.com/post/201 … o-MIT.aspx