Page 1 of 8

Ogre`s Windows 8 UI Style port (now commited to OGRE!)

Posted: Tue Mar 06, 2012 11:05 am
by Eugene
Update:
Port to Windows 8 is already done, repository and dependencies are here:
https://bitbucket.org/sinbad/ogre /* integrated into v1.9 */
https://bitbucket.org/eugene_gff/ogre-winrt /* development history */
https://bitbucket.org/eugene_gff/ogre-d ... cies-winrt

Both CoreWindow and Xaml scenarios are supported.

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 06, 2012 11:19 am
by Eugene
JDX_John wrote:Cool :)

Could you summarize the main changes you had to make? It looks like you retained existing D3D11 RenderSystem?
Of course. Here is my original plan:
1. Build Ogre with #define WINAPI_FAMILY 2 using subset of Win32 that is allowed for Metro-style apps. Fix/re-implement/exclude from build Timer, ErrorDialog, ConfigDialog, WindowEventUtilities, DynLib.
2. Tweak RenderSystem_Direct3D11 to work over ICoreWindow instead of HWND. This must be made via #ifdefs to avoid unavailable API usage, but in all other aspects Direct3D11.1 is similar to Direct3D11.
3. Rebuild Ogre`s dependencies with #define WINAPI_FAMILY 2, build simple sample application and check with Windows App Cert Kit that nobody uses forbidden API and sample application is "Windows Store clean".
4. After Win8 beta1 in late Feb 2012 investigate and add support for Direct3D/XAML mixed mode, i.e. not full screen applications.

Almost all of this was done. Mixed Direct3D/XAML mode is supported by Win8 Consumer Preview but not yet enabled in Ogre, and some forbidden APIs are still used - I`ll fix this ASAP.
Slightly bigger problem is with HLSL shaders - I compile them via d3dcompiler_44.dll instead of unavailable D3DX library. But Microsoft allow shader compilation only for development builds, and not for retail. While Ogre can avoid shaders compilation in runtime using microcode cache, it still depends on shaders reflection for determining shader`s input and constant buffer layout. This problem must be solved, may be even by implementing custom shader reflector.

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 06, 2012 11:25 am
by Eugene
lonewolff wrote:Nice one, bro 8)

How does it go with app store certification?
Not yet completed, but issues are minor and I`ll fix them ASAP.
Aforementioned problem with d3dcompiler_44.dll is here too, and it is not so easy to fix.

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 06, 2012 11:44 am
by JDX_John
Do you have any screenshots or anything Eugene?

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 06, 2012 1:14 pm
by DimA
There is a minor issue while Eugene fix this. You have to create Dependencies link to real dependencies directory in cmake generated directory.

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 06, 2012 1:16 pm
by Eugene
JDX_John wrote:Do you have any screenshots or anything Eugene?
Screenshots are the same for win32 and winrt :)
But if you really want it, here screenshot from simulator

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 06, 2012 1:21 pm
by JDX_John
So does that mean it is not working in Metro? I was hoping to see a nice Ogre tile :)

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 06, 2012 1:39 pm
by DimA
"nice tile" means nothing. This screenshot together with task manager shows Ogre Sample running as true Metro app.
It's only way to show this fact, because Metro apps launch in fullscreen mode.

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 06, 2012 1:57 pm
by DimA
Anyway if you want "nice tile" here it is:

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 06, 2012 2:26 pm
by JDX_John
DimA wrote:"nice tile" means nothing. This screenshot together with task manager shows Ogre Sample running as true Metro app.
It's only way to show this fact, because Metro apps launch in fullscreen mode.
Oh yes, though we do also have side-by-side mode, yes?

Is it feasible to use the "live tiles" functionality, where a tile's content can change (similar to email, twitter, etc)? Could we even render Ogre into the small tile?!

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 06, 2012 4:04 pm
by DimA
You may also teach a rabbit to smoke if you like :)
Check out following link:
http://msdn.microsoft.com/en-us/library ... 65360.aspx

Re: Ogre`s Windows 8 Metro Style port

Posted: Fri Mar 09, 2012 2:51 pm
by Eugene
Here is the list of virtual machines known to work with win8:
http://blogs.msdn.com/b/b8/archive/2011 ... nment.aspx

Building process for OGRE_BUILD_PLATFORM_WINRT requires some manual steps and is described in BuildingOgreWinRT.txt,
here are some highlights from this file:

1. You need Windows 8 Consumer Preview (build 8250) or later.
(http://windows.microsoft.com/en-US/windows-8/iso)
Windows 8 Developer Preview (build 8102) is not supported.

2. You need patched CMake 2.8.7 from Feb 23 2012 or later for
VS_WINRT_EXTENSIONS and VS_WINRT_REFERENCES special target properties.
(http://www.cmake.org/files/dev/cmake-2. ... 32-x86.exe)

3. You need Visual Studio 11 Ultimate Beta or later.
(http://www.microsoft.com/download/en/de ... n&id=28975)
Visual Studio 11 Express Beta is not supported.

Re: Ogre`s Windows 8 Metro Style port

Posted: Fri Mar 09, 2012 3:59 pm
by JDX_John
Is VS11 a hard requirement for WinRT, or is that just what you were using because it was easiest?

Re: Ogre`s Windows 8 Metro Style port

Posted: Fri Mar 09, 2012 4:52 pm
by Eugene
JDX_John wrote:Is VS11 a hard requirement for WinRT, or is that just what you were using because it was easiest?
Hard requirement.

Using WinRT from pure C++ is not fun, and C++/CX is supported in VS11 only.
Also, Metro Style applications have very special build/deployment steps, only MSBuild from VS11 knows about them.
Also, CRT must be "Metro-clean", i.e. do not use forbidden APIs, therefore it must be CRT from VS11.

Re: Ogre`s Windows 8 Metro Style port

Posted: Fri Mar 09, 2012 5:05 pm
by JDX_John
Ugh :( I'd imagined WinRT API was a bit like a total replacement to Win32 API so we could just point VC++ at different libraries.

Oh well... maybe it'll finally be time to upgrade from VS2008!

Re: Ogre`s Windows 8 Metro Style port

Posted: Fri Mar 09, 2012 5:35 pm
by spacegaier
JDX_John wrote:Ugh :( I'd imagined WinRT API was a bit like a total replacement to Win32 API so we could just point VC++ at different libraries.
Oh well... maybe it'll finally be time to upgrade from VS2008!
Exactly my thoughts as well :D.

@Eugene: Great work your are doing here! Keep it up!

Re: Ogre`s Windows 8 Metro Style port

Posted: Fri Mar 09, 2012 5:58 pm
by Eugene
JDX_John wrote:Ugh :( I'd imagined WinRT API was a bit like a total replacement to Win32 API so we could just point VC++ at different libraries.
It`s true, but even those different libraries are in special format - *.winmd files with .NET compatible metadata.
C++/CX (component extensions) compiler is familiar with this format and provides some syntax sugar to work with, just like C++/cli is familiar with .NET assemblies format.
I saw examples of working with WinRT without C++/CX - it`s very verbose and heavy COM related code, I feel pain only from looking at it.
It`s like programming Win32 with assembler - unnecessary verbosity and no benefits - just wrong language.

Re: Ogre`s Windows 8 Metro Style port

Posted: Sun Mar 11, 2012 7:58 pm
by Wolfmanfx
So i installed win8/vs11 on VMWare Fusion4 (MBP) builded deps and now building the OGRE core but the CMAKE script do not create the ogre sample projects so i am missing something here?

Re: Ogre`s Windows 8 Metro Style port

Posted: Mon Mar 12, 2012 10:50 am
by Eugene
Wolfmanfx wrote:So i installed win8/vs11 on VMWare Fusion4 (MBP) builded deps and now building the OGRE core but the CMAKE script do not create the ogre sample projects so i am missing something here?
Yeah, you missed BuildingOgreWinRT.txt file with description of required manual build steps :)

I fixed one more problem - output folders for built dependencies was not pre-created. Update your dependencies.

Re: Ogre`s Windows 8 Metro Style port

Posted: Mon Mar 26, 2012 2:51 pm
by Cygon
I have your WinRT build working in my own, minimal metro application. All in all it was pretty smooth going, although in the end I had to dissect the sample browser a bit to figure out how to pass CoreWindow pointer to the Direct3D11 renderer :)

Image

Running an empty render loop works fine (see the nice blue background that I set for my viewport), but as soon as I add a model, the renderer complains that I do not have a vertex and pixel shader set:

Attempted to render to a D3D11 device without both vertex and fragment shaders there is no fixed pipeline in d3d11 - use the RTSS or write custom shaders.

The problem is pretty obvious from the message, but being an utter noob at Ogre, I'm not even sure if it's due to Direct3D 11, or due to WinRT, or if my code is simply wrong. Here's what I did:
  • Created a scene manager, camera and viewport
  • Raised the ambient light level
  • Code: Select all

    Ogre::Entity *entity = this->ogreSceneManager->createEntity("Head", "ogrehead.mesh");
    Ogre::SceneNode *node = this->ogreSceneManager->getRootSceneNode()->createChildSceneNode("HeadNode");
    node->attachObject(entity);
Doing the same in Mogre (with the Direct3D 9 renderer, though) gets the model to render. So do I need to load the shaders explicitly somehow?

Btw, I plan on putting together a little WinRT starter kit package for Ogre, but wanted to at least verify that it can render a mesh to the screen before. If anyone wants to give it a whirl: http://www.nuclex.org/temporary/Ogre-Wi ... inished.7z (28 MiB). Just unpack, open solution in Visual Studio 11 under Windows 8, press F5 :)

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 27, 2012 9:18 am
by Cygon
I thought that maybe Ogre's runtime shader system might be what's missing, so I enabled it and added the RTShaderLib to my directory.

Now it appears that the shader library is not suitable for the D3D11 renderer:

Cannot assemble D3D11 high-level shader 2652689661_FS Errors:
FFPLib_Texturing.hlsl(197,6-16): error X3523: DX9-style intrinsics are disabled when not in dx9 compatibility mode.


which would be this function:

Code: Select all

void FFP_SampleTexture(in sampler2D s, 
				   in float2 f,
				   out float4 t)
{
	t = tex2D(s, f);
}
I wonder how the sample browser does it.

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Mar 27, 2012 1:09 pm
by Cygon
Okay, maybe I'm one step further. Or maybe not.

I forced the mBackwardsCompatibility flag to true and now the D3DCompiler does successfully compile the RTShaderLib HLSL scripts. After that, Ogre falls flat on its nose again with the earlier error message (need to have both vertex and fragment/pixel shader assigned).

Thus, I set out to get the sample browser running with my own binaries (I'm not using CMake, though I probably really should take a look at it by now :mrgreen:) and that at least worked:

Image

So I guess there's something my minimal application is still doing wrong.

Anyone willing to take a look at my code? OgreTest.cpp
  • I verified that the RTShaderLib directory is in the right place (see above, I even ran into some errors when these shaders were compiled at first)
  • The mesh can be loaded and if the camera looks the other way, the application runs, but as soon as it comes into view, up comes the exception telling me that I need to have both vertex and fragment shaders assigned)
  • As far as I understand it, the RTShaderSystem will hook itself into the mesh render call and emulate the FFP shaders. Except that it doesn't in my example
  • Unless I'm mistaken, the SampleBrowser's GUI also requires the RTShaderSystem (assuming the dialogs are drawn as primitives, not blitted as bitmaps), so I concluded that the SampleBrowser would be able to draw meshes, too. I hope that conclusion was right.

Re: Ogre`s Windows 8 Metro Style port

Posted: Thu Mar 29, 2012 10:28 am
by Eugene
You need RTSS system, that would generate missing shaders for you. Look at pieces of code under #define USE_RTSHADER_SYSTEM in SampleBrowser to figure out how to setup and use it.
All shaders coming from RTSS are already with mBackwardsCompatibility flags, look at commit with title "RTShaderSystem: enable backward compatibility for hlsl shaders with profile 4.0".

P.S.
I looked at your code and found concerns about d3dcompiler_44.dll. Actually, VS11 Beta Ultimate has binaries for ARM here: "C:\Program Files (x86)\Windows Kits\8.0\Redist\D3D\arm\d3dcompiler_44.dll", but this dll is not Metro-clean (for all architectures), and therefore should be avoided to pass Store validation process. I wrote about this above.

Re: Ogre`s Windows 8 Metro Style port

Posted: Thu Mar 29, 2012 2:18 pm
by Cygon
Eugene wrote:You need RTSS system, that would generate missing shaders for you. Look at pieces of code under #define USE_RTSHADER_SYSTEM in SampleBrowser to figure out how to setup and use it.
That's what I've been doing all along. In the end, what was missing from the example code I posted was the listener in Ogre's MaterialManager (which in the SampleBrowser was buried beneath some long-winded piece of code searching the shader library directory). Got it working now!
Eugene wrote:All shaders coming from RTSS are already with mBackwardsCompatibility flags, look at commit with title "RTShaderSystem: enable backward compatibility for hlsl shaders with profile 4.0".
Yes, I've seen that that commit and pasted the change into my sources manually.

That was my original problem: if I downloaded your commit titled "WinRT compatibility: SampleBrowserWinRT" I got the WinRT-patched Ogre sources. But if I instead downloaded your later commits, eg. the one titled "WinRT compatibility: allow external access to ID3D11Device" I got those changes but the Ogre sources were back to normal.

It's probably just me not understanding Mercurial and/or Bitbucket. That's why I originally sent you a PM a few days ago were you instructed me to "pull new branch, rebase your changes on top of it and strip old branches that are not on bitbucket anymore" -- but I'm too clueless regarding Mercurial to follow those instructions and didn't want to bother you any further. I'll pick up on Mercurial eventually, for now I'm happy to have your WinRT patches working even if I made it a bit harder for myself :)
Eugene wrote:P.S. I looked at your code and found concerns about d3dcompiler_44.dll. Actually, VS11 Beta Ultimate has binaries for ARM here: "C:\Program Files (x86)\Windows Kits\8.0\Redist\D3D\arm\d3dcompiler_44.dll", but this dll is not Metro-clean (for all architectures), and therefore should be avoided to pass Store validation process. I wrote about this above.
I read that (but took the DLLs from 'C:\Program Files\Windows Kits\8.0\bin' where the ARM binaries were missing - thanks for giving me the proper one ;)).

As far as I understand it, that means we either hope for Microsoft to provide a WinRT/Metro-clean HLSL compiler, or hack the RTShaderGenerator to use precompiled/cached shaders only or design our applications to use only manually written shaders.

Re: Ogre`s Windows 8 Metro Style port

Posted: Thu Mar 29, 2012 8:56 pm
by Eugene
Cygon wrote: As far as I understand it, that means we either hope for Microsoft to provide a WinRT/Metro-clean HLSL compiler, or hack the RTShaderGenerator to use precompiled/cached shaders only or design our applications to use only manually written shaders.
Even with our own precompiled shaders we need shader reflection interface from d3dcompiler_xx.dll to create input layout to bind vertex and constant buffers to shader. So, if MS would not provide this interface we need to cache this info too or reverse engeneer reflection info. It seems that format is very straightforward, and Wine teem already did this.