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

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Post Reply
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre`s Windows 8 Metro Style port

Post by Kojack »

For the second question, AFAIK ARMs are little-endian too, so byteswap functions are necessary.
Some ARM chips are little endian, some are big endian. The Cortex A8 (the one popular in a lot of phones) is little endian for instructions, but can dynamically switch between big and little endian for data (the SETEND assembly instruction controls it).
User avatar
Cygon
Halfling
Posts: 70
Joined: Thu Nov 07, 2002 9:36 pm
Location: Germany
x 5
Contact:

Re: Ogre`s Windows 8 Metro Style port

Post by Cygon »

Eugene wrote:First issue can be corrected by using "internal" and "protected internal" access specifiers.
You're repeating what I said :)
Kojack wrote:
For the second question, AFAIK ARMs are little-endian too, so byteswap functions are necessary.
Some ARM chips are little endian, some are big endian. The Cortex A8 (the one popular in a lot of phones) is little endian for instructions, but can dynamically switch between big and little endian for data (the SETEND assembly instruction controls it).
I didn't know ARMs supported little endian, too (though I wonder how all those additional circuits mix up with the low power requirements?).

The Xbox 360 has a switchable PowerPC CPU as well and runs it in big endian mode. Anyway, some googling shows that Windows Phone 7 was most likely a little endian platform. And there's a photo of some Microsoft developer running Windows 8 on his Windows Phone.

This points to Windows 8 on ARM using little endian. What a relief, I thought ARMs were big endian exclusively :)
User avatar
Eugene
OGRE Team Member
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

Post by Eugene »

Windows NT kernel has assumption that it would work on little-endian processor. Even when PowerPC port was done, special version of the chip was made that while still being actually big endian (64bit memory accesses were simple big endian) but for smaller sizes address was XOR-ed by the chip with 0x4 for 32bit, 0x6 for 16bit and with 0x7 for 8bit accesses, that together with strict data alignment rules of RISC architectures and constant 32bit instruction length make the processor act as a little endian to software. But in physical memory bytes in each 8byte chunk are reversed as compared to normal little-endian layout, and all other devices that can access memory without processor can discover this fact. To fix this, PowerPC motherboards that were intended for use with WindowsNT had special translator between CPU+memory in this strange mode and usual little-endian PCI bus+the rest of the system, so that all drivers for miscelaneous PCI devices need not to know about this.

So knowing this I was sure that ARM port of Windows 8 would be little-endian.

P.S. From wikipedia, ARMs were initially little-endian and still little endian by default.

P.P.S Interesting post about this from Microsoft insider
http://blogs.msdn.com/b/larryosterman/a ... 26334.aspx
ergo1
Gnoblar
Posts: 18
Joined: Sun Jan 22, 2012 12:05 am

Re: Ogre`s Windows 8 Metro Style port

Post by ergo1 »

I'm following along here, but crashed and burned when I got to the cmake step:

Code: Select all

CMake Error: CMake was unable to find a build program corresponding to "Visual Studio 11".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: Could not find cmake module file:E:/W8/BUILDS/ogrewinrt/CMakeFiles/CMakeCCompiler.cmake
CMake Error: Could not find cmake module file:E:/W8/BUILDS/ogrewinrt/CMakeFiles/CMakeCXXCompiler.cmake
Configuring incomplete, errors occurred!
Any hints on how to get around this?

( Using cmake 2.8.8 , win8rp build 8400, VS2012 express RC )
User avatar
Cygon
Halfling
Posts: 70
Joined: Thu Nov 07, 2002 9:36 pm
Location: Germany
x 5
Contact:

Re: Ogre`s Windows 8 Metro Style port

Post by Cygon »

Visual Studio went through some changes in the Release Preview, maybe CMake is only able to find Visual Studio 11 from the Consumer Preview, but not Visual Studio 2012 RC from the Release Preview?

I'm not using CMake myself, so I can't say whether the latest development builds work, but if a set of ready-to-compile Visual Studio 2012 RC projects help you, I have put together my own little Ogre 1.8.0 SDK for WinRT:

http://blog.nuclex-games.com/2012/06/og ... nrt-metro/ (pick the "sources-and-patches" package for the Visual Studio projects)
Professional C++ and .NET developer trying to break into indie game development.
Follow my progress: http://blog.nuclex-games.com/ or Twitter - Topics: Ogre3D, Blender, game architecture tips & code snippets.
azenren
Gnoblar
Posts: 2
Joined: Thu Jun 07, 2012 8:05 pm

Re: Ogre`s Windows 8 Metro Style port

Post by azenren »

Cygon wrote:
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.
What do you mean by use only manually written shaders? How could I do that in my app to get around this issue and pass MS app certification?
User avatar
Eugene
OGRE Team Member
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

Post by Eugene »

azenren wrote:
Cygon wrote: As far as I understand it, <...> 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.
What do you mean by use only manually written shaders? How could I do that in my app to get around this issue and pass MS app certification?
I think it exactly what MS did in their samples: shaders are all known at compilation time, and corresponded vertex and constants buffers are declared as C++ structs, as well as corresponded input/cb layout descriptions are declared in code as C++ arrays instead of being constructed at runtime using the information obtained via reflection mechanism.
User avatar
Cygon
Halfling
Posts: 70
Joined: Thu Nov 07, 2002 9:36 pm
Location: Germany
x 5
Contact:

Re: Ogre`s Windows 8 Metro Style port

Post by Cygon »

Do you have any workaround for the D3DCompiler_*.dll issue planned?

I have only taken a brief look at the d3d render system code, but if the problematic methods are D3DCompile() and D3DReflect, would it be feasible to save the data usually obtained by D3DReflect() by hand?

The types I see used are D3D11_SHADER_DESC (very simple, just a big structure of integers), D3D11_SIGNATURE_PARAMETER_DESCs and ID3D11ShaderReflectionConstantBuffer which looks a bit complicated since it forms a tree of various COM objects (but maybe the entire tree isn't needed, the code seems to only be interested in the names of the variables stored in it). It looks doble

Another point of interest would be if two different RenderSystem_Direct3D11.dlls would be required (one for development to fill the shader and shader metadata caches, another one to ship) or if it will pass the Windows App Certification already if the method is not called (and maybe /DELAYLOAD:D3DCompiler_45.dll added to the linker options). But that's just details :)
User avatar
Eugene
OGRE Team Member
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

Post by Eugene »

Cygon wrote:Do you have any workaround for the D3DCompiler_*.dll issue planned?
I still hope that MS would allow shader reflection in some way. Therefore I postponed this problem and work on other parts of my application. If MS decided don`t do this work for me, than may be somebody else do it. And as the last option I will reimplement reflection by myself. I already read such implementation in Wine, and it looks very straightforward, with some caveats to support older formats from older d3dcompiler.dll versions. But I`ll do this only when it would be unavoidable.
User avatar
Eugene
OGRE Team Member
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

Post by Eugene »

I updated http://bitbucket.org/eugene_gff/ogre-winrt repository for Windows 8 Release Preview (build 8400). Also patches were relocated on top of v1-9 Ogre`s branch.
User avatar
Eugene
OGRE Team Member
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

Post by Eugene »

ergo1 wrote:I'm following along here, but crashed and burned when I got to the cmake step:

Code: Select all

CMake Error: CMake was unable to find a build program corresponding to "Visual Studio 11".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: Could not find cmake module file:E:/W8/BUILDS/ogrewinrt/CMakeFiles/CMakeCCompiler.cmake
CMake Error: Could not find cmake module file:E:/W8/BUILDS/ogrewinrt/CMakeFiles/CMakeCXXCompiler.cmake
Configuring incomplete, errors occurred!
Any hints on how to get around this?

( Using cmake 2.8.8 , win8rp build 8400, VS2012 express RC )
I can not repeat this problem using full version of VS2012. Probably VS2012 Express is not supported by CMake.
User avatar
Cygon
Halfling
Posts: 70
Joined: Thu Nov 07, 2002 9:36 pm
Location: Germany
x 5
Contact:

Re: Ogre`s Windows 8 Metro Style port

Post by Cygon »

Eugene wrote:
Cygon wrote:Do you have any workaround for the D3DCompiler_*.dll issue planned?
I still hope that MS would allow shader reflection in some way. Therefore I postponed this problem and work on other parts of my application. If MS decided don`t do this work for me, than may be somebody else do it. And as the last option I will reimplement reflection by myself. I already read such implementation in Wine, and it looks very straightforward, with some caveats to support older formats from older d3dcompiler.dll versions. But I`ll do this only when it would be unavoidable.
I haven't decided yet whether I will use Ogre or roll my own limited set of graphics routines for my game, but I did write my own replacement for D3DReflect().
  • This is an implementation from scratch without looking at the Wine sources (because I wasn't sure if my code would otherwise be considered a derivative work under the GPL license)
  • It is not a drop-in replacement for D3DReflect() because it translates the data into my own structures that do not rely on the DirectX SDK headers
  • If you or anyone else from the Ogre team finds this code useful in any way, feel free to take it with no strings (or licenses) attached
Headers: https://devel.nuclex.org/framework/brow ... rospection
Sources: https://devel.nuclex.org/framework/brow ... rospection
(the meat is in HlslShaderReflector.cpp, HlslInputSignatureSerializer.cpp and HlslResourceDefinitionSerializer.cpp)

In case I decide to use Ogre (and your Metro port ;)) I'd be willing to integrate this into Ogre's RenderSystem_Direct3D11 myself. I'll check back when I have made a decision!

By the way, when I did my quick check of the Ogre sources, I sketched out a list of the structures returned by D3DReflect() that Ogre accesses. Maybe it's useful:

Code: Select all

D3DReflect()
  ID3D11ShaderReflection
    ::GetDesc()
      D3D11_SHADER_DESC
        .InputParameters
        .ConstantBuffers

    ::GetInputParameterDesc()
      D3D11_SIGNATURE_PARAMETER_DESC
        .SemanticName,
        .SemanticIndex,
        .Register,
        .SystemValueType,
        .ComponentType,
        .Mask,
        .ReadWriteMask,
        .Stream,
        .MinPrecision

    ::GetConstantBufferByIndex()
      ID3D11ShaderReflectionConstantBuffer
        ::GetDesc()
          D3D11_SHADER_BUFFER_DESC
            .Name,
            .Type,
            .Variables,
            .Size,
            .Flags
        ::GetVariableByIndex()
          ID3D11ShaderReflectionVariable
            ::GetDesc()
              D3D11_SHADER_VARIABLE_DESC
                .Name,
                .StartOffset,
                .Size,
                .Flags,
                .DefaultValue,
                .StartTexture,
                .TextureSize,
                .StartSampler,
                .SamplerSize
User avatar
Eugene
OGRE Team Member
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

Post by Eugene »

Cygon wrote:I did write my own replacement for D3DReflect().
  • This is an implementation from scratch without looking at the Wine sources (because I wasn't sure if my code would otherwise be considered a derivative work under the GPL license)
  • It is not a drop-in replacement for D3DReflect() because it translates the data into my own structures that do not rely on the DirectX SDK headers
  • If you or anyone else from the Ogre team finds this code useful in any way, feel free to take it with no strings (or licenses) attached
Headers: https://devel.nuclex.org/framework/brow ... rospection
Sources: https://devel.nuclex.org/framework/brow ... rospection
(the meat is in HlslShaderReflector.cpp, HlslInputSignatureSerializer.cpp and HlslResourceDefinitionSerializer.cpp)
It`s awesome, kudos to you :) !

I have some questions:
1. Why did you decide to use your own structures instead of Direct3D11? AFAIK they are not under #ifndefs for WinRT and can not be catched by validation tool, only original D3DCompile_XX.dll can not pass validation.
2. If you have bitbucket account I can grant the modification rights to winrt branch to you.

With best regards,
Eugene Golushkov
User avatar
Cygon
Halfling
Posts: 70
Joined: Thu Nov 07, 2002 9:36 pm
Location: Germany
x 5
Contact:

Re: Ogre`s Windows 8 Metro Style port

Post by Cygon »

Eugene wrote:1. Why did you decide to use your own structures instead of Direct3D11? AFAIK they are not under #ifndefs for WinRT and can not be catched by validation tool, only original D3DCompile_XX.dll can not pass validation.
It's part of a little graphics library experiment. Instead of deriving graphics API-specific graphics classes from API-neutral ones like in Ogre, the API-specific classes act as observers to the neutral ones. The public headers are pure ISO C++ and avoid all platform specific dependencies (like the DirectX SDK or Windows.h), thus the custom structures.

If I port the code to Ogre, I'd use the D3D11 types, of course :)
Eugene wrote:2. If you have bitbucket account I can grant the modification rights to winrt branch to you.
I'm still undecided whether I'm going to use Ogre for my game. If I chose to go with Ogre, I'll come back to your offer!
User avatar
Eugene
OGRE Team Member
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

Post by Eugene »

So, Windows 8 released - August 1, 2012!
http://blogs.msdn.com/b/b8/archive/2012 ... -2012.aspx

And Ogre still does not officially support it - nor WinRT mode nor even plain old Win32 mode with Windows 8 SDK. What a shame!
User avatar
Wolfmanfx
OGRE Team Member
OGRE Team Member
Posts: 1525
Joined: Fri Feb 03, 2006 10:37 pm
Location: Austria - Leoben
x 99
Contact:

Re: Ogre`s Windows 8 Metro Style port

Post by Wolfmanfx »

:(
Is your app released inside the win8 store?
User avatar
Eugene
OGRE Team Member
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

Post by Eugene »

Wolfmanfx wrote::(
Is your app released inside the win8 store?
Not yet. I have 3 months before Win8 would be released to general public to get it ready. But now I have solid foundation in released version of Windows 8, and still can not say this about Ogre.
ergo1
Gnoblar
Posts: 18
Joined: Sun Jan 22, 2012 12:05 am

Re: Ogre`s Windows 8 Metro Style port

Post by ergo1 »

Eugene wrote:
ergo1 wrote:I'm following along here, but crashed and burned when I got to the cmake step:

Code: Select all

CMake Error: CMake was unable to find a build program corresponding to "Visual Studio 11".  CMAKE_MAKE_PROGRAM is not set.  You probably need to select a different build tool.
CMake Error: Could not find cmake module file:E:/W8/BUILDS/ogrewinrt/CMakeFiles/CMakeCCompiler.cmake
CMake Error: Could not find cmake module file:E:/W8/BUILDS/ogrewinrt/CMakeFiles/CMakeCXXCompiler.cmake
Configuring incomplete, errors occurred!
Any hints on how to get around this?

( Using cmake 2.8.8 , win8rp build 8400, VS2012 express RC )
I can not repeat this problem using full version of VS2012. Probably VS2012 Express is not supported by CMake.
Yes, absolutely confirmed ... VS2012 express and CMake don't yet play well together!


Today I was finally able to build samplebrowser on Win8 build 8400:
used Cmake 2.8.9rc3 and VS2012 Pro to build from Ogre v1-9 (along with your dependencies kit) :D

One thing I notice is that running the Metro app, the FPS of the various samples is limited to 20-30 frames per second.
If I run the win7-built (VS9) samplebrowser here in win8, (using the DX9 rendering) I'm getting 2000-3000 FPS (Nvidia GTX460M) - roughly 100x better performance
User avatar
Klaim
Old One
Posts: 2565
Joined: Sun Sep 11, 2005 1:04 am
Location: Paris, France
x 56
Contact:

Re: Ogre`s Windows 8 Metro Style port

Post by Klaim »

I'm using VS2012 RC Pro on Win 7 and it works almost correctly. Looks like indeed it's the express version that is a problem.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 534

Re: Ogre`s Windows 8 Metro Style port

Post by Kojack »

So, Windows 8 released - August 1, 2012!
Cool. Checking MSDNAA website... I can get it for free on the 15th of august.
Well, not that I particularly want to run it, but at some point I know my college will suddenly roll it out without warning me, so I need to get used to it and evaluate how compatible our software is with it.
User avatar
Cygon
Halfling
Posts: 70
Joined: Thu Nov 07, 2002 9:36 pm
Location: Germany
x 5
Contact:

Re: Ogre`s Windows 8 Metro Style port

Post by Cygon »

Eugene wrote:It`s awesome, kudos to you :) !

I have some questions:
1. Why did you decide to use your own structures instead of Direct3D11? AFAIK they are not under #ifndefs for WinRT and can not be catched by validation tool, only original D3DCompile_XX.dll can not pass validation.
2. If you have bitbucket account I can grant the modification rights to winrt branch to you.

With best regards,
Eugene Golushkov
I finally made some progress with my game and I decided to use Ogre now. If you're still interested, I'll add my D3DReflect() replacement to your Ogre fork on BitBucket.

Currently reading the Mercurial docs (I never used a distributed VCS before) - so far I've signed up for a BitBucket account (username is "cygon"), installed TortoiseHg, cloned your Ogre-WinRT repository and I'm now trying to set up my BitBucket SSH keys in TortoiseHg.
User avatar
Eugene
OGRE Team Member
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

Post by Eugene »

Cygon wrote:I finally made some progress with my game and I decided to use Ogre now. If you're still interested, I'll add my D3DReflect() replacement to your Ogre fork on BitBucket.

Currently reading the Mercurial docs (I never used a distributed VCS before) - so far I've signed up for a BitBucket account (username is "cygon"), installed TortoiseHg, cloned your Ogre-WinRT repository and I'm now trying to set up my BitBucket SSH keys in TortoiseHg.
I use https:// protocol instead of SSH to push to Mercurial - without all those problems with private keys.
You have modification rights to the winrt branch now. I don`t like fragmentation, but here it seems unavoidable.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Ogre`s Windows 8 Metro Style port

Post by Assaf Raman »

Eugene and Cygon, can you sign the contributor forum and send it back to me - so we can use it in the main trunk?

Cygon - can you change the license for your reflect code to be the same as OGRE - else - it will be hard for me to integrate it to the official trunk. BTW: If we save the binary version of the shader, why not save the D3DReflect results as well? Shouldn't be hard at all and will be better performance and more reliable then the code you wrote, right?

Eugene - What is the status with my summer student project, is all your code merged into his repo?
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Ogre`s Windows 8 Metro Style port

Post by Assaf Raman »

I had a look at the microcode cache code, it will not be hard to change it to save also the shader reflection, and I like that solution much better then the one Cygon created.

All we need to do is write code to serialize all the relevant reflection classes.
Watch out for my OGRE related tweets here.
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Re: Ogre`s Windows 8 Metro Style port

Post by Assaf Raman »

I am trying now to get the WinRT OGRE version compiled and running on my computer, if I do - I will fix the reflection code.
Watch out for my OGRE related tweets here.
Post Reply