Page 2 of 8

Re: Ogre`s Windows 8 Metro Style port

Posted: Fri Mar 30, 2012 11:34 am
by Zonder
Eugene wrote:
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.

Re: Ogre`s Windows 8 Metro Style port

Posted: Mon Apr 02, 2012 12:35 pm
by Eugene
WinRT related changes were rebased on top of current v1.8 branch

Re: Ogre`s Windows 8 Metro Style port

Posted: Fri Apr 06, 2012 1:45 pm
by loath
awesome work eugene.

this will be a huge benefit to the ogre community moving forward.

did you have any trouble using other libraries with windows 8 / metro? for example, boost, physx, etc?

Re: Ogre`s Windows 8 Metro Style port

Posted: Fri Apr 06, 2012 2:44 pm
by Eugene
loath wrote:did you have any trouble using other libraries with windows 8 / metro? for example, boost, physx, etc?
Almost all libraries would need some porting and at least recompilation.

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Apr 10, 2012 5:52 pm
by Cygon
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.

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue Apr 10, 2012 11:31 pm
by Eugene
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).

Re: Ogre`s Windows 8 Metro Style port

Posted: Wed Apr 11, 2012 9:09 am
by Kojack
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. :)

Re: Ogre`s Windows 8 Metro Style port

Posted: Wed Apr 11, 2012 10:35 am
by Cygon
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 :)

Re: Ogre`s Windows 8 Metro Style port

Posted: Wed Apr 11, 2012 1:10 pm
by Eugene
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 :)

Re: Ogre`s Windows 8 Metro Style port

Posted: Wed Apr 11, 2012 1:28 pm
by Cygon
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).

Re: Ogre`s Windows 8 Metro Style port

Posted: Thu Apr 12, 2012 2:19 pm
by Cygon
I'm not sure if your builds already support multithreading (couldn't find anything about Poco, TBB or Boost.Threads in the repo).

If you can use it, here's a patch that will allow Boost.Threads (of Boost 1.49.0) to compile under WinRT:
http://www.nuclex.org/temporary/boost-1 ... inrt.patch

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.

Re: Ogre`s Windows 8 Metro Style port

Posted: Fri Apr 13, 2012 5:36 pm
by Eugene
Direct3D/Xaml interoperability done. As usual, sources are at http://bitbucket.org/eugene_gff/ogre-winrt

Re: Ogre`s Windows 8 Metro Style port

Posted: Sat Apr 14, 2012 10:08 pm
by ahmedismaiel
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

Code: Select all

The program '[7028] SampleBrowserWinRTXaml.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
any idea what dll would it be and how to add it back ?


i also noticed i didn't need step 6 from BuildingOgreWinRT.txt ,was that required before?

Code: Select all

6. In WinRT mode VS11 by default uses precompiled headers, and CMake can not yet prevent this.
So, open OGRE.sln in Visual Studio, select All projects except ALL_BUILD,INSTALL,PACKAGE,OgreMain 
than go to "Properties" select "Configuration Properties", than "All Configurations" and under 
"Configuration Properties > C/C++ > Precompiled Headers > Precompiled Header" choose 
"Not Using Precompiled Headers" (TODO: patch CMake for this).

Re: Ogre`s Windows 8 Metro Style port

Posted: Sat Apr 14, 2012 11:12 pm
by ahmedismaiel
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

Unhandled exception at 0x00DCD9CA in SampleBrowserWinRT.exe: 0xC0000005: Access violation reading location 0x00000004.
StackTrace
> SampleBrowserWinRT.exe!OgreBites::SdkTrayManager::showCursor(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & materialName) Line 1883 C++
SampleBrowserWinRT.exe!OgreBites::SampleBrowser::setup() Line 1074 C++
SampleBrowserWinRT.exe!OgreBites::SampleContext::initApp(OgreBites::Sample * initialSample) Line 252 C++
SampleBrowserWinRT.exe!SampleBrowserWinRT::[Windows::ApplicationModel::Core::IFrameworkView]::Run() Line 81 C++
SampleBrowserWinRT.exe!SampleBrowserWinRT::[Windows::ApplicationModel::Core::IFrameworkView]::__abi_Windows_ApplicationModel_Core_IFrameworkView____abi_Run() C++

Re: Ogre`s Windows 8 Metro Style port

Posted: Sun Apr 15, 2012 10:44 am
by Eugene
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.

Re: Ogre`s Windows 8 Metro Style port

Posted: Sun Apr 15, 2012 4:49 pm
by Cygon
If it helps, I packaged Eugene's modifications into my own little SDK plus example application: Ogre 1.8.0 RC for WinRT/Metro.

It doesn't include Eugene's latest additions (Xaml support) yet, but it should work out of the box -- so maybe you can at least use it to compare against your project.

Re: Ogre`s Windows 8 Metro Style port

Posted: Mon Apr 16, 2012 12:13 am
by ahmedismaiel
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?

Re: Ogre`s Windows 8 Metro Style port

Posted: Mon Apr 16, 2012 7:49 am
by Eugene
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.

Re: Ogre`s Windows 8 Metro Style port

Posted: Mon Apr 16, 2012 6:21 pm
by ahmedismaiel
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 ?

Re: Ogre`s Windows 8 Metro Style port

Posted: Mon Apr 16, 2012 7:43 pm
by Eugene
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 ?
SampleBrowserWinRT > Properties > Custom Build Step

Re: Ogre`s Windows 8 Metro Style port

Posted: Wed Apr 18, 2012 6:27 pm
by ahmedismaiel
tried it on my nvidia 570 desktop and it works like a charm ,thanks.
after running the app certifications i noticed that there is 2 that belongs to the app beside all the d3dcompiler one's

Code: Select all

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

Re: Ogre`s Windows 8 Metro Style port

Posted: Tue May 15, 2012 1:32 pm
by Eugene
Eugene wrote:
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.

P.S.
I posted bugreport to Microsoft.

Re: Ogre`s Windows 8 Metro Style port

Posted: Thu May 24, 2012 5:21 pm
by Eugene
WinRT related patches as well as several generic bugfixes were rebased on top of v1.8 branch

Re: Ogre`s Windows 8 Metro Style port

Posted: Mon Jun 11, 2012 12:24 pm
by Cygon
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.

If it helps, I also updated my port of Boost to WinRT (mainly Boost.Thread to enable threading in Ogre): https://devel.nuclex.org/external/unsta ... 2012.patch.

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.

Re: Ogre`s Windows 8 Metro Style port

Posted: Mon Jun 11, 2012 8:41 pm
by Eugene
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.