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.

Raise a connect issue. That way it will bring it to there attention and they may realise they should include it.

0 x

There are 10 types of people in the world: Those who understand binary, and those who don't...

I've encountered some crashes which I tracked down to the way the window handle is passed to the Direct3D 11 renderer.

My Windows::UI::Core::CoreWindow had an address of 0x0000009b0fd202c0. When this was passed through the NameValuePairList, 0x000000000fd202c0 came out the other end, causing an access violation when the Direct3D 11 code tried to cast it back into a managed pointer. It worked before, so apparently the window is in most cases given a lower address.

I think the best solution would be to extend OgreStringConverter to be able to convert between pointers and strings so pointers can be safely converted to and from.

You compiled Ogre in x64 mode without problems and it almost works? Thats awesome, I did not expected this, partially because Ogre casts pointers to integers and vice versa, like HWNDs and CoreWindows and many other types for miscelanious build platforms. Therefore I modeled passing CoreWindow with the same assumptions as HWNDs, and that needs to be fixed.

Fixing OgreStringConverter is very delicate thing as all overloaded functions should compile on so many different platforms. Probably I can do this and test on Windows (VC++ x86, VC++x64) and MacOSX (Apple gcc 4.2 x86 and x64).

Hmm, that's not good. We shouldn't be casting pointers to ints.
I just did a quick check, there's (at least) 6 places where an unsigned int (parsed from a string) is cast as a hwnd (which is 64 bit on x64).
It's in code that only deals with user created windows, if you let ogre handle the window creation it shouldn't be a problem. But there's probably other problems like this in there.

In fact there's no 64 bit support in the string converter code at all. There's int and long, but both are 32 bit on x84. There should be a long long (or whatever the preferred type name is these days) method to parse strings into 64 bit.

I think I'll make a new thread soon for 64bit issues, I don't want to derail this thread.

I'd prefer to add a StringConverter::ParsePointer() and StringConverter::ToPointer() method (maybe in addition to the 64 bit int methods).

Reasoning: Using a 64 bit int method would again be casting pointers to ints (maybe safely so, but why do it at all, it's a code smell). It would also move the burden of deciding which method to use to each place that needs to pass pointers (including the user himself). With a native pointer method in the StrongConverter, the method would automatically adhere to the target platform's pointer size.

If Eugene has the resources to add and test this on MacOS for endianness issues, that would be wonderful

Cygon wrote:I'd prefer to add a StringConverter::ParsePointer() and StringConverter::ToPointer() method (maybe in addition to the 64 bit int methods).

Reasoning: Using a 64 bit int method would again be casting pointers to ints (maybe safely so, but why do it at all, it's a code smell). It would also move the burden of deciding which method to use to each place that needs to pass pointers (including the user himself). With a native pointer method in the StrongConverter, the method would automatically adhere to the target platform's pointer size.

If Eugene has the resources to add and test this on MacOS for endianness issues, that would be wonderful

Usually there are integer type intptr_t with size large enough to hold any pointer without truncation. It`s typedef, therefore automatically supported if some class has function with overloads for all integer type sizes. It`s already used in Ogre. Casting to it don`t smell, as it is intended for this purpose

Eugene wrote:Usually there are integer type intptr_t with size large enough to hold any pointer without truncation. It`s typedef, therefore automatically supported if some class has function with overloads for all integer type sizes. It`s already used in Ogre. Casting to it don`t smell, as it is intended for this purpose

That's what I was saying. I was advocating against casting (Something *) to (long long).

The CreateThread() emulation code is based on Shawn Hargreaves' CreateThread for Windows 8 Metro. Obtaining the number of CPUs required a call to an asynchronous method, so to avoid blocking in the UI thread, I fire the call statically during program launch so the result is already there when it's required and can be returned without blocking.

nice work .i spent 2 hours getting the the lib and dependencies setup and it compiled pretty nicely without issues .but when i start the WinRT browser in either the local debugger or the simulator it fails with the error below

look like that step is required after all ,but an additional attribute need to be set on all the dll projects is MetroStyle App Support = Yes under project properties->general otherwise the reference will not be included.

now the app crashes at startup but in a different place,debugger shows mCursorLayer is null

ahmedismaiel wrote:look like that step is required after all ,but an additional attribute need to be set on all the dll projects is MetroStyle App Support = Yes under project properties->general otherwise the reference will not be included.

This is done automatically by right version of CMake. Probably you uses wrong one, and needs to do this manually.

About crash: I never had such problem, and only can suppose, that problem is with resources. Ensure, that packaged application has subfolder Media with Ogre`s resources and/or check Ogre`s logs. Resources should be packaged automatically too, but who knows.

Thanks guys ,i tried your Cygon project and it is working (pretty bummed about cg not working, our game Stuntrally uses it everywhere http://code.google.com/p/vdrift-ogre/ )
i'm still interested in getting it straight from a repo as i have alot of custom changes to d3d11 plugin that didn't go to trunk yet .i started over with a new nightly build of cmake and it got the right attributes this time(metro support and unicode) . compiled but running give me an empty black screen (with the winrt xaml i get the xaml overlay ontop of the blakc screen). when i enabled catching all exceptions i see it is complaining about BlurH_ps40.hlsl missing but not sure if the app was meant to continue without it .i'm assuming the file is generated automatically ,but i cann't confirm until i see the ogre logs ,where are they ?

another thing was the media folder is not included in the browser WinRT project ,when i did "include in project" it doesn't seem to add all the files and when i added them manually it recognized the hlsl files as buildable files and caused the build to fail and have to exclude then from build manually .any ideas on how to add the whole directory recursively as a resource to the appx package in an easy way?

ahmedismaiel wrote:i started over with a new nightly build of cmake and it got the right attributes this time(metro support and unicode) . compiled but running give me an empty black screen (with the winrt xaml i get the xaml overlay ontop of the blakc screen). when i enabled catching all exceptions i see it is complaining about BlurH_ps40.hlsl missing but not sure if the app was meant to continue without it .i'm assuming the file is generated automatically ,but i cann't confirm until i see the ogre logs ,where are they ?

another thing was the media folder is not included in the browser WinRT project ,when i did "include in project" it doesn't seem to add all the files and when i added them manually it recognized the hlsl files as buildable files and caused the build to fail and have to exclude then from build manually .any ideas on how to add the whole directory recursively as a resource to the appx package in an easy way?

1) There are some strange problem with Direct3D11 Render System that causes black screen on Samsung Slate PC (aka development machine from \\build conference). I can not repeat this problem on ATI and NVidia cards, only on Intel HD3000, and problem is not with the failed hardware as simple 3D samples runs without problems. This problem is not WinRT port specific, but can be reproduced with Win32 Ogre too. I still can not trace it, and decide to postpone till graphic debugger in VS would be fixed so I could inspect pipeline states.

2) 7 or 8 missing resources including BlurH_ps40.hlsl are normal, and while prevent some samples from working it would not affect Ogre`s ability to run.

3) Media folder is symlinked into project directory by custom build script, and output of this script is marked as Content, so it would be picked up automatically. You should not add it to the project manually, as there are too many files and IDE became slow and would try to compile shaders and so on, but if you really want, you can mark every *.hlsl file as Content to prevent compilation.

sounds good .i was testing with my laptop which have an intel HD card ,will try on my nvidia machine and hopefully things will be better.can you point me to which part of the build script that does the magic to add the all the media ?

ahmedismaiel wrote:sounds good .i was testing with my laptop which have an intel HD card ,will try on my nvidia machine and hopefully things will be better.can you point me to which part of the build script that does the magic to add the all the media ?

◦API CreateDirectoryA in kernel32.dll is not supported for this application type. SampleBrowserWinRT.exe calls this API.
◦API GetFileAttributesExA in kernel32.dll is not supported for this application type. SampleBrowserWinRT.exe calls this API.

so ,what are the options to load a precompiled shader using fxc in ogre so that i don't take a dependency on d3dcompiler_44.dll ?

ahmedismaiel wrote:i started over with a new nightly build of cmake and it got the right attributes this time(metro support and unicode) . compiled but running give me an empty black screen (with the winrt xaml i get the xaml overlay ontop of the blakc screen).

There are some strange problem with Direct3D11 Render System that causes black screen on Samsung Slate PC (aka development machine from \\build conference). I can not repeat this problem on ATI and NVidia cards, only on Intel HD3000, and problem is not with the failed hardware as simple 3D samples runs without problems. This problem is not WinRT port specific, but can be reproduced with Win32 Ogre too. I still can not trace it, and decide to postpone till graphic debugger in VS would be fixed so I could inspect pipeline states.

I found the reason and workaround for this problem. It`s buggy driver "Intel(R) HD Graphics Family (Microsoft Corporation - WDDM 1.2)", that draw nothing if all three conditions are met
1) vertex shader main function calls another user supplied function
2) D3DCOMPILE_SKIP_OPTIMIZATION is specified
3) D3DCOMPILE_DEBUG is specified

As RTSS rely on function calls in generated shaders you can remove D3DCOMPILE_SKIP_OPTIMIZATION or D3DCOMPILE_DEBUG flag to workaround this problem. I think it`s problem with debug information, as I was able to create simple shader and compile it via fxc.exe with one set of options that causes problem and another that works like a charm, and disassembler listing was identical up to chosen registers, #line directives and comments.

After switching to the Release Preview, I noticed that there have been some changes in Visual Studio 2012 RC which may affect your Ogre Metro port as well. One issue that stumped me for a while was that C++/CX ref classes may no longer have public or protected members that reference ISO C++ types. All ISO C++ methods and fields have to be declared internal or private now.

By the way, whilst working with your 2012.02.27 sources, I noticed that you had replaced a htons() or something with a fixed _byteswap_ushort() call. I don't have an ARM device to test it with myself (yet), but I believe that should be a no-op if _M_ARM is defined. If it's alright, I'll provide a patch once I start updating my Ogre sources to your latest trunk.

Cygon wrote:After switching to the Release Preview, I noticed that there have been some changes in Visual Studio 2012 RC which may affect your Ogre Metro port as well. One issue that stumped me for a while was that C++/CX ref classes may no longer have public or protected members that reference ISO C++ types. All ISO C++ methods and fields have to be declared internal or private now.

By the way, whilst working with your 2012.02.27 sources, I noticed that you had replaced a htons() or something with a fixed _byteswap_ushort() call. I don't have an ARM device to test it with myself (yet), but I believe that should be a no-op if _M_ARM is defined. If it's alright, I'll provide a patch once I start updating my Ogre sources to your latest trunk.

First issue can be corrected by using "internal" and "protected internal" access specifiers.
For the second question, AFAIK ARMs are little-endian too, so byteswap functions are necessary.