locked
ARM and DirectX / c++

    Question

  • I have been making good progress on my x86 C++ Direct3D11 Metro app/game.  I was aware for a while that Win8 would run on ARM tablets/PC's and I just figured that would be a segment of the market I would miss out on.

    Now I read that the very first Microsoft Surface Tablet out at Win8 launch would be the ARM version.  So now I am wondering can you make a C++/Direct3D11 Metro app by just recompiling an x86 project for ARM, or is that not possible.


    http://www.puttnutz.com

    Wednesday, June 20, 2012 6:35 PM

Answers

  • Things you can do to make it easier to port to Windows RT before you get any hardware:

    * Make sure your application runs well on Feature Level 9.1 and Feature Level 9.3 devices, plus whatever you are using for x86.

    * Use DirectXMath instead of some roll-your-own math library. DirectXMath supports SSE2 on x86 and x64 native, and ARM-NEON on ARM platforms.

    * Ensure you can build your application as both an x86 and x64 native Metro style app. This helps you find some 32-bit x86 specific non-portability issues, and certainly helps highlight any dependancies on other libraires you may be using that don't have x64 native versions and thus may not have ARM versions either.

    * Consider enabling maximum warnings (/Wall) and then disable the specific ones you can safely ignore (using #pragma warning or /wd). This helps find portablity issues as well, particularly C4302 and C4826.

    * Use C++ style casts instead of C-style cases. (const_cast, static_cast, reinterpret_cast). This can really help avoid supressing useful warnings when your cast does something you did not realize it did.

    * Use Code Analysis (/analyze) and fix any issues. Be sure to run it on x86 and x64 native builds for both Debug and Release configurations. This will ensure you have clean, portable code.

    * Once you've done all that, try building an ARM configuration using the VS 2012 tools and resolve any remaining code issues.



    Wednesday, June 20, 2012 11:24 PM

All replies

  • That is correct. In general the move from x86 to ARM is just changing the target and recompiling. So long as your app gracefully handles lower end hardware you should be fine.

    Once ARM systems are available you will want to test on them, but I wouldn't expect significant problems.

    --Rob

    Wednesday, June 20, 2012 7:44 PM
    Owner
  • Very nice!

    One more question.  The simulator that is used to capture screenshots. If you build for ARM and then launch Store\Capture Screenshots will it run an ARM version of the Simulator, or do you need an actual ARM target HW with DX11 video?

    Is there any talk of allowing licensed developers purchase early versions of the surface tablets before they are avalable to the general public?


    http://www.puttnutz.com

    Wednesday, June 20, 2012 8:02 PM
  • You would need an actual ARM target HW. The simulator isn't an emulator: it actually connects back to your existing machine via an RDP session.

    I am not aware of any announcements about pre-release developer ARM hardware.

    --Rob

    Wednesday, June 20, 2012 8:20 PM
    Owner
  • Things you can do to make it easier to port to Windows RT before you get any hardware:

    * Make sure your application runs well on Feature Level 9.1 and Feature Level 9.3 devices, plus whatever you are using for x86.

    * Use DirectXMath instead of some roll-your-own math library. DirectXMath supports SSE2 on x86 and x64 native, and ARM-NEON on ARM platforms.

    * Ensure you can build your application as both an x86 and x64 native Metro style app. This helps you find some 32-bit x86 specific non-portability issues, and certainly helps highlight any dependancies on other libraires you may be using that don't have x64 native versions and thus may not have ARM versions either.

    * Consider enabling maximum warnings (/Wall) and then disable the specific ones you can safely ignore (using #pragma warning or /wd). This helps find portablity issues as well, particularly C4302 and C4826.

    * Use C++ style casts instead of C-style cases. (const_cast, static_cast, reinterpret_cast). This can really help avoid supressing useful warnings when your cast does something you did not realize it did.

    * Use Code Analysis (/analyze) and fix any issues. Be sure to run it on x86 and x64 native builds for both Debug and Release configurations. This will ensure you have clean, portable code.

    * Once you've done all that, try building an ARM configuration using the VS 2012 tools and resolve any remaining code issues.



    Wednesday, June 20, 2012 11:24 PM
  • Just to confirm.  I am getting ready to hit the "Pre-Order" button on Surface with Windows RT.  Is there a way to either:

    a) Get Dev Studio running on this Windows RT Surface so I can see how my app runs, or

    b) I can build my app for ARM on my development PC, and install it on the Windows RT Surface.

    Please advise.

    Thanks!


    http://www.puttnutz.com

    Tuesday, October 16, 2012 3:50 PM
  • Hi David,

    You'll do the second: build on your dev PC and then install and remote debug on the Windows RT device.

    Jason Zander has a good overview of the process at http://blogs.msdn.com/b/jasonz/archive/2012/06/12/what-you-need-to-know-about-developing-for-windows-on-arm-woa.aspx

    --Rob

    Tuesday, October 16, 2012 4:23 PM
    Owner
  • I can't wait.  Really looking forward to it !!!

    Other related issue is I am doing a 3D minigolf game.  Each level/hole is a .DLL with POD structs and common entry points to initialize.  Currently when these get built the output directory is the Assets folder.  I have the .DLL's added to the project and "Content" set to true.  works great.  I am guessing I will now need each .DLL compiled for ARM as well right? Does that mean that I add all of those .DLL's in both flavors into one package or do I make two packages, one with ARM assets and one with x86.

    Your help is greatly appreciated!!


    http://www.puttnutz.com

    Thursday, October 18, 2012 9:51 PM