RE: To rbfx and not to rbfx

Hello,

sorry if I reopen a contentious topic.
I believe some possibilities weren’t brought up in the last discussion.

rbfx adds neat features/changes to Urho : the lightmapper, automatic bindings via swig (C# for now, but lua should be relatively easy to add), built-in serialization, better containers, …

But some people want to :

  • avoid the C# ecosystem (because Microsoft)
  • keep angelscript (which is removed in rbfx, and would need work to add to swig definitions)
  • keep the original editor (built on angelscript)
  • avoid the eastl containers (because EA)

Here’s my take on it :

  • so long as the engine itself doesn’t depend on C#, the binding does no harm.
    I don’t like Microsoft either, but the language is good for scripting purposes and is becoming the industry standard. If Microsoft fuckery happens, we just keep the last clean open-source version of the .Net environment until the userbase has migrated their projects, then ditch the binding

  • while angelscript can’t have auto bindings, we could keep the original angelscript manual bindings (@rku : can you confirm that the manual bindings could be brought back ?). Also, let’s drop the burden of maintaining them to whoever uses them instead of those that add features.

  • thus, the original editor can be kept with angelscript for the sake of retro-compatibility, but having the editor dependent on one of the scripting languages was a really bad idea. The new editor already in rbfx, while not full-featured, is in c++ like the rest of the engine as it should, on top of being easier on the eyes. Let’s just build it up to what the old one was capable of.

  • the eastl containers are different from the C# bindings in that they are an integral part of the engine. BUT a container library is very different from a language. Even if it goes closed-source or stops being maintained, we would just keep the last clean open-source version and maintain it ourselves, which is already the case with the actual containers anyway.

Hope that makes sense, looking forward to your responses,
and thanks for coming to my TED talk :stuck_out_tongue:

2 Likes

https://github.com/AtomicGameEngine/AtomicGameEngine

JavaScript, C#, own editor, 2d lighting and other cool features

We should not. SWIG support for lua is quite bad. No polymorphism support for example. However i am eyeing sol2 for that. Bindings using sol2 could be generated from clang ast. clang10+ can dump ast as json and i am working on a python script that would pregenerate lots of SWIG crap. There is another similar script i made, but it uses pyclang and is terrible in just about any way you could imagine so it must be set afire :fire:.

There is no technical obstacle, lack of AS in rbfx is purely political. I am not going to put any work behind something i think is a bad investment.


It is clear that there are multiple groups of people who want different things. People who would like to maintain status quo may keep using upstream Urho3D. People who want to experiment may use rbfx. This is totally fine.

Oh hell here we go again. God I hate such threads so badly.

Last time I had a poll it was clear that significant portion of Urho users enjoy its stability and lack of breaking changes and feature removal. It’s their choice and I am fine with it.

Whereas the main purpose of the rbfx fork (and almost any other fork in general) is to be different from original, to change things in breaking manner. To lose something and to gain something else.

I don’t see how you can realistically reconcile these two very different approaches to development. It’s hard to make breaking changes in fork. It would be three times as hard to make similar non-breaking changes in master.

2 Likes

Does this mean that there is only one person making decisions in your organization?

No. But this particular decision was made when there was just one person total. Be that as it may, it does not change a fact that AngelScript is a bad investment.

I’ve always considered AS to be one of the best scripting languages out there. Can you substantiate your point of view?

Those may also want to consider giving Dry a try, which also comes with a (∞WIP) editor cluster.

I admit that AS has good aspects, efficient C++AS interop in first place.
What I don’t like in AS:

  1. No automatic binding library. Your autobinder may or may not fill this niche later, but at the moment of AS removal from rbfx there were none, and your binder is still not generic enough.
  2. AS is assembly library and it cannot work without platform-specific assembly code implemented by AS maintainers. I don’t think it caused actual issues with Urho, but I don’t like this kind of dependency. I just don’t want to rely on portability of assembler library in year 2020.
  3. Derived from 1) and 2), C++AS bindings are very type-unsafe. One mistake may lead to crash or security risk.
  • AS is very C++-like. If i wanted something like C++, i would use C++.
    • Since it is a scripting language i do not understand why it adds a cognitive load of C++ concepts.
  • AS has no ecosystem around it.
    • No editors
    • No debugging
    • No libraries

You split a community. :eyes:

C# is very C+±like. If i wanted something like C++, i would use C++.

1 Like

C# uses assembler for interopt

C# is syntax is C++-like, but we do not need to think about pointers when writing a C# script. It also has insanely rich ecosystem around it (libraries and tools). And no, it does not use assembly for interop.

But C# not scripting language. And use assbler for interopt.

Sure, C# interop is quite dirty. That’s why I don’t want to use C# as script language as well. It has even bigger platform compatibility issues than AS.
However, I have a bit more trust in long term support of C# than support of AS.

If I had a choice, I would have used Lua or some similar lightweight 100% integrated and platform independent language for scripting

https://killedbymicrosoft.info/

Strange why there is no UrhoSharp and mfc in this list xD

And? Claiming that we can not rely on Microsoft to not kill C# is like saying we can not rely on Microsoft to not kill Windows. These are their flagship products, they are not going anywhere ever. Besides C# is so widely used in enterprise sector and is opensource and MIT, that it is essentially unkillable now.

Still i agree lighter alternative would also be good. They serve different usecases and having both would be good.

Great template “X are their flagship products, they are not going anywhere ever”.

UrhoSharp are their flagship products, they are not going anywhere ever.
XNA are their flagship products, they are not going anywhere ever.
MFC are their flagship products, they are not going anywhere ever.
Kinect are their flagship products, they are not going anywhere ever.
SilverLight are their flagship products, they are not going anywhere ever.

Microsoft to not kill Windows

Microsoft installs Linux on its servers and adds support for running Linux applications on Windows.

Neither of those were ever flagship products.

So Microsoft goes where money is. Big surprise. Enterprise windows licensing is big money too.