There are no special differences, it’s exactly not in the code writing, but for what conveniences, in terms of quick compilation, removal of the general code, the absence of “h” files, opening on the fly in andriod, ios, etc. Comfort from the additions of the language itself and various modern programming chips. Before 3-4 years ago, even there was no idea to use c #, but take a look at it now - these are completely different things.
“Just C ++ works faster” now the difference is miserable, with the advent of Core X, optimization went uphill
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.
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.
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)?
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.
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.