Those binaries no longer work with the Windows 8 Release Preview and Visual Studio
2012 RC, so I thought I’d provide an updated package!

This time I went a bit further: while the last package was compiled with multithreading
disabled, I have in the meantime ported Boost 1.50.0 to compile on WinRT (using a slightly
modified version of Shawn
Hargreaves’ WinRT CreateThread emulation code. Thus, this Ogre build has full support for
multithreading and includes Boost!

The Demo package contains the example project and all compiled Ogre DLLs,
just like an OgreSDK, only organized a bit differently. Also includes normal Ogre binaries
for Visual Studio 2012 RC and Visual Studio 2010 SP1.

The Sources and Patches package contains all the source code and projects
(Boost, FreeImage, Ogre) so you can compile everything yourself and obtain PDB files
that let you debug Ogre in case something goes wrong.

37 Responses to “Ogre 1.8.0 for WinRT/Metro”

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.

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)

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

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)

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

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

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.

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

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?

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!

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

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.

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?

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.

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)

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.

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 🙂

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

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.

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

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.

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