Not much, just things i personally find useful. They do not align with goals of upstream and have little chance being accepted into main Urho3D project.
Some things i did there:
Completely rewrote build system. It is not as feature-full as current Urho3D build system, but is much more lightweight and easier to modify. Also added gradle build script for android so that new SDK/NDK can be used. Thanks to @Pencheff and others for doing research!
Removed AngelScript and Lua bindings because IMHO they are toys that require way too much maintenance. Scripting languages have their place in scripting scene logic, but wrapping entire engine only to allow use it for someone who does not know how to compile c++ code… I am not interested in that.
Added imgui subsystem and integrated it with Urho3D UI so they do not fight when both are available on screen.
Started writing imgui editor in that fork. Future of editor is not clear to me at the moment. @Eugene wants to see it upstream but at the pace Urho3D is moving i find it very demotivating to contribute to upstream.
Added easy_profiler integration which was originally written for Atomic. Actually useful profiler is very important.
Convinced @boberfly to add bgfx backend. He is working on the code, i make build system happy. Porting happens on a fork of my fork. bgfx will land in my fork way before PR gets accepted by Urho3D.
Added my tasks (stackful coroutines) subsystem. Yes, it may not work on all platforms. They are still awesome.
Added convenience subsystem getters with pointer caching because writing
GetCache() is definitely better than writing
GerSubsystem<ResourceCache>() and hashmap lookups for getting subsystems is wasted work. I know hashmap lookups are fast. It is still wasted work. Practicality beats purity. This by the way was suggested to Urho3D in a PR and was declined.
I am working on c# wrapper generator using CppSharp. We will see what comes out of it. No promises
This fork does not offer hard backwards compatibility guarantees. This is a moving target and you will need to update your code after engine update. To be honest i did not really intend others to use this fork so i suggest to not grow dependant on it. I view it more like incubator of nice-to-haves. @dragonCASTjosh wants to contribute some cool shader work which may or may not be accepted by upstream. My fork is more accepting of all kind of code. This ultimately means that code will not be as stable as vanilla Urho3D. My work is oriented towards a powerusers who know what they are doing. Newbie users should not use this fork because they will definitely have a very bad time with it.