Apple deprecates OpenGL and OpenCL

All in favor of Metal
https://developer.apple.com/macos/whats-new/#deprecationofopenglandopencl

Sucks.
@boberfly it’s your chance! xD

That was expected. Anyway WTF. While you can expect Mac to take ages before open gl goes away, this is almost sure to be removed on next ios version (that is, ios 13). This means we probably won’t be able to ship anymore for ios in one year.

It is actually an opportunity to see whether this project is dead as the fish or not.

World needs to be saved!

Indeed. Everybody welcome the Urho showdown.
Will it survive, or will we have to rename it “the deadfish engine?”

MoltenVK, translation layer from Vulkan to Metal is open sourced -

Currently, we have DX9, DX11, OpenGL renderers.
The practical way to survive for Urho is -

• Add Vulkan (especially for Android)
• Support Metal (via something as MoltenVK or directly by using Metal API)
• Abandon DX9 (goodbye a few WinXP users)
• Optional support for DX12 (DX11 is good enough for a lightweight game engine)
• We are able to be more advanced for the graphics, sitting on the modern graphics APIs: DX11/Vulkan/Metal

Edit: for optimists, we only need to add one Vulkan renderer

Or add BGFX backend and don’t care anymore
BGFX has its own problems tho. Too highlevel batch processing is one of them.

I also wonder what Apple is going to do with WebGL to keep it working in iOS browsers.

Excuse my ignorance, but I always thought Vulkan ran directly on Mac. Why would you need a vulkan-to-metal layer?

Even if Urho had Vulkan shaders, you would need this on Mac Os / Ios
In short only Metal and Open gl are supported by Apple as of now.

I am afraid that no one will add any support for Metal .

The best way would be to take an off the shelf cross platform solution that is actively developed , i.e. BGFX.

Another option would be to use ANGLE with an Vulkan backend which is currently under development and put it on top of MoltenVK

So the translation would be : OpenGL ES -> Angle -> Vulkan -> MoltenVK

Urho heavily dependents on OpenGL, I have been studying Metal for several days, there are too few tutorials and examples to cover all cases, such as water, grass etc. To port the render part, you need to re-write nearly all codes, include c++ part and shader part.

Not hard for Po, the kungfu panda. As rabbit and pig, I’m calling for the panda to save the world, or his fish master

I’m trying bgfx these days. Could you elaborate on this?

AFAIK batches are totally independent.
If you want process 20k batches, you have to fill every batch with all possible data including all shader uniforms.

It allows more optimization, but require more processing.

When’s the next release of Urho3D ? Is the project really dead in the water ? It’s been a long time since 1.7 and slant.co is saying the popularity of Urho3d is on the decline.

I’d say resources are low on many fronts and we lost our commander, but there sure is a pulse and steady progress on this already very functional engine. What lightweight bells and whistles did you have in mind?
As you may know from metal lore, Urho is quite comfortable in the dark, and as long as it works for Linux it works for me.

What lightweight bells and whistles? An easy way to export project to Android Studio for compilation/signing. To me, urho3d is feature complete for now. Just missing the most important obvious support for Android.

If you really look at the recent release history then you should know usually Urho only release about one version a year and that version 1.8 is not overdue yet. Also note that we are not in a hurry of releasing anything. It’s ready when it’s ready. And as for Android build support using Gradle out of the box is just perhaps a day work. The problem is, no one works full day for this project.

A good intro tutorial is here, albeit old: https://www.raywenderlich.com/146414/metal-tutorial-swift-3-part-1-getting-started
Anyway just reading it is sufficient to agree to what you say: it would take a complete rewrite. Difficult.
Besides that, I’ve checked out bgfx. Same, even worst; that’s more low-level too, imho. That’s another rewrite.
No opt-out of open gl as of now. Bye bye, Apple.

@boberfly had some progress with it.
Why do you think that BGFX would be even harder to adopt?

The metal approach looks like much Urho; high level abstraction. I feel bgfx is abstracted someway but low level at the same time. Just a feeling, probably stemming from differences between c++ and swift.
Not really sure anyway about which would be tougher to integrate in Urho…