Raise a connect issue. That way it will bring it to there attention and they may realise they should include it.Eugene wrote: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.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.
Ogre`s Windows 8 UI Style port (now commited to OGRE!)
- Zonder
- Ogre Magi
- Posts: 1168
- Joined: Mon Aug 04, 2008 7:51 pm
- Location: Manchester - England
- x 73
Re: Ogre`s Windows 8 Metro Style port
There are 10 types of people in the world: Those who understand binary, and those who don't...
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
WinRT related changes were rebased on top of current v1.8 branch
-
- Platinum Sponsor
- Posts: 290
- Joined: Tue Jan 17, 2012 5:18 am
- x 67
Re: Ogre`s Windows 8 Metro Style port
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?
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?
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
Almost all libraries would need some porting and at least recompilation.loath wrote:did you have any trouble using other libraries with windows 8 / metro? for example, boost, physx, etc?
- Cygon
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
- Contact:
Re: Ogre`s Windows 8 Metro Style port
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.
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.
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
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).
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).
- Kojack
- OGRE Moderator
- Posts: 7157
- Joined: Sun Jan 25, 2004 7:35 am
- Location: Brisbane, Australia
- x 534
Re: Ogre`s Windows 8 Metro Style port
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 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.
- Cygon
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
- Contact:
Re: Ogre`s Windows 8 Metro Style port
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
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
Professional C++ and .NET developer trying to break into indie game development.
Follow my progress: http://blog.nuclex-games.com/ or Twitter - Topics: Ogre3D, Blender, game architecture tips & code snippets.
Follow my progress: http://blog.nuclex-games.com/ or Twitter - Topics: Ogre3D, Blender, game architecture tips & code snippets.
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
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 purposeCygon 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
- Cygon
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
- Contact:
Re: Ogre`s Windows 8 Metro Style port
That's what I was saying. I was advocating against casting (Something *) to (long long).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
- Cygon
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
- Contact:
Re: Ogre`s Windows 8 Metro Style port
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.
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.
Professional C++ and .NET developer trying to break into indie game development.
Follow my progress: http://blog.nuclex-games.com/ or Twitter - Topics: Ogre3D, Blender, game architecture tips & code snippets.
Follow my progress: http://blog.nuclex-games.com/ or Twitter - Topics: Ogre3D, Blender, game architecture tips & code snippets.
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
Direct3D/Xaml interoperability done. As usual, sources are at http://bitbucket.org/eugene_gff/ogre-winrt
- ahmedismaiel
- OGRE Contributor
- Posts: 217
- Joined: Wed Jan 25, 2006 11:16 pm
- Location: Redmond,WA
Re: Ogre`s Windows 8 Metro Style port
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
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
The program '[7028] SampleBrowserWinRTXaml.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
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).
- ahmedismaiel
- OGRE Contributor
- Posts: 217
- Joined: Wed Jan 25, 2006 11:16 pm
- Location: Redmond,WA
Re: Ogre`s Windows 8 Metro Style port
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++
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++
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
This is done automatically by right version of CMake. Probably you uses wrong one, and needs to do this manually.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.
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.
- Cygon
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
- Contact:
Re: Ogre`s Windows 8 Metro Style port
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.
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.
Professional C++ and .NET developer trying to break into indie game development.
Follow my progress: http://blog.nuclex-games.com/ or Twitter - Topics: Ogre3D, Blender, game architecture tips & code snippets.
Follow my progress: http://blog.nuclex-games.com/ or Twitter - Topics: Ogre3D, Blender, game architecture tips & code snippets.
- ahmedismaiel
- OGRE Contributor
- Posts: 217
- Joined: Wed Jan 25, 2006 11:16 pm
- Location: Redmond,WA
Re: Ogre`s Windows 8 Metro Style port
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?
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?
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
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.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?
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.
- ahmedismaiel
- OGRE Contributor
- Posts: 217
- Joined: Wed Jan 25, 2006 11:16 pm
- Location: Redmond,WA
Re: Ogre`s Windows 8 Metro Style port
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 ?
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
SampleBrowserWinRT > Properties > Custom Build Stepahmedismaiel 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 ?
- ahmedismaiel
- OGRE Contributor
- Posts: 217
- Joined: Wed Jan 25, 2006 11:16 pm
- Location: Redmond,WA
Re: Ogre`s Windows 8 Metro Style port
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
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 ?
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.
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
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 metEugene wrote: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.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).
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.
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
WinRT related patches as well as several generic bugfixes were rebased on top of v1.8 branch
- Cygon
- Halfling
- Posts: 70
- Joined: Thu Nov 07, 2002 9:36 pm
- Location: Germany
- x 5
- Contact:
Re: Ogre`s Windows 8 Metro Style port
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.
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.
- Eugene
- OGRE Team Member
- Posts: 185
- Joined: Mon Mar 24, 2008 4:54 pm
- Location: Kraków, Poland
- x 41
Re: Ogre`s Windows 8 Metro Style port
First issue can be corrected by using "internal" and "protected internal" access specifiers.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.
For the second question, AFAIK ARMs are little-endian too, so byteswap functions are necessary.