Here’s an interesting hypothesis: when Apple started its App Store, it was the El Dorado of software developers. Now Microsoft is adding an App Store to Windows 8. The Windows user base is huge, much larger than even the number of people running around with iPhones in their pockets (some estimates I came across average to around 75 million iPhone users [1] [2] versus around 600 million Windows users [3] [4]). Even if Windows 8 adoption rates are as bad as Vista’s you could turn a mighty profit!
What better way could there be to achieve that than to publish a 3D game on the Windows App Store when most of the world’s developers are still trying to get a grasp of WinRT? :)
Of course I wanted to use an existing 3D engine, so I reviewed my options:
| Engine | Status |
|---|---|
| Ogre 3D | A user named Eugene on the Ogre forums already did all the work required fixing invalid API calls so Ogre compiles and validates on WinRT. This is what this post is about! |
| C4 Engine | No word on WinRT/Metro support. C4 is based on OpenGL, but Windows App Store only allows Direct3D 11 to be used. I’ve seen someone on C4’s forums working on a Direct3D 11 renderer, so if its source is released, C4 users might get lucky. |
| Unity | I believe Unity is well positioned for Metro support (they have an experimental Direct3D 11 renderer, I wouldn’t rule out porting Mono to WinRT either). No official statement yet and I’ll not risk betting on some kind of surprise. You can vote for Unity WinRT/Metro support here. |
| Axiom 3D | Axiom 3D is a .NET rewrite of Ogre. Work on a SharpDX renderer is on its way, and SharpDX will support WinRT/Metro. Sadly, Axiom 3D is severely understaffed, thus, despite fantastic people like Borrillis, the massive size of the code base means it’s moving slowly. |
Ogre 3D
Thanks to Eugene’s work on porting Ogre to WinRT/Metro all I had to do was pick up his changes, reapply them to my sources and generate projects via Visual C++ 11 Beta (CMake is great and all that, but I already had some projects from my Mogre builds and wanted to customize a few things). The ARM debug build was a bit tricky, I had to use LTCG just so the linker wouldn’t blow up from the size of the object files.
In the end I managed to build a working set of Ogre WinRT binaries:
You can download a minimal example application that will compile and run out-of-the-box as long as you have the Windows 8 Consumer Preview and Visual Studio 11 Beta installed. It includes binaries of Ogre, FreeImage, Hydrax and SkyX for x64, x86 and ARM in both Debug and Release flavors and is configured to automatically link the right versions of those libraries.
Notice
Binaries no longer work on Windows 8 Release Preview
WinRT and C++/CX have gone through some changes and the files below will no longer
work with the current Visual Studio and Windows 8 versions. I have published a new
package here: Ogre
1.8.0 for WinRT/Metro.
Download
Ogre-1.8.0-RC1-WinRT-VS11Beta-Demo.7z (29.6 MiB)
Ogre-1.8.0-RC1-WinRT-VS11Beta-Sources-and-Patches.7z (82.6 MiB)
Requires Windows 8 Consumer Preview and Visual Studio 11 Beta (I’m running the Express edition, but have Professional installed also, so it may or may not work with Express alone). The Demo package contains the example project and all compiled Ogre DLLs you need to get going. The Sources-and-Patches package contains the Ogre source code and is useful if you want to compile and debug Ogre yourself.
Status
As you probably already know if you’re interested in WinRT development, many of the Windows API methods are not accessible to WinRT applications. Visual C++ 11 Beta helps you by removing forbidden API methods if you compile a WinRT project, and to detect things such as linking to a non-WinRT DLL that uses forbidden API methods, the Windows App Certification Kit is used. If you submit anything to the Windows Store, Microsoft will do its own checks, which at the very least include running the Windows App Certification Kit. If that fails, your app will not be accepted.
The current Ogre WinRT build passes validation with these exceptions:
- PluginCgProgramManager uses NVidia’s CG toolkit. You can use it for development, but your final product must not load or use this plugin
- RenderSystemDirect3D11 relies on D3DCompiler_44.dll, which is not WinRT-clean. We have to see whether Microsoft provides an HLSL compiler that can be used from WinRT or if we need to compile all shaders ahead of time and only ship their compiled versions.
Windows 8 RC1 is expected for May/June, so we may get a new Visual Studio 11 Beta and more informations then. Even if that brings bad news (eg. no HLSL compiling in Metro), there’s still at least 4 months left until release day, so my plan will be to begin development with what I got here and in 2-3 months I can evaluate if additional work will be required or not. That would also be a good time to decide whether aiming to publish a playable mini version of the game in the Windows Store before Windows 8 release day in order to get acquainted with the process would be a good idea.
Interesting stuff. I hadn’t paid much attention to WinRT or the Windows App Store but I suspect you might be on to something here. Good luck with your project :)
Thanks! I would have loved to use Mogre for this (and C++/CX looks pretty similarto C++/CLI on the surface), but it’s also fun doing some C++ again after all this time with .NET :)
Hi,
Thank you for this great files.
I have problems with the materials, if I use a compex one(for example “Ogre/Compositor/Blur0”) it closes the app.
Sorry, I’m still learning Ogre myself. What you can do is make the debugger halt on any exception (Ctrl+D,E, check “thrown” in C/C++ exceptions) and see if an exception is coming up somewhere when the app closes. I haven’t included the .pdb files (otherwise the package would have been hundreds of megabytes in size), so to actually see where in Ogre’s source it is happening, you’d need to use the second package I provided and try to compile Ogre yourself.
Another thing you could do is to cross-check the results with the normal Ogre SDK, but using the Direct3D 11 driver. The effect compiler in Direct3D 11 is a completely new one, I believe, and only compiles the old shader sources with a compatibility flag set, so it might very well be that the material you’re using contains some effect that has problems under Direct3D 11 in general.
Just to let you know I get a few issues in the latest Win8 build. Unfortunately I’ve moved all my machines off CP and while I can’t talk about it in detail due to the NDA situation, it’s a couple of compilation errors, and after fixing those it crashes on start-up unable to find the app entry point.
I was just wanting to play around with the build as I was curious, as such I didn’t really have time to dig much further than the compilation errors. Linking worked perfect. Great work however, very exciting. Looking forward to see it in action.
When Windows 8 RC is released around June, I’ll be able to see for myself and either update the package or make a new one.
It’s weird that they would be making breaking changes now when they’re so close to the RC, while they managed to keep everything working between the developer preview and the community preview.
Yeah. I was really impressed with how few errors I got. I’m having another poke around tonight so will keep you posted if I find anything.
http://pastebin.com/QE0cDx93
Hi, I’m also having the issue “someone” mentioned. The app is crashing with the issue “First-chance exception at 0x77529551 (ntdll.dll) in SampleBrowser.exe 0xC0000139 ‘Entry Point Not Found’.
I am running Win8 Release Preview with VS 2012 RC. There were a couple project changes that had to be made to get this working on release preview: add _CRT_SECURE_NO_WARNINGS and _SCL_SECURE_NO_WARNINGS to the preprocessor defs for OgreMain. Then in the SampleBrowser project, remove d3dcompiler_44.dll and replace with d3dcompiler_45.dll, since 44 is no longer provided.
Any pointers you could give on this issue? Are you anticipating another drop of the solution sometime in the near future? We are looking forward to be using this.
Oh, yeah, I also added “sealed” to the BasicTimer class and the SampleBrowserWinRT class…maybe that was wrong? It wouldn’t compile otherwise.
I’m working on an updated build with the Ogre 1.8.0 sources right now. This time with thread support, too.
The ‘sealed’ requirement is new to Visual Studio 2012 RC, so there’s no way around it. Your error sounds a bit like the Visual Studio projects need some change (I’m currently just recreating all my projects from scratch because I want to make absolutely sure there are no beta bits hanging around anywhere.)
Ok, great. I’ll check back for the new drop. Thanks for the work on this!
And done! You can find my new Ogre 1.8.0 WinRT kit here: http://blog.nuclex-games.com/2012/06/ogre-1-8-0-for-winrt-metro/
The thread support is not heavily tested yet, but I haven’t seen any issues in my current game project (which uses the terrain component, which uses threading to generate lightmaps for the terrain)