Ogre`s Windows 8 UI Style port (now commited to OGRE!)
-
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Ogre`s Windows 8 UI Style port (now commited to OGRE!)
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.
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.
You do not have the required permissions to view the files attached to this post.
Last edited by Eugene on Thu Aug 23, 2012 5:29 pm, edited 6 times in total.
-
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
Of course. Here is my original plan:JDX_John wrote:Cool
Could you summarize the main changes you had to make? It looks like you retained existing D3D11 RenderSystem?
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.
-
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
Not yet completed, but issues are minor and I`ll fix them ASAP.lonewolff wrote:Nice one, bro![]()
How does it go with app store certification?
Aforementioned problem with d3dcompiler_44.dll is here too, and it is not so easy to fix.
Last edited by Eugene on Tue Mar 06, 2012 3:25 pm, edited 1 time in total.
-
- Gnome
- Posts: 397
- Joined: Sat Nov 08, 2008 1:59 pm
- x 2
Re: Ogre`s Windows 8 Metro Style port
Do you have any screenshots or anything Eugene?
-
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
Re: Ogre`s Windows 8 Metro Style port
There is a minor issue while Eugene fix this. You have to create Dependencies link to real dependencies directory in cmake generated directory.
-
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
Screenshots are the same for win32 and winrtJDX_John wrote:Do you have any screenshots or anything Eugene?

But if you really want it, here screenshot from simulator
You do not have the required permissions to view the files attached to this post.
-
- Gnome
- Posts: 397
- Joined: Sat Nov 08, 2008 1:59 pm
- x 2
Re: Ogre`s Windows 8 Metro Style port
So does that mean it is not working in Metro? I was hoping to see a nice Ogre tile 

-
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
Re: Ogre`s Windows 8 Metro Style port
"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.
It's only way to show this fact, because Metro apps launch in fullscreen mode.
-
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
Re: Ogre`s Windows 8 Metro Style port
Anyway if you want "nice tile" here it is:
You do not have the required permissions to view the files attached to this post.
-
- Gnome
- Posts: 397
- Joined: Sat Nov 08, 2008 1:59 pm
- x 2
Re: Ogre`s Windows 8 Metro Style port
Oh yes, though we do also have side-by-side mode, yes?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.
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?!
-
- Halfling
- Posts: 59
- Joined: Tue Jan 10, 2006 12:52 pm
- Location: Ukraine
- x 6
Re: Ogre`s Windows 8 Metro Style port
You may also teach a rabbit to smoke if you like 
Check out following link:
http://msdn.microsoft.com/en-us/library ... 65360.aspx

Check out following link:
http://msdn.microsoft.com/en-us/library ... 65360.aspx
-
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
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.
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.
Last edited by Eugene on Sat Mar 10, 2012 11:46 am, edited 1 time in total.
-
- Gnome
- Posts: 397
- Joined: Sat Nov 08, 2008 1:59 pm
- x 2
Re: Ogre`s Windows 8 Metro Style port
Is VS11 a hard requirement for WinRT, or is that just what you were using because it was easiest?
-
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
Hard requirement.JDX_John wrote:Is VS11 a hard requirement for WinRT, or is that just what you were using because it was easiest?
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.
-
- Gnome
- Posts: 397
- Joined: Sat Nov 08, 2008 1:59 pm
- x 2
Re: Ogre`s Windows 8 Metro Style port
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!

Oh well... maybe it'll finally be time to upgrade from VS2008!
-
- OGRE Team Member
- Posts: 4304
- Joined: Mon Feb 04, 2008 2:02 pm
- Location: Germany
- x 136
Re: Ogre`s Windows 8 Metro Style port
Exactly my thoughts as wellJDX_John wrote:UghI'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!

@Eugene: Great work your are doing here! Keep it up!
Ogre Admin [Admin, Dev, PR, Finance, Wiki, etc.] | BasicOgreFramework | AdvancedOgreFramework
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
Don't know what to do in your spare time? Help the Ogre wiki grow! Or squash a bug...
-
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
It`s true, but even those different libraries are in special format - *.winmd files with .NET compatible metadata.JDX_John wrote:UghI'd imagined WinRT API was a bit like a total replacement to Win32 API so we could just point VC++ at different libraries.
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.
-
- OGRE Team Member
- Posts: 1525
- Joined: Fri Feb 03, 2006 10:37 pm
- Location: Austria - Leoben
- x 99
Re: Ogre`s Windows 8 Metro Style port
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?
-
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
Yeah, you missed BuildingOgreWinRT.txt file with description of required manual build stepsWolfmanfx 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?

I fixed one more problem - output folders for built dependencies was not pre-created. Update your dependencies.
-
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
Re: Ogre`s Windows 8 Metro Style port
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 

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:
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


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);
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

-
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
Re: Ogre`s Windows 8 Metro Style port
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:
I wonder how the sample browser does it.
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);
}
-
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
Re: Ogre`s Windows 8 Metro Style port
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
) and that at least worked:

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 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


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.
-
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
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.
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.
-
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
Re: Ogre`s Windows 8 Metro Style port
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: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.
Yes, I've seen that that commit and pasted the change into my sources manually.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".
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

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 oneEugene 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.

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.
-
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
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.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.