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

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 .

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.

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.

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

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.

C# and Windows

Windows Phone are their flagship products, they are not going anywhere ever…

But where is Nokia xD

Jokes aside, I would like to compare “killed by Microsoft” to “not killed by Miscrosoft” and “died of old age unrelated to Microsoft” and to “killed by anything else”.

What is the fraction of discontinuted software in total, comparing to all supported software in the world?
What is the fraction of discontinuted software to supported software among everything owned by Microsoft?

If you have such a question, you may have already found this list. So how many Microsoft products do you use besides Windows and VS?

It’s more of a salvaging operation, really.

I should have waited until after work to start this. you guys are quick

Atomic died because the main developer moved on with no contributor willing to take his place.
Urho3d survives despite the same happening because of the people and the features. Both go together. No features no devs, no devs no features. Splitting the project harms both

your concern over the future of C# is noted

Then I don’t see why it can’t be brought back for those that use it.

All I’ve seen in this thread thus far is two camps arguing over each other’s choice of programming language. Who cares ?

vanilla and rbfx can use the same game engine and different scripting languages. Don’t spit on each other’s contributions to the engine itself

the bigger question was can the merge be done without harming one too much.
The C# part is moot, don’t use if you don’t want to.
The angelscript part is too, surprisingly. just bring it back and let whoever uses it maintain it.
And it seems like the eastl bit isn’t that problematic since no one brought it up.

your concern over the future of C# is noted

I have nothing against C #. It’s just that it will attract users who do not write C ++ code and will not do PRs to the engine.

Oh, it’s very problematic. No one brought it up because there is nothing to argue about.

Significant part of current Urho users prefer custom Urho containers and want to use them.
Most (all?) of rbfx users prefer standard (EASTL) containers and want to use them.
I don’t see how it can be “merged”. One can’t do both.

No it can not, because nobody in upstream wants it. And that is fine. To be honest i dont think i want it either.

So no different compared to current userbase.

Yes, but at the moment we do not often have to answer the question “How can I add a button to Urhosharp”

can’t understand why, but if that’s the case then the merge is indeed sleeping with the fishes

becuase eastl is slow

Migration from custom container library to augmented EASTL

EASTL iterators are raw pointers so iteration is as fast as it gets. If it still is slow for you, then problem is in a chosen data structure or in the code. Typical frame should not be allocating memory. Hot path should not allocate memory. If these are true then any possible slowdown is amortized by vastly expanded feature set. Did you know that Urho3D HashMap used to allocate memory even if it was empty? And it was like that for years. Some SendEvent() variant would cause memory allocation even if no parameters were passed. Urho code is not as stellar as people say it is.

Did you know that Urho3D HashMap used to allocate memory even if it was empty?

How does this affect performance?

Someone already explained the issue here.

I don’t see any measurements taken there.

If rbfx already has everything you want, then go use rbfx.

If you want C#/UrhoSharp, then go ask MS to support it there. They created that mess, it’s their problem.

Please stop trying to push C# and EASTL here.

It’s slower, but why does it matter? Urho is slower than plain OpenGL, yet you still use it because it offers more.

We have already discussed this many times. No one is stopping you from using your containers wherever you need to. But why replace fast containers with slow ones inside the engine?

It was done because maintaining two sets of incompatible containers is even worse than having just EASTL or just Urho containers. I wouldn’t want to work with such code.

So yep there are three options all of which are bad. You just choose your preferred kind of bad

My favorite example is an array of batches, which is sorted every frame. It directly affects performance, but you don’t interact with it in any way. Why touch him?

I do believe that in an open-source project where people do voluntary work, readability and maintainability should trump performance as a goal (unto a point. t’would be idiotic remake the engine in python). If devs hate touching the code, they won’t.
The eastl while less performant than custom-made code, is probably a better choice for the project itself. You’re still using a reasonably fast c++ library.

I have a different question. Do you choose which project you will send PRs, or just decided to engage in organizational activities?

maybe my last message was a bit preachy. Apologies.

I stumbled onto Urho recently while searching for an alternative to Godot.

I read the last rbfx thread and thought the problem could be solved by keeping angelscript and wanted to make the suggestion. I am not dictating what you should do or not.

rbfx is also open source. If it already has all those changes, why not use it instead? Why change Urho3D and turn it into another rbfx?

Does it worth keeping whole class of container for sake of tiny performance gain per frame? I dunno, maybe for someone. Not for me. So I don’t really care.
I never needed these extra 0.05ms per frame.

It’s not like I’m asking anyone to replace Urho containers with EASTL in their projects

I never needed these extra 0.05ms per frame.

60 FPS = 1/60 = 0.01ms

If only things were so easy, if only.
rbfx discussion was the longest thread on this forum, and probably had more activity than whole year prior and after it.

And there were no solution found. The only outcome was that different things should sometimes just stay different.

60F/1000ms ~ 17ms/F

Yes you are right. In any case, this figure was invented and not confirmed by the test. In any case, together with eastl, we get terrible string class. And what about smart pointers?

https://github.com/rokups/rbfx/blob/master/Source/Urho3D/Engine/Application.cpp

std::vector<std::string> cliArgs;

https://github.com/rokups/rbfx/blob/master/Source/Urho3D/IO/File.h

const ea::string& GetAbsoluteName()

Despite (minor) differences like eastl, this is the same code base/3d engine.
So it would be better for the userbase and devs both if efforts are not duplicated.
You seem to devilify rbfx. I don’t believe that’s rational.

There is no duplication of effort, code is ported from two repositories in both directions.

Wouldn’t it be more rational just to use rbfx instead of having to implement major breaking changes to current Urho3D?

The implementation is already done. We’re talking about a merge, which isn’t much work. And I answered to that already.

Welp I don’t think this will be solved today. feel free to close the thread.

.NET Native AOT is totally worth selling one’s soul to a lifetime of adoring MS. Even while a buggy mess it’s still a hundred times better than a ten mile long esoteric log for a handful of template errors.

You can run BEPU Physics as fast native Bullet, the whole thing is nuts.

.net is very fast until it runs out of memory. After that, the permanent StopTheWorld begins.

eastl string is great. Also I kept Urho3D smart pointers because moving away from those proved to be too difficult. Maybe one day, but not today.

If eastl strings are so great, why didn’t you adapt them for your engine? Why all your functions outside string class?

At the same time, you were able to modify the terrible RefCounted for your engine. When you go to great eastl smart pointers, will the new functionality be outside the class too?

We did add extra functions to string class. Only few utf-8 ones are outside due to obvious reasons.

I don’t recall details regarding smart pointers in eastl. Not sure if there is intrusive variant. If there isn’t then there may be nothing left to do othert han sticking to current implementation.

We did add extra functions to string class. Only few utf-8 ones are outside due to obvious reasons.

The reasons are not obvious to me. In Urho3D utf-8 is the internal encoding for strings (like UTF-16 is internal encoding for .net).

What is the internal encoding in your engine?

Does it introduce support for dextrosinistral writing systems?

Btw, in Dry String::Empty() was renamed to String::IsEmpty(), for the sake of consistency.
“Breaks” things though.

…and IntVector#s are converted to float vectors in calculations, just as separate ints would be.

It’s not. You cannot do str[2] in Urho and expect it to pick 3rd UTF-8 character from string. Same with all other string functions. They don’t care about string being in UTF-8.

I would say, ASCII is internal encoding for strings in Urho, same as in EASTL.
It just so happens that UTF-8 and ASCII are kind of compatible.

EASTL has no equivalent of Urho WeakPtr/SharedPtr/RefCounted.
What did you expect to happen?
To have RefCounted replaced… with what exactly?

EASTL has no equivalent of Urho WeakPtr/SharedPtr/RefCounted.

I thought it was the ideal library… It turns out that you have replaced one imperfect library with another imperfect library.

It’s not. You cannot do str[2] in Urho and expect it to pick 3rd UTF-8 character from string

What encoding are characters extracted from a string in when rendering text?

I don’t know who told you that EASTL is perfect library…
It just offers about 10 times as much as Urho containers and I find it quite convenient when writing code.

If I remember correctly, Urho treats string contents as UTF-8, converts it to UTF-32 and then does the rendering. Urho text renderer works with UTF-8 string as input, but String doesn’t know anything about it.

Urho treats string contents as UTF-8

Exactly.

For any input / output (localization, clipboard, input, rendering), strings are interpreted as UTF-8 without any checks. The engine does not even expect that there may be some other coding. But of course that does not mean that the internal encoding is UTF-8.

Windows-1251, CP866 are ASCII compatible, so maybe Urho3D works with it?

RogueWave STL is the only good STL, like any good STL, it doesn’t even know what UTF-8 is. As all things should be.

STL is ThirdPary library. In Urho3D all ThirdPary libraries are wrapped. When you use Urho3D, you are not accessing Bullet and Box2D directly, you are not accessing SDL and Recast directly. In Urho3D we use UTF-8. So need we wrap std::string ?

String as container can keep all these formats. Urho classes just cannot work with them.

UTF-8 support in Urho is at the level of public API (I.e. class methods), while internal format of String is just ASCII-like something.

From this point of view, why did you decide that String knows something about ASCII?

Which is the single most terrible thing in the entirety of Urho3D.

There would probably be a lot less debate about this if Urho’s TL (JTL as I call it, because it’s junk) were a an external library (along with the math and core data types) eliminating most of the code-sharing headaches that rise up in real-world pipeline projects.

How would you change this? How it should look like, for example, adding a node with a physical body in a user’s application with a direct call Bullet functions and conversion btVector3 to Urho3D::Vector3 every time?

I know I’m just a user here, but part of what has always annoyed me about Urho3D is the custom containers. I don’t believe that containers should be encapsulated or wrapped, unlike the other ThirdParty bits, and I think that any containers you do use should be compatible with C++ language constructs. I’m not 100% sold on EASTL itself, but at least it supports standard library naming conventions so that switching to the standard library, or using C++ iteration constructs, is possible.

No professional engine uses STL. But we need to ignore the needs of our engine and use other people’s libraries that do not fully suit us.

Things should be wrapped, but within a reason. It makes sense with bullet, but for example we wrapped next to nothing for RmlUi because it’s a lot of stuff and we ironed out type compatibility. There are times when you do need full power of library api. Same is true for bullet. Try doing something complicated, I do not believe everything is possible without including bullet headers.

Frostbite (eastl), proprietary engine used by Black Desert (stdlib). Just a few that come to mind. Take any game from those companies it will be using stl I bet.

RigidBody is not just btRigidBody with Urho types and Urho-style names, it’s much more. It is component of rigid body implemented via btRigidBody.

It’s quite silly to have “wrapper” that does nothing expect… well… wrapping.
Wrapping is a tool, not a goal.

What kind of functionality you want to add to std::string by wrapping?
These ones?

StartsWith, ReplaceAll, Join, TrimStart, TrimEnd() etc etc etc

We added all this stuff directly to EASTL classes.
This was part of the reason why EASTL is better suited for our goal than STL.
It’s a shame C++ standard doesn’t have such basic methods in standard string type.

With std::basic_string, +, += and append concatenate. C++20 introduces starts_with and ends_with functions to it. erase is quite powerful in that it can do all your trimming.

AngelScript: The generic calling convention

Okay, it’s nice that AS has fallback route that doesn’t depend on ASM. Can Urho work on this fallback route only? Perhaps in new bindings?

Yes.

The engine used generic calling functions on some platform (WEB, ARM64). After the last workaround of VS bugs, this mode is available on any platform.

New bindings are not needed, as there is a set of macros that wraps functions automatically.

elix22 have updated UrhoSharp… The .net binding is generated. See his post.

Actually C# is not bad.

The renderer imrovements @Eugene has been doing on rbfx seems very promising. I wonder if these changes would go to upstream Urho3d?

Thanks!

Yes, it’s bad.
Really bad.
Really really bad.
Really really really bad.

Since rbfx is so promising, why not use rbfx instead.

Also, apparently Github has “forum” (Discussion tab) support now. Maybe ask rbfx to enable it on their Github so they can finally have a forum.

It looks interesting. Is it possible to download a forum using a git client the same way as wiki?

Hi @adhoc99 , don’t misunderstand me, I’m working on Urho3D some times and recently just contributed a little to the project when I got some vocation.

If you look at the rendering subsystem of Urho3D closely, you’d find there is surely need more work. For the future of Urho, it needs improvements, a lot. Additionally, Eugene is also one of the main maintainers of Urho for a long time.

I took a look at the Discussion documentation but couldn’t find an option for that at the moment. Apparently it looks more like the issue system than the wiki system.

I don’t really see a point in talking about it now, since upstream community has already declined to accept these changes.

We had this discussion year ago, and significant portion of Urho community has refused to accept breaking changes from the fork to upstream repo. And I respect others’ choises even if I don’t agree with them.

I know that you are afraid of telemetry, but elix22 work is not Microsoft’s work.

Everything you do now a day is monitored. E.g. Google record everything you do on android phone, Windows record things you do on windows, Apple record everything you do on Apple’s phone etc… Now stop using them. When you go to the web, website track your interest with AI and display your last view items. Now, do you stop using the internet too?

.Net core is opensource. Just disable what ever function you wanted…

Guess we have to run in terror at v1 and v2 UUIDs because how dare someone other than me be able to use hard work to figure out my mac-address from a bunch of UUIDs … when my mac address is already used pretty much everywhere /s.

Telemetry and sysinfo arguments are tiresome because when someone complains about basic telemetry data they’re likely also complaining about Wirth’s Law or “planned obsolescence” somewhere else.

Do you expect platform vendors to just magically divine the decisions they need to make in regards to their targets to support?

The last time MS made “magical” decisions … we got Silverlight.

No, just not oblivious to it. Some people actually care about privacy.

Maybe use Startpage or DuckDuckGo instead of Google, LineageOS instead of Android, Linux instead of Windows or MacOS, Firefox instead of Chrome, and NoScript, uBlockOrigin, TOR, /etc/hosts, etc.

And being opensource doesn’t make it good in the slightest. It and C# are still horribly slow.

duckduckgo knows everything you do. When you are on the internet, really there is no privacy.

How big is the game you are making? 100 players? 1000 players? The wrapper is auto generated, so if you are developing in C++ then it does not effect you.

Telemetry is what’s bothering you people? If anything, I’m against C# simply because it requires another compiler. Angelscript is interpreted letting you edit it faster and could be later compiled for release

I don’t like C# simply because ¯\_(ツ)_/¯
I just like C++ more, nothing else.

Yes, you have good point too. C# introduces too much build complexity into project, I just don’t trust it to be reliable and stable.

The linux crowd is getting very very loud despite the OS not being a viable target.

Even when Valve tried to hamfist it into a target it failed.

Nixer’s and AMD/ATI fanboys would shit themselves if I had free reign in the graphics code. Fuck AMD if they won’t offer competitive APIs to VR-works or NV’s fast-gs. Intel has a fast path, why is that so hard for AMD?

Have you heard anything about android?

Embroiled waist deep in lawsuits that will end the platform if they lose.

The lawsuits concern only the virtual machine, not linux (which is not a operating system, but a kernel). They have plans to create their own virtual machine. In addition, Linux turned the software world upside down, it made even Microsoft pay attention to open source.

No, they concern the app market as a whole. Gacha games in particular have come under attack as most use a “complete” model that is illegal in most countries so many games have had to change their model like SMT-DX2 where they ceased the loop on upgrades and added a spirit mechanic to dodge the law.

In any case, when the Chinese say they need to switch to linux, the whole world will switch to linux xD

You can bet on that , I am not affiliated to Microsoft in any way
Actually after 20 years as a professional in the Software industry and with Covid’s help I decided to take a year off and relax this year (I can afford it) .

As a C++/C developer all my professional life , I was actually very surprised by the really good performance of Urho.Net , specifically on mobiles (Mono runtime) .
It’s actually has fast edit/compile iteration time , on par with AngleScript or any other scripting language.
AngleScript runtime is actually much slower than the Mono runtime(I actually did some benchmarks on a bunch of scripting runtimes …)
AngleScript doesn’t have any good IDE support as opposed to C# (Visual-Studio-Code is just perfect in my opinion)

I am not trying to convince anyone or sell anything
By the end of the day Urho3D is just a middleware , the end-goal objective is to create fun enjoyable games .
Everyone should feel free and comfortable to use any language and platform to bring their creative games into live.

A very valid question about new renderer turns into bikeshedding fest. This is why upstream can not have nice things.

Comparing C# and AS is incorrect. Because AS is an embedded language. For example you need a console in your application - use AS. You can only compare C# with C ++. And C# loses to C++ in many ways.

I don’t think that’s the case today anymore , it’s supported on all major platforms.
The related runtimes are all open sourced and if you run AOT code than the performance is on par with native compiled code.
I personally think Net 6 is going to be a game changer.
Yes it has some cons (I personally don’t like the GC stuff ) but it has big advantages when it comes to
fast iterative development

Never thought I’d see gacha being discussed next to lightmappers and telemetry

Yes, GC is a big problem. C # application runs fast until it runs out of memory. After that, the constant “stop the world” begins.

And if a C++ program runs out of memory? Either way if your game needs more than 4GB of RAM you’re doing something wrong.

You probably don’t understand well how GC works. C# can’t even handle simple applications like autoclicker.

GitHub - 1vanK/AutoClicker
Cell to Singularity - Evolution Never Ends | Cheat | Auto Clicker - YouTube

The first half an hour the program works normally, but the longer it works, the more often it freezes and the longer these microfreezes. I write all my utilities, and even medium-sized projects in C #. But never in my right mind would I use it for anything serious.

Why are you clicking so fast?
1/100 seconds. e.g. 100 clicks in a second?
If you want to write a bot then 2 clicks every second is already too fast. You will bring every application down by clicking that fast.

I used to write an auto clicker to test my application (data capturing tool). It can run several hours without problems.

I think it is depends on how event messages are implemented. If they implemented similar to the UDP technique then it won’t slow down.

I wonder why. There’s no explicit allocations in autoclicker. Do you know why it cannot work smoothly all the time?

While others adhere to false profits.

Much time passed and my memories became clouded. It was not the program slowed down, but the game which is written on Unity. This is written in README in repo.

There is a message queue.

Seeing people arguing with each other is actually much better than checking a dead fish forum and project.

Why we talk about language choice? I guess only a few people like Java in this forum, but it’s still an important part of our software world.

To be or not to be. It seems very binary. Maybe this question is fundamentally wrong. (For the community)

I think we should just upstream C# support and be done with it.

Or maybe stay on rbfx since it already has C# support.

But it’s a perfect fit together with boost. I know you would love it as well.

Fits a lot better on rbfx. It could even become the next “unity”.

Probably next “division” from the looks of it

Same old, same old. [α ω]

How’s that forum coming along?

Its there. But this place is more fun

Its ok, we still love you

Upstreaming C# in one way or another. Be it embedding mono, one of the newer for embedding CoreCLR experimentals (I was delighted to see those efforts from MS), or as PInvoke bindings should be a priority.

Urho desperately needs some new blood and C# is a good avenue to catch some “victims” … I mean future contributors that aren’t soiled with arguments of old.

Reality is we all tend to fixate on rendering and that holds us down because everyone with any knowhow in that area is strongly opinionated in one specific or another which is often in conflict with others.

C# is something that at worst dissenters can belatedly agree with for the greater benefit of fresh blood.

At some point we do have to accept that we’re dead in the water and need to start swimming.

Edit: I prefer embedding mono or CoreCLR than Swig bindings, but that’s me. If Swig gets us there faster, let’s do it. I’m onboard for contributing to that sort of thing.

We should also probably retire Angelscript and keep Lua but focus on making sure we’re Zerobrane compatible for those that choose Lua. Even as an Angelscript guru myself, it’s time to just let it go. Dial in what we need to do, which is be future facing and move on.

C # will only attract people who won’t write C ++ code. We already have a lot of forum posts from UrhoSharp users “Hello, I need to add a button, help me!” These people will not help the development of the engine in any way.

Just curious, what’s you opinion on ongoing renderer refactoring?
I think you are the only person here who have really touched renderer deeply.

TL;RD is to increase flexibility and ease of change:

• Remove shader copypaste with help of SpirV-Cross
• Remove hardcoded shader permutations aka LoadPassShaders
• Replace declarative XML RenderPath with programmable one
• Cache pipeline states externally to simplify modern GAPI backends integration and remove this kind of equilibristics in PrepareDraw:
  
  

  image1005×275 10.6 KB

Thanks God I know how to add a button

Ask yourself this :
1 - What kind of people did you attract so far by investing so much effort on AngelScript ?
2 - Did you attract major game engine developers that contribute to Urho3D ?
3 - Did you attract Game developers that are making games with Urho3D ?

The more people you have that are asking “how to add a button” the better , these are the key people.
These people will also attract Game engine developers that will contribute to Urho3D development .
The " Chicken or the egg" problem Chicken or the egg - Wikipedia

So far there are no chickens nor eggs , just a dead fish

We have AngelScript, but it annoys many people that you have to manually make bindings. I am solving this problem.

About “more users = more developers” this is very controversial. For example, a Unity developer talked on the Box2D forum and asked a lot of questions. As a result, Unity has a CapsuleCollider2D, but he hasn’t sended the modifications to the main repository. Bullet is very popular library. But how many contributors does it have?

@Eugene

Is there a render refactor branch around?

Aside from pipeline-hell (which isn’t that bad if you know most of your permutations AOT) SetData/GetData is the pain point in the modern apis as Urho doesn’t consider that anything could be async. I’d hope there isn’t a lot of code out there depending on a GetData including the contents of a SetData from a few function-calls ago, it’s easy enough if tracking sync-points and waiting before rendering is enough. Descriptors suck. I haven’t touched the new APIs much since picking up TheForge, so I’m probably missing things.

Be it GLSLang+SPIRVCross or ShaderConductor one of them is necessary IMO. I use ShaderConductor but have used GLSLang+SPIRVCross and only prefer SC because of append/consume structured buffers (spits out extra buffers for the counters in GL/VK).

I’m not a fan of the renderpath as data either. It’s a headache and if you’re doing anything complicated it turns into a mess of toggling tags or concatenating multiple renderpaths. It’s hard to handle things like quality settings well. Adding single-pass stereo to that was a complete cludge-fest.

I cringe whenever I see all the bitwise hell that’s scattered about. I gave up and tore it out in a few places to just crc64 stuff instead.

I hate thinking about this stuff though because there’s so much to trivially miss in the renderer. Be it stencil test on lights, vertex-lights being a thing, zones being awkward.

@1vanK “more users = more developers” is indeed very unlikely, but “more users = more tiny, often questionable PRs” seems probable enough. Sure stuff like “how do I change the color of a button” sucks, but it’s not like it’s only trivial nonsense that’ll come up.

Here is the branch. This folder is basically 80% of new code. There’s still a lot of draft code and most of samples don’t work yet.

Yeah, Since I’m working in the fork, I don’t really bother. I aim at 98% feature parity, I don’t think I have to pick every single little feature that old renderer has.
E.g. I ignore “shadow map reuse” completely. And light stenicl/scissor optimizations (perhaps I’d add them later)

Its tricky. Well nowdays it is less tricky, but in the past it was quite annoying. For example to debug mono in visual studio all these big engines provide IDE plugin. It is absolute nonsense. Now that Microsoft aims to ship mono as part of .NET6 that might change, but still… The path i have taken is runtime-agnostic. Swig generates interop layer that runs on any runtime and we create application entry point in C# executable, which gives us free runtime hosting without writing any of runtime hosting code. This means we could run everything on old .net framework and debug it in Visual Studio just like that, while also doing same with mono on linux in whatever IDE you work on linux. Note that you can not really avoid c interop layer no matter what runtime you use. There are some solutions like CppSharp or Biohazrd (early WIP) that side-step c layer altogether, but i did not have good luck with either of them. So we would still need Swig or something comparable no matter what. Now that .NET6 is bringing different runtimes together (mono+net core) seems like i unknowingly took a right path, as entry point delegation to C# code hits a jackpot here and we can get same code run on multiple platforms and runtimes easily. It might sound annoying for people who want to mostly use C++ and only do some light scripting in C#, but managed entry point is merely this:

internal class Program
{
    private void Run(string[] args)
    {
        Urho3D.ParseArguments(Assembly.GetExecutingAssembly(), args);
        Context.SetRuntimeApi(new ScriptRuntimeApiReloadableImpl());
        using (var context = new Context())
        {
            using (Application editor = Application.CreateApplicationFromFactory(context, CreateApplication))
            {
                Environment.ExitCode = editor.Run();
            }
        }
    }

    [STAThread]
    public static void Main(string[] args)
    {
        new Program().Run(args);
    }

    [DllImport("libEditor")]
    private static extern IntPtr CreateApplication(HandleRef context);
}

Everything else (starting from your Application subclass) is done in C++. I would say its a cheap cost to get multi-runtime support without any special code for each runtime.

By the way i did try runtime hosting. Running your application in debugger and expecting to work is out of question in that case (on linux at least). So it isnt very user-friendly.