To rbfx and not to rbfx

Because in cases where you do need script (when sending behaviour over network for instance) AS is a god-sent to those who have been coding C++ up until that point for the same reasons. I think we all agree automatic bindings would be divine for any scripting language and is guaranteed to accelerate engine development.

1 Like

Eugene: There are people who don’t want to use fork. What should they do?
adhoc99: They should use fork!

I think that this way of answering questions and solving problems is weird and quite… nonproductive.

1 Like

Definitely agreed. But that is not happening for AS. It isnt even happening for lua even though lua is easier of two. But we should not forget lack of ecosystem around AS. It is said already that you basically have your notepad and thats it. lua at least has a richer ecosystem around it, editor plugins that support debugging even… Of course nothing beats C# in editor support. Not trying to say that Urho needs C#, just pointing out that good tools make life a lot easier. That should be of some consideration at least.

1 Like

Not all that is said is true.

It is not impossible. The future is uncertain.

1 Like

Code::Blocks AS editing is a hack that sort of works. It is not a proper solution.

Automatic AS bindings are possible, but nobody will put in the work to make them happen. Go and prove me wrong :smiley:

This instant? You know that is impossible. But you proved yourself wrong about Urho being dead. Maybe the same will be true for AS auto-binding.

CodeLite any better?

VS2019 definitely the best

Code injecting proprietary IDEs are not a sane option.

1 Like

VS2019 community forever

I am not unreasonable. Start working on it. No matter how long it will take. It is a lot of boring work nobody wants to do though… Same stands for lua by the way. It is only marginally better than AS. We have some plans to bind lua using SWIG in the future.

From a perspective of someone who is more interested in using the engine instead of making one, dropping AS would be a big mistake. Thanks to AS it’s possible to create application, that can be easily modified by the end-user. I think that we all need to agree that when it comes to games modding support is very desired feature that helps to build a community around the title and can keep even old game alive for a long time. Also when it comes to other types of applications (not games), users usally prefer to have an ability to write some simple scripts that will automate their workflow. Now I know there’s still Lua, but rbfx dropped it also and the reasons behind this move are still valid, so there’s a big chance that Lua would simply be next in line to be removed (apparently with plans to bring in back in some undefined future). In the end this will mean that changes that are supposed to make a live of a developer easier, would also limit what this developer can offer to the end user or would require additional work to bring back functionality that’s already there.
Next thing - as someone already pointed out C# support is experimental, rbfx site also states that editor is still WIP, so it seems like proposed changes mean that some parts of the engine would be improved, but there will also be a regression in other parts. I have not used rbfx so I don’t know what’s the current state of the editor (and that’s rather important tool), but if it’s far behind the ‘vanilla version’, it will also require some additional ‘manpower’ to bring at least current functionality and since rbfx is a thing for some time now, but editor there is still WIP, my guess is that’s it’s not very high on priority list there.

Finally, I must ask what’s next? Would this be a one-time ‘code synchronization’ or from now on both versions would be kept in synch (what’s the point of having two versions then?). If it’s supposed to be one time thing, than I don’t need to be a prophet to see what will happen later: rbfx users will stay with rbfx, urho users with stay with urho or even will stick to version before changes (because of the compatibility breakadge), rbfx and urho will go their own ways, after some time once again there will be too many differences, to make a project compatible (or easy to port) with both versions and we will be back in the same discussion just about different features - so I would like to know what’s the plan there?


If the community is convinced, as long as EASTL itself alone does not break things too much, we may provide some scripts/way to help people migrate their own projects.

As for AngelScript, can we make things automatic? like SWIG for C#? So we just keep lua, AngelScript and scripts based Editor, as long as we don’t have a better alternative yet so discarding any of the parts are not considerable. If people love C#, use it.

So, everyone is happy and Urho is stronger. Am I asking too much (based on the community size and contributor number)?

1 Like

You are very wrong.
But I am not foolish enough to dox myself or my work.

I am very outspoken against it because it is crystal clear that this will become “Urbfxho3D”. If you guys are so proud of your amazing work on rbfx, I insist:

Oh, if you are using that logic then:

Eugene: So we will push the change anyway, because we know better and we know what is good for you.
adhoc99: Yes, yes, I welcome our future Urbfxho3D overlords.

What a brave new world this will be.

Your attitude is insulting to me.

First of all, you are ignoring the fact I mentioned before God knows how many times.
I will make it bold here:
It is impossible to merge rbfx into Urho

Second, do you maybe think that I will be happy to merge things from rbfx from Urho?
Merge is ****ing hard work! That I will be doing in my personal unpaid time.

And so I come here on forum with an offer of partial feature merge. The offer that community may accept or may decline based on reasoned discussion.

And obviously, every single contribution that I may or may not make, for every single feature or breaking change, will have to be discussed on the forum and reviewed as PR by the community on GitHub.

And here you are, accusing me of pushing rbfx over Urho as if I have just force-pushed Urho3D master branch.

Such attitude towards a person who is basically offering a gift is deeply insulting.

Oh yeah, we should be so greatful for your time, it is trully a blessing.

Behold the glorious “gift” one is not allowed to refuse.

It may be surprising for you, but you are not the community.
If you don’t want something, it doesn’t mean that everybody don’t want it too.

Behold the glorious “gift” one is not allowed to refuse

What exactly does it mean?..
Every contribution is damned pull request that has to be reviewed and approved before it goes into master branch. Can you point out how exactly pull request “cannot be refused”?

There are several major and multiple minor features, including native Editor (WIP), automatic C# bindings, built-in lightmapper that you all have probably seen, universal user-friendly serialization from/to binary/XML/JSON instead of this terrible (and sometimes broken) x6 copy-paste in vanilla Urho, profiler, type-safe logging and string formatting using fmt , subdirectory support by build system and so on and so on.


  • universal user-friendly serialization is optional, it’s just more convenient. Can we also make one in vanilla?
  • profiler can also introduced to Urho, as another outsourced feature of Urho, by using Tracy as rbfx
  • logging is just optional, the vanilla one works good, I don’t see many people complain about the current one.
  • string formatting using fmtis also optional, I don’t see many people complain about the current one.
  • C# controversial, skip it currently.
  • Without more from the list, I don’t know more about rbfx.

I checked the Editor. If I can understand deep enough, IMHO, it is still not very usable, not as featured as AS based one in Urho at least, though the latter has many issues and not pleasant to use to me. The rbfx author has been trying to make the workflow run, asset import/export… but not there yet. A lot of detailed stuff are not done yet, but I can understand to some extent the willing behind the code and the GUI. Maybe Editor is something people like Eugene really want from rbfx? But it’s far from done.

Lightmap Baker
I know the lightmapping implementation is nice and Eugene has done it beautifully, but it is based on the rbfx code, without the editor and eastl, lightmapping lost its foundation. Or maybe re-design it as a stand alone project, which allows baking by input of scene information?

I’m for the stl introduction if it really releases productivity, and happy to see more features into Urho, but I against breaking Urho for introduction of the editor from rbfx, or the Lightmap Baker, if I have a vote.

It can be ported quite easily. However, it may be more complicated to actually integrate it into existing classes. It always takes a lot of effort to break as little as possible.

This is called “quality of life update”. When you can crash application by typo in logging, it’s not very good logging library.

Lightmapper is unrelated to editor, except one optional menu item for model resources. But eastl is quite important for it.

Yes, definetely. WIP. It has basic usabiliy – I’ve made all test scenes for lightmapper with said Editor. But it’s lacking and currently under developement.

I believe so. Proper container library simplifies making changes in the engine and enables more optimizations. I don’t mean that it will make existing code faster (however this may happen too), but you can write faster code with better container library.

I’m glad the EASTL discussion has been broken out into a separate thread, because there’s more heat than light in the present discussion.

Pretty sure I know where the animosity is coming from though. De-blessing of scripting languages is an existential threat to communities. The track record from my previous experience in the Ogre3D ecology is clear. When a scripting language does not receive fully blessed support from its engine, it dies. The one person cobbling the binding together in their spare time, eventually loses interest and moves on to other things. Any work that was done on top of that scripting language, the kind of work that is immediately visible to actual users, rapidly dies with it. If you want a healthy ecology to exist around an engine, you have to decide what your scripting languages are.

Just because someone doesn’t like the risks of typeless or hand crafted languages, isn’t a reason to take them seriously. I don’t know of any engineering solution that doesn’t give you bugs. It’s all a matter of what provides a benefit in the real world and what doesn’t. What is supported, maintained, and improved and what isn’t.

I don’t have a handle on how much AngelScript ecology surrounds Urho3D, but if people rationally decide it’s substantial, then abandoning it is not to be taken lightly. Frankly in that case I’d call it a dealbreaker. And why should it matter to rbfx back porting efforts anyways? They don’t have any AngelScript stuff to backport. If rbfx devs want to become main Urho3D devs, well then they can just do it with the caveat that they won’t bother with AS, no way no how. That’s a political problem not a technical one.

I’m not in favor of C# bandwagons because I don’t like the language, and I don’t see what a 3D engine going ala C# is offering anybody over Unity. Maybe someone can explain to me why they really really want C#, and not Unity and its ecology. The vast majority of game devs who don’t put much effort into this stuff, are just going for Unity and being “happy” with the money they’re making / saving. Explain to me why they need rbfx instead.

Lua, on the other hand, is a proper scripting language, and fast for being one. It of course has tradeoffs. It also has a lot of proven use in the game industry. It’s not crazy talk to build a 3D engine ecology around Lua. I definitely see the case use for Lua instead of C#.

I can’t take the “do it only in C++” crowd seriously.

I’ve spent a lot of years trying to invent my own programming language, that would be a unified C++ and scripting language replacement. Nothing to report so far. I’ve got maybe 2 ideas, in all that time, that are actually good and should be implemented. I may yet make an attempt now. I’m currently contemplating the problem of making 3d art assets by hand typing into text files, as opposed to 3d editors. Maybe that will finally get me going.

Jonathan Blow has his Jai langauge in the hands of a few beta testers now. Maybe he’s finally going to release it onto the world?

I have followed many languages over the years, trying to overcome the “C++ and scripting language” barrier to development. Never did find a magic bullet. But it has caused me to study a lot of language ecologies. You can judge communities by what they actually get done with their languages.


If very difficult, just not do it or just stick to rbfx?

If people use some other game engines, there are also many things not perfect. e.g. UE4 is complicated as hell, quality of life will be harder if you don’t use Blueprint, cocos2d-x lacks of a lot of features by your standard. But I’m still think if we can have these in Urho style, and without breaking Urho.

Nice to hear Lightmapper is not strong related to rbfx

Until it is ready and good enough, let’s not abandon AS and keep Urho as a whole and not broken.