In this topic I want to discuss fork of Urho3D known as rbfx and possible feature merge from rbfx back into original Urho3D. This topic is not a proposal or announcement but the opening of discussion.
I really don’t believe rbfx and vanilla can be merged completely, but I’d like to bring them as close as possible.
In case you have no idea what I’m talking about, here is the link to rbfx:
Initially rbfx was quite close to original Urho3D (I will call it vanilla from now on) in terms of codebase and feature set.
However, the divergence grows as time goes on.
And this divergence becomes really annoying for users of both projects.
I cannot make wide-scope changes in rbfx because it will make things even worse than they are now. I cannot merge my changes into vanilla because it would require tedious rework of codebase. Users of both projects cannot simply switch back and forth because API is already incompatible to a certain degree: it’s nearly impossible to write code working both on vanilla and rbfx.
Oh, I hate forks soo much. And I don’t want to repeat the story of Atomic.
What does rbfx offer and why bother?
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.
I’m planning to do some major renderer changes too, but I won’t make any promises here.
What’s the problem with “just merging” everything back into vanilla Urho?
Short story: there are breaking changes. A lot. And a lot of dependencies between features too.
So it’s actually impossible to merge rbfx into vanilla “by bits”: it’s a package deal, and the package is huge.
The broadest (in terms or API affected) breaking change is using EASTL standard library instead of custom Urho containers. Yeah, Urho containers may have some nice features, but they are sorely lacking compared to EASTL or STL libraries. I personally switched to rbfx just because it’s so much easier to write code with standard containers. Maybe in the future it would even be possible to take the next step and switch to STL completely.
This change is mandatory to merge anything else from rbfx into vanilla Urho. It will also require certain rework in script bindings. Lua would probably be easy to fix because it has compile-time type checks. AS would be more painful. Speaking of which…
The biggest (in terms of functionality) breaking change in rbfx: AngelScript is gone. Forever.
You see, AS is assembly library. Just think about it. Urho is using raw assembly right now in 2020. Not just for optimization, but as scripting core. AS has zero compile-time type safety, so if you make a mistake or forget to update some manually written binding code, you will get real-time crash, or UB, or data corruption, or anything. Manual and fragile bindings to AS greatly decrease code maintainability.
Consequently, vanilla Urho Editor is gone. Yeah, writing Editor basing on AS scripting sample was a mistake. It’s sad because vanilla Editor is quite nice and has a lot of features. But it is really hard to extend due to poor architecture and using AS bindings instead of propper C++.
Theoretically, it’s possible to merge stuff from rbfx and keep AS and vanilla Editor. However, I’m not going to do anything for it – neither to fix conflicts on merge nor support manual bindings, ever. Feel free to volunteer for this task.
So, what do you think?
Is it worth a shot, or I want too much?
Is it better to try to bring rbfx and Urho closer or let them diverge forever, essentially becoming separate projects?
It’s not too late yet, but every major update in rbfx will make things more complicated than they are now.
Here are some polls.
About possible merge
- [against] I’m fine with current state of Urho (stagnation) and I don’t care about any changes;
- [against] I want changes in Urho but I don’t want to merge anything from rbfx;
- [tentative] I want to get breaking changes from rbfx as long as Urho doesn’t suffer any feature cut;
- [supportive] I want to get breaking changes from rbfx and I’m ready for a reasonable feature cut (e.g. removing AS);
- [supportive] I’m already using rbfx and I want to get code merged back into Urho;
- [skip] I don’t care
- [impossible] I want to get changes from rbfx as long as it doesn’t break any API
And about AngelScript specifically (assuming that you will get native Editor as replacement):
- I don’t care about AS;
- I’d like to have AS but I can deal with its removal;
- I need AS support and I’m ready to maintain it;
- I need AS support and I don’t want to do anything to maintain it;
Damn, I’ve spent hours writing this chunk of text. Please don’t ignore it. Thanks.
I’m summoning here all ppl I can think of.
@rku, @weitjong, @Modanung, @Miegamicis, @JTippetts, @JTippetts1 (I have no idea who is real you), @boberfly, @Dave82, @Lumak… And I hit the limit of mentions, sorry if you aren’t listed here. I’d summon @cadaver too, but I don’t think he have strong opinion on the subject.