Windows Phone support?

Is there any chance developers would implement basic support of WP platform in future?

SDL does support WinRT nowadays, so it’s not an impossibility, but it would be a large undertaking, as it practically needs implementing a D3D11 renderer first.

A DX11 renderer would be nice to have at some point, especially if we can take advantage of the many new features not present in DX9. The way the project is organized so far, it wouldn’t be too disruptive to begin adding support for it. Though we would need someone familiar enough with DX11 to make something solid.

I’ve had some experience with dx11 in wp8: I think it’s just some wrapper about dx9 hardware with disabled features of dx11 and enabled complexity of dx11 :angry:

There are at least two ways to go implementing a D3D11 renderer.

  1. The API & compatibility-disrupting, efficient way. We change our whole low-level rendering API to benefit from D3D11 concepts, like the immutable state objects. Materials use uniform buffer objects instead of individual uniforms. OpenGL2 and D3D9 backends are rewritten to emulate D3D11 concepts. This breaks Urho programs which rely on the old low-level rendering API.

  2. The minimal hack way: we write a D3D11 backend which emulates D3D9/OpenGL2 concepts like the individual renderstates and individual uniforms, and maps them to D3D11 concepts. This will not break compatibility, but it doesn’t realize D3D11’s full potential for performance gains.

Also, unless some magic is performed, D3D11 requires writing a third version of every shader. One possibility would be to ditch D3D9 at that point in which case we’d be back to just two versions: GLSL and D3D11 HLSL.

EDIT: somewhat related to the discussion at hand, I’ve started an experimental toy engine project which will explore modern graphics API’s, different scene representation (basically merging the concept of “child node” and “component” into one, as well as unifying scene and UI) and radical lack of reliance on 3rd party libraries. I’m not quite up to the rendering part yet, but I’ll start from D3D11. With some luck the knowledge gained from this will benefit Urho3D as well, and can in time be “transplanted” back:

code.google.com/p/turso3d

That toy project sounds like a great way to test concepts. I love how you specify multithreading in your “to do” list for the project, that’s something that Urho3D could definitely use.

I propose a different way of implementing D3D11: Separate the Graphics subsystem. We can keep the original Graphics subsystem for OpenGL/D3D9 support, then add a Graphics_D3D11 subsystem which utilizes all the new awesome stuff that D3D11 has to offer. That way we don’t need to ensure compatible between the various graphics modes.

I say this because the entire concept of implementing D3D11 being coupled with the implementation of OpenGL or D3D9 runs in the opposite direction of the existing Component-based structure.

The thing is, however, that a lot of classes in Urho rely on the Graphics subsystem API. Materials, the high-level view rendering, even UI. Having a different Graphics for D3D11 would mean also creating two versions of these classes, or a lot of #ifdef blocks inside them, and the differences could likely leak to the outside API, for example Material class exposing individual uniforms vs. constant buffers.

Material class is part of the Graphics subsystem, there should be no problem separating it. UI is one of those things that will probably either need several #ifdef blocks or its own separate UI_D3D11 subsystem.

It sounds to me like it’s time for some potential refactoring. It seems that the entire point of the subsystem-based approach is so that developers can mix-and-match just the systems they need. If we’re going to run into these problems because some systems are too tightly coupled, then we need to decouple them and rethink our approach.

Maybe there is a small point to try to use ANGLE WP8 port? Just for basic support for this platform?

I don’t think there’s a refactoring possibility that can help to avoid coupling to Graphics, if we want to keep the idea that you write multiple rendering backends, but only need to write the higher-level rendering (meshes, lights, materials, UI) once. Compare to Ogre’s RenderSystem interface, to which all Ogre’s higher level classes talk to. The optional subsystems (Physics, Navigation, Network, Script…) on the other hand are very easy to keep decoupled. However, there may be a possibility to do adjustments to the Graphics API that accounts for both the old API’s and new, for example make a SetShaders() call that accepts geometry / hull shader pointers, but practically those will always be null on OGL2 / D3D9.

Yes, ANGLE would be the fastest shortcut. Though considering that a phone is always slower than a PC, running extra code to function as a realtime graphics API call translator doesn’t sound like it would get stellar performance.

In the Turso3D engine (code.google.com/p/turso3d) I’ve now basically completed a D3D11 renderer. From this experience it should be doable to also implement D3D11 rendering in Urho. There are many options how to proceed but keeping the old Graphics API just as it is should result in reasonable performance, though obviously without any D3D11 extra features. Basically we’d create D3D11 state objects on the fly as needed from the Urho renderstates.

However, in Turso I wrote shaders from scratch using the SM4 profile, while in Urho it wouldn’t be nice to have to write shaders three times (D3D11, D3D9, OpenGL). If we want to retain Urho as a viable engine for old Windows computers, dropping D3D9 means only choice is OpenGL, which may potentially have very bad drivers. SM2 could be dropped at any time though.

From this experience it should be doable to also implement D3D11 rendering in Urho
cool! yes it’s time )

dropping D3D9
it’s nice idea (I always was interested only in open gl), but mb better make option for this then you build urho3d (use dx9 or dx11 )

Yes, I think there was a discussion topic quite sometime ago about supporting the “plugins” mechanism similar to Ogre’s RenderSystem.

Very cool Cadaver! I like the design of Turso3D’s graphics, serialising render states like this lends itself well to a Mantle/DX12 or GL-next approach, from seeing the NV_command_list extension. The multiple shaders situation is still painful though, not really sold on bgfx’s approach or Unreal4’s non-free HLSL cross-compiler either.

I think DX9 is still viable for all those Windows XP machines in China, it all depends what state the OpenGL driver is for these said machines, the Intel driver especially. Nvidia would expose stable enough drivers with perhaps GL3 or GL4 even.

store.steampowered.com/hwsurvey
stats.unity3d.com/pc/

From memory I don’t think China is listed in the steam hardware survey (one of their steam dev days mentioned this that DOTA2 was deployed outside of steam in China). The Unity3D stats are more reflective of this, having the unsupported Windows XP at 39.1% (!)

Hello Cadaver,

I think you could drop DX9 support and keep OpenGL but maybe switch to OpenGL 3.x ?

OpenGL support need to be keeped of course :slight_smile:

[quote=“cadaver”]In the Turso3D engine (code.google.com/p/turso3d) I’ve now basically completed a D3D11 renderer. From this experience it should be doable to also implement D3D11 rendering in Urho. There are many options how to proceed but keeping the old Graphics API just as it is should result in reasonable performance, though obviously without any D3D11 extra features. Basically we’d create D3D11 state objects on the fly as needed from the Urho renderstates.

However, in Turso I wrote shaders from scratch using the SM4 profile, while in Urho it wouldn’t be nice to have to write shaders three times (D3D11, D3D9, OpenGL). If we want to retain Urho as a viable engine for old Windows computers, dropping D3D9 means only choice is OpenGL, which may potentially have very bad drivers. SM2 could be dropped at any time though.[/quote]

I am personally sick of transpilers from work. Given all of the possibilities though the transpiler option, bgfx shaderc + glsl optimizer isn’t a bad one. There is also the angle approach for old intel hardware. If we had opengl/dx11 and angle for old windows intel cards it would open up things like nanovg.

I would like to hear your more on what you learned from writing another renderer. Did you find any oportunities for optimizations for urho cpu side? The legendary, tyrannical king among fish will be more fierce then ever!

I see the earlier comments about dx11 indicate that maybe it could get messy as far as graphics classes are concerned-- but otherwise I think having duplicate shaders wouldn’t be too big of an issue as we already have the dx9 shaders ready. Future shader additions is extra work on contributors, but there’s nothing that requires an engine-user to write shaders/offer every graphics API option.

From an overall value perspective, I think having dx9-level support is a plus on Urho’s side. Dx11 would be a great addition too.

The original topic is about getting windows phone support, so I’m not sure if it’s on the table-- but would tessellation and geometry shaders be on the table with this proposed change?

D3D11 is a prerequisite for Windows Phone support. Obviously it would need work elsewhere too, but the render API is probably the biggest hurdle. Realistically speaking it will need a contributor who is interested and has hardware, to finalize the work once D3D11 support is in place, and also to keep maintaining the port.

By adopting newer rendering API’s things like geometry shaders and tessellation become possible, that said I don’t have experience of them so that too will probably require someone who has an idea of how they should be used and what the API should look like, but they should be easy enough to contribute once the newer API itself is in place.

For optimization: I did find some opportunities, for example simplifying the Drawable virtual function interface for updating objects in frustum, ensuring that we don’t go through all the visible objects unnecessary times, and updating render state settings only just before the draw call, from a cached state that the Graphics class stores. Nothing major though, as Urho is already fairly good in its CPU & API use effectiveness.

I’d like to help with GL4/DX11 code where possible. When do you plan on integrating Turso3D things to Urho3D Cadaver? Or would you perhaps reshape Urho3D to be more in line with modern hardware and treat DX9/GL2 as a fallback?

But yeah it would just be some experiments on the side from me due to lack of time, OpenSubdiv is a nice codebase to look and see how they do tessellation in a practical way (despite the massive draw call overhead). This reminds me I got Oculus on the backburner once I get my DK2 back again too…

I will not commit to any firm promises but it looks like I’ll be working on it during the first half of 2015. Will still need to make some final experiments related to shader language and perhaps implementing a quick & dirty fallback D3D9 renderer in Turso to see what it would look like before I start gutting Urho.

With current perspective it looks like the only major change would be the use of constant buffers. In Turso I have a pretty heavy-handed approach where I assume nothing of the uniforms, and actually require users (as well as the high-level rendering system) to craft properly ordered constant buffers. I’m not sure if this is the way to go, as it would make Urho somewhat less friendly to use. The alternative is to have the shader tell its constant buffer layout, and go always through that layout mapping when updating uniforms (like before). This seems to also be the approach used by bgfx.

Other things like tessellation, geometry shaders would be just additions that don’t disrupt the existing API.