Ogre 1.8.0 for WinRT/Metro

37 thoughts to “Ogre 1.8.0 for WinRT/Metro”

1. Hi,

   I downloaded the demo and tried to run it with VS2012 and RP8, but ran into a couple of problems. First, the project still seems to be a VS2010 project – I had to update it on opening it in VS2012, otherwise it had compile issues. Then, on running it, I get: “Unhandled exception at …. (msvcr110.dll) in OgreTest.exe. An invalid parameter was passed to a function that considers invalid parameters fatal.

   I’m going to try compiling the whole src and see if that works, but thought I would let you know.

   Thanks for the new drop!

2. That sounds very strange.

   I just downloaded the -Demo archive, extracted it on my system (Windows 8 RP Build 8400). Double-clicking launched Visual Studio 2012 RC (Professional, 11.0.50522.1 RCREL) with no messages of any kind.

   But I can reproduce the exception you’re seeing. Looks like I broke something at the last minute when fixing the x64 build (which works, only the x86 build blows up)

3. I know what I broke. I added OgreStringConverter::toString(void *) to pass the (HWND) or (CoreWindow ^) into Ogre (since otherwise the handle or pointer would be truncated to 32 bits, causing crashes).

   But I added that method inside some #if..#endif block that only applies on android, ios and 64 bit builds. In 32 bit builds, missing the toString(void *) method, the compiler picks the toString(bool) method, which nicely truncates the pointer to 1 bit :)

   Excuse me while I fix the mess I made here… will upload a new archive tomorrow :-S

4. Ok, thanks…tried the x64, and yes, that works great!!

5. Will your changes be going into the winRT branch of the ogre repo? It would be nice if these made it in.

6. Not sure. So far it’s all in Eugene’s personal repository. I wrote him about the x64 issue in March, but either he forgot or he wants to do his own thing. I’ll definitely try :)

7. Both packages are updated and the x86 targets should work now.

   I also hunted down the last non-metro method in Boost so that everything would now pass the Windows App Certification Kit if it weren’t for d3dcompiler_45.dll and NVidia’s cg.dll (I hope there will be a solution to use precompiled shaders or some other workaorund when Windows 8 releases, otherwise I’ll start hacking Ogre (maybe inventing a dummy shader language which actually is the already compiled shader machine code + some metadata describing the inputs and outputs)

8. Is there no way to get around using d3dcompiler_45.dll in ogre? Ogre won’t load precompiled shaders at all (new to Ogre, so I didn’t know that, I thought there would be a way). Can I generate the assembly-level shader and then use that? Will that still require d3dcompiler? This is important to us, we will need to pass Windows App Cert.

   I’ll try your new drop…thanks for the fast fix!

9. Haha, I’m not exactly an Ogre veteran either.

   I have yet to take a closer look at the design of Ogre’s shader system, but from what I could gather in the Ogre forums, Ogre uses d3dcompiler_45.dll for two purposes:

   • The first usage is compiling HLSL shaders (these are then cached in a directory of your choosing). This could be easily bridged simply by making sure said cache directory is fully populated with the shipping game.
   • The second usage is to analyze already compiled shaders to, for example, assign the view and projection matrices automatically if the shader declares inputs with the right usage and type.

   To work around the second usage, the required informations would have to be saved together with the compiled shader code when the shader is processed. Or an open source shader compiler would have to be found that can be ported to WinRT. Or the compiled shader code could be analyzed directly.

   My plan of attack is to just work on my game for now and when the Windows 8 release draws closer, I’ll see if the problem has been solved for me already (har har :D) or if I need to invest my own time.

10. Hi,

    I tried opening the demo, which compiles and executes, but I’m not able to see the model in the screen, just a plain blue background. I only opened the solution and compiled it as it was, do I need any more intermediate steps or something like that? I’m on Release Preview (8400).

    Thanks for your help

11. That’s all there is to it, compile and run.

    If the model doesn’t show, but the application keeps running, then my best guess would be that something went wrong loading resources.

    The demo writes a log file to the temporary directory it is assigned by WinRT (stored somewhere like C:\Users\Username\AppData\Local\Packages\37763720-a0f5-4da1-a71d-8e1ebc1bd5a8_v30vr5hfa5qb0\TempState\Ogre.log). You’ll probably have to either do a file search for Ogre.log or check the path passed to the Ogre::Root class in the debugger to get the correct location. Maybe some error is recorded in there.

12. Besides the warning about the old file format of the head, all media is loaded correctly. The D3D11 Rendering Subsystem is also initialized correctly. I can’t see what’s wrong in there.

13. Yes,me too. I got nothing but a blue screen.I even update the model format for ogre 1.8.0. Besides, I guess maybe there is something wrong with shader code, so I rewrite the generated shader to remove the RTShaderLib include ,but unfortunately it give me a wrong result. And I also find that this version can not be debugged by the Graphics Diagnostics….

    I’m on Release Preview (8400) and Microsoft Visual Studio Ultimate 2012 RC Version 11.0.50522.1 RCREL
    Microsoft .NET Framework Version 4.5.50501

14. It’s hard to figure out for me since it works perfectly on my system. Running the same versions as @ahzhe, with an NVidia GeForce GTX 460 using Microsoft’s default drivers.

    You can compile Ogre yourself if you want to debug into the engine code. It should be relatively painless:
    – extract everything into one directory
    – Open FreeImage (msvc-11.0-winrt).sln and compile
    – Open Boost (msvc-11.0-winrt).sln and compile
    – Open Ogre (msvc-11.0-winrt).sln and compile
    The binaries can be found in the bin directories of the projects. Copying OgreMain.dll and RenderSystem_Direct3D11.dll over the example should be sufficient since DLLs include the location of their PDB file.

    I haven’t used the graphics diagnostics in Visual Studio before. Currently reading up on it. Is there anything I have to do to enable it?

15. hi,Cygon,I just choose DEBUG->Graphics->Start Diagnostics(Alt + F5),and the Graphics Diagnostics will start for you.After that, u should capture one frame and choose Pipeline Stages, then u can debug into the shader code.here is the guild from msdn http://msdn.microsoft.com/en-us/library/hh873207(v=vs.110).aspx.
    I can use it to debug the samples code from http://code.msdn.microsoft.com/windowsapps/Direct3D-Tutorial-Sample-08667fb0,it is easy to capture one frame , but under ogre , the capture get nothing even after wait a long time, I do not know why..

16. Wow, that’s pretty useful. I didn’t even notice this feature before since I do everything via keyboard and virtually never open the menus :)

    I’m seeing an access violation on 0x0000000000000002 when I run with the debugger that is not occurring when I run the demo project normally. In a non-Ogre Metro + Direct3D application it works fine. I’ll see if I can find out why that is!

17. Hi guys. It can be problem with intel drivers, that work incorrectly with shaders having nested functions calls compiled with debug info. Take a look at one of commits named “D3D11 Render System: Workaround for broken debug shaders handling on some Intel cards” at http://bitbucket.org/eugene_gff/ogre-winrt

18. It is awesome!!

    I replace the code with https://bitbucket.org/eugene_gff/ogre-winrt/changeset/dc2c077e9690#chg-RenderSystems/Direct3D11/src/OgreD3D11HLSLProgram.cpp

    and now I can see the ogrehead in center of the wnd.^_^

    thx Eugene Golushkov!

19. Great! Thanks @Eugene, especially for finding my little blog here :)

    Looks like I’ll have to provide another update in the near future, especially now that you’ve rebased your repository to the Ogre 1.9 development trunk.

20. Hey. Your help is needed. As for your demo application to create a normal Ogre binaries for Visual Studio 2012 RC and Visual Studio 2010 SP1? Please, for more detail.

21. I’m not sure I understand you.

    The Ogre-1.8.0-WinRT-VS2012RC-Sources-and-Patches.7z package contains Visual Studio 2010 and Visual Studio 2012 RC project files that you can use to compile Ogre easily without setting up CMake or anything else.

    All solutions in that package follow a pretty obvious naming scheme: Ogre (msvc-10.0).sln is for Visual Studio 2010. Ogre (msvc-11.0).sln is for Visual Studio 2012 RC in desktop mode and Ogre (msvc-11.0-winrt).sln is for Visual Studio 2012 RC in Metro mode.

22. Sorry for my bad English. The demo project contains standard .mesh files. For example robot.mesh. And they are very open. But when I use my mesh files, error file msvcr110d.dll. How to create the mesh files are compatible with your project?

23. I’m using standard Ogre .mesh files. The ogrehead.mesh, robot.mesh, etc. are taken from the Ogre tutorial framework without modification.

    Try the following:

    – If you’re using custom shaders, add enable_backwards_compatibility true to your .material files. This allows HLSL to emulate instructions like tex2D() that have been removed in HLSL 4.0.

    – If there is an error, it’s likely that an exception is being thrown. Catch the exception in the WinMain() method and read the error message.

    – Read the Ogre.log file (do a file search for Ogre.log in C:\Users\Username\AppData\Local\Packages\), it may also contain the exception message.

    – If that doesn’t help, compile Ogre yourself (it’s as easy as first compiling FreeImage*.sln, then Boost*.sln, then Ogre*.sln). It will give you .pdb files that let your debugger show the exact line where the error was caused.

24. Maybe this helps you, too — I created the Ogre .mesh files I use in my game like this:

    1. Model and rig the mesh in Blender 2.5
    2. Use the OgreExporter for Blender
    3. Convert the .mesh into binary data (normally it’s XML) using OgreXMLConverter.exe from the OgreCommandLineTools (see Ogre website)

    That has worked for me so far.

25. HI, I cant run this code.

    I’m using windows 8 RTM. It’s compile well, but it throw an
    “The program ‘[6044] OgreTest.exe’ has exited with code -1073741511 (0xc0000139) ‘Entry Point Not Found’.
    Activation of the Windows Store app ‘2b0733fd-f68d-4eb6-b469-394d7f916d37_v30vr5hfa5qb0!App’ failed with error ‘The app didn’t start’.”

    look it cant find the main method. Does anyone could give me some tip to fix it?

26. They probably changed things again and you will need to recompile all the libraries using Visual Studio 2012 RTM.

    I don’t have an MSDN subscription, so I can’t provide a new package until Windows 8 is officially released or even test it on Windows 8 RTM.

27. Yep, same issue here.

    Noticed that _beginthreadex is now completely out, can’t even compile with it in there when building the libraries. I replaced it with a C++ task call but am now getting critical errors at runtime, going to put it on the back burner.

    Was wanting to present at a conference next week using Ogre, but unfortunately I have to do it in RTM Windows, not RP.

28. Working now under RTM (well, for now). Carefully copied all the rebuilt binaries again, I must have copied a wrong one by mistake.

    So to rebuild the sources… get the full source zip, extract everything. Build everything. Only difference is…

    – Open up “FreeImage-SeparateLibs (msvc-11.0-winrt).sln”
    – Replace the _beginthreadex in Source/IlmThread/IlmThreadWin32.cpp with your preferred approach to concurrency::create_task
    – Build
    – Copy

    Working well.

29. Ah, I admit I already had a bad feeling when I used _beginthreadex() there but it was so much more convenient than wrapping a task or switching to std::thread (which on WinRT probably just wraps the task API, too, I suspect).

    Thanks for the report, I guess I can be a bit more relaxed about the Windows 8 release now :)

30. Hi,

    I’m trying to run it on Win8RTM with last VS2012. Got same ‘Entry Point Not Found’ issue.

    So i tried to recompile “FreeImage-SeparateLibs (msvc-11.0-winrt).sln” with “concurrency::create_task” instead of _beginthreadex.
    But it still crashes… Maybe i don’y use correctly “concurrency::create_task”.

    Which code did you use, please ?

    Thanks,

31. I do not think that part of the code is ever executed, you could probably replace it with “throw -1” and not ever notice the change.

    If it doesn’t work, you have probably not recompiled everything, not copied the recompiled binaries into the References directory or forgot something else.

    I’m currently setting up Windows 8 and Visual Studio 2012 Express, so I haven’t even been able to test it for myself until now. If all goes well, I’ll probably provide an updated package in the next days.

32. Thank for your reply. I tried to recompile again the 3 packages and recopy properly each .dll & .lib in “References” directory but it’s still crashing.
    Error is not the ‘Entry Point Not Found’ issue; after debugging “OgreTest”, it crashes when loading “RenderSystem_Direct3D11.dll”.

33. Now it works ! I see the ogrehead !

    I ve just replaced my recompiled “rendersystemd3d11.dll + lib” with ones containing in your “demo.7z” package.
    To resume of what i did:
    -install win8rtm & vsstudio 2012 ultimate trial version
    -unzip your full source and erase the line with _beginthreadex (or replace with a thread create)
    -recompile 3 packages : boost, freeimage & ogre (winrt.sln).
    -unzip your demo package
    -replace all dll & lib (except directx11 plugin) in Reference directory with dll lib recompiled.
    -compile & run demo package updated

34. Hi Cygon thanks for providing this code, I’m wondering if there has been any progress on the d3dcompiler issue for store submission. I am beginning work on a project that is set for release next month.

35. Hi!

    From your forum thread, it looked like 1 day after I offered my solution, Assaf had decided on a solution of his own that he thought would be better than mine:

    > “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.”

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

    > “I worked today on getting your code to work. Regarding the reflection – I hope you will
    > see that my solution is better when it is completed.”

    > “I wrote the “cache the reflection data” code in just a few hours. You can view it on
    > the summer project repo.”

    Thus I concluded that my help was no longer wanted.

    Did I misunderstand?

36. can load other dll ok, but can’t load “RenderSystem_Direct3D11.dll”, recompile RenderSystem_Direct3D11.dll, also not work!

37. Without the error messages and a clear description of what you did it’s hard to even guess what’s going wrong.

    This was done with the Windows 8 Release Preview and VS2012 Release Candidate.
    Skyrocker (a few comments above yours) explained what he did to make it work on Windows 8 RTM. Did you try that?

    In any case, the source snapshot I used is pretty outdated by now. It’s probably better to use Eugene’s current sources (I think I’ve read they’ve been merged with the official Ogre source tree, too).

This site uses Akismet to reduce spam. Learn how your comment data is processed.