Limit 3D application for Windows RT device - windows-8

I am developing a 3D game for Windows Store (Metro application) using Visual Studio 2012 Express and Blender for creating 3D objects (fbx). I have used Visual Studio 3D Starter Kit for importing fbx file in the game. Currently I have tested my application on Windows 8 machine only and now, I want to test it on Windows RT device too. On Microsoft forums I read that if I want to deploy the build on Windows RT device, I need to limit my application to Feature Level 9_1.
I need to know the following two things:
• How to run the application on hardware graphics card on Windows RT machine?
• How to limit the application to DirectX Feature Level 9_1?
Any help will be appreciated.

How to run the application on hardware graphics card on Windows RT machine?
The Direct3D code provided in the various Windows 8 samples and templates should always run on the hardware graphics card. Assuming you're interested in the specifics of how to actually get the app there in the first place (i.e. deployment), there are two main ways to do this. The first is remote deployment and debugging: In Visual Studio, go to your project's properties page and go to the Debugging view. Under "Debugger to launch" select "Remote Machine" and set "Machine Name" to the IP address or NetBIOS name of the target Windows RT machine. The remote machine will need to be running the remote debugging tools and connected to the same network as the development machine. For more info about remote debugging, check out this page.
The second way is to manually create and deploy a local test package. To do this, right click the project and go to Store -> Create App Packages. When prompted about whether this package will be submitted to the store, select "no" and follow the remaining prompts to create an appropriate app package. Copy the contents of the created package folder to the target machine, then run the "Add-*" powershell script. This will install the package on the target machine.
How to limit the application to DirectX Feature Level 9_1?
The best way to do this is to use the DirectX Control Panel. Run "dxcpl.exe" and click "Edit List" under the scope menu. Add the name of your app's executable (typically [app name].exe) to the list. Then, under Device Settings, set "Feature level limit" to 9.1 and check the "Disable Feature Level Upgrade" checkbox. The next time you launch your app, the system will automatically restrict functionality to what is available on 9.1 hardware.
Note that the Windows App Certification Kit automatically performs a feature level test to ensure your app does not crash on 9.1, however its scope is relatively limited.

In additional to alanw, if you have any shaders in your solution, for each, bring up the property page in VS, expand "HLSL Compiler" and select "General". Under "Shader Model" select 4_0_level_9_1.

You should pass in the D3D_FEATURE_LEVEL_9_1 feature level on creation of your d3d11 device.
D3D_FEATURE_LEVEL pFeatureLevels[] =
{
D3D_FEATURE_LEVEL_9_1
};
ID3D11Device* pDevice;
ID3D11DeviceContext* pDeviceContext;
D3D_FEATURE_LEVEL eFeatureLevel;
D3D11CreateDevice(NULL, D3D_DRIVER_TYPE_HARDWARE, NULL, pFeatureLevels, 1,
D3D11_SDK_VERSION, &pDevice, &eFeatureLevel, &pDeviceContext);

Related

Building iOS hybrid app does not update worklight.plist or root.plist file

I'm running WL 6.1 (6.1.0.01.20140310-1427) on a macbook air (latest OSX). I have a dojo hybrid application that I'm trying to connect to a remote WL server. When I generate an iOS app and I'm changing the address of the worklight server to a remote server. It does not change the address in the generated iOS code. The steps I follow are:
Open the Build Settings and Deploy Target... On the hybrid app folder.
Select the check box for Build the application to work with a different Worklight server.
Put in the new server information and click OK
Build all environments
After the build is complete, I launch into xcode and look at the worklight.plist and Root.plist files.
At this point they are still referencing my local server. If I edit them to point to the remote server, then my app works. Since these files are regenerated every time you do a build this is not a valid solution.
To verify it is nothing in my app, I created a default dojo hybrid application. Performed the steps I listed above. When I launched into xcode, the Root.plist and worklight.plist still have the default local server information.
So here is the funny thing. I also have a win7 system running the same level of WL developer plugin. I perform the same steps and the worklight.plist file is updated correctly on windows, just not in osx. The only other difference is the win7 version is running jre 1.7_21 where the osx is running 1.7_51. Both are in 64-bit mode.
I believe the real difference between your Mac and Windows machines is step 5, where you "launch into xcode". If by that you mean that you are actually doing Run As > Xcode project, then see below. This option is available only in Mac and not in Windows.
This is the expected behavior in Worklight 6.0.0.x and 6.1.0.x.
If after changing the server address to a remote server (rather than the local development server) and building, and then selecting Run As > Xcode project, this will overwrite the server settings back to the local development server.
Run As > Xcode project does 3 actions:
Build & deploy the app to the local Worklight Development Server
Generate an Xcode project (this in turn overwrites worklight.plist back to use local server settings)
Open the generated Xcode project in Xcode
So if you want to use the app with the remote server settings, then after changing the settings and build the app, either:
Copy the .zip from the your-iphone\package folder
Navigate in the filesystem to the iphone\native folder and double-click the .xcodeproj file to open the it straight in Xcode (like what Run As > Xcode project does)
For future releases of Worklight it is being considered to streamline the behavior so that no matter if you choose, local or remote server settings, Run As > Xcode project will always use the ones you've selected.

Cannot use Direct Update for Windows 8 in Worklight 5.0.6

I use Worklight 5.0.6 and can't use direct update for a Windows 8 application.
IBM Worklight Information Center tells that windows 8 app can use direct update.
My way to test direct update as follows.
Please tell me how to use direct update in Windows8.
make windows8 env project
change wlInitOptions.connectOnStartup value "true" (in common\js\initOptions.js )
select [Build All and Deploy]
double click .jsproj file run simulator in visual studio 2012 for Windows8
make app "back ground"
change html file and "re [Build All and Deploy]"
make app "foreground"
This documentation page is misleading (I will open a defect to correct it).
Direct Update (as in the process of updating the web resources of the application after it has already been installed on the device) is available ONLY for iOS and Android. In those environments following your steps will indeed trigger a Direct Update.
The update (or rather, upgrade) of Desktop applications has no relation what-so-ever to the Direct Update mechanism mentioned above.
For Desktop enviornments consider it like updating any other desktop application - where you up the version number, and the app detects that there is an update available or so.
In the case of Adobe Air and Windows 7/Vista Gadgets:
Build your application and install it
In application-descriptor.xml, up the value of the version attribute in the envrionment's element (for instance from "1.0" to "1.1")
Build again
I believe that now you need to go to the Worklight Console and re-download the installer, and it will detect that it needs to upgrade rather than install afresh).
Note: iGoogle, Facebook, Windows 7/Vista Gadgets and Dashboard environments will be removed in the next version of Worklight. All have ample replacements with other supported Worklight environments.
In the case of Windows 8:
Direct Update most certainly does not exist for it
The steps above are also not relevant as it is not a downloadable executable

How can I submit an application to the store that can target multiple platforms?

I'm prepping an application for submission to the Windows Store that utilises the Bing Maps API - as such, the app has to be compiled to target specific architectures. Whilst there is a guide to submission, it's not clear how to submit both Arm and x86 configurations of the same app. Is it even possible, or will there have to be in the store twice?
When you select the option to create your app package from the Visual Studio Store menu, you get a choice to select the package architecture. There are 4 options: Neutral, x86, x64, ARM.
If you select Neutral, then it builds a single package for "Any CPU" that you can upload to the Store. If you select x86, x64 and ARM, it will build a package for each of these configurations, and you will have to upload the corresponding packages for the architectures you wish to support.
Additionally, if you're building to submit to the Store, make sure to always select Release for each of the selected architectures.
There are cases where some references don't support building using a Neutral architecture. The Microsoft Visual C++ Runtime Package is an example.
Taken from here:
The process of engineering for ARM was different for each language (JavaScript, C++, and C#/VB), based on existing implementation details
of the various runtimes and compilers.
JavaScript uses a JIT compiler, so platform targeting is taken care of at runtime. Therefore Metro style apps using JavaScript are
platform neutral, and you can write once to run on x86/x64/ARM.
C# and Visual Basic are also abstracted from hardware differences. They compile to MSIL, which is platform neutral. Therefore, Metro
style apps using C# or Visual Basic can be compiled once to run on
x86/x64/ARM.
C++ is close to the metal, and compiled to the machine language for
the platform that you’re targeting. This offers developers full
control, but also requires that they specify the hardware where the
app will be supported.
The essence of it is that pure .net or pure html/js will run on any architecture without problems. If you want C++ then you will need to compile your app once for each supported architecture. My understanding is that you can create an app package which contains installers for multiple architectures in this case.
The post here has some good details on packaging your app for multiple architectures. Here are a few highlights:
7.In the Select the packages to create and the solution configuration mappings section, select the check box for each build configuration
for which you want to create a package.
The build configurations grid lists the possible platform
architectures of the package (that is, Neutral, ARM, x64, and x86). In
each row, a combo box displays the combination of the current Solution
Configuration and Architecture choices that are relevant for that
row’s architecture. The check box for the default platform is set to
the current, active project platform. The combo box for the Neutral
row show the Solution Configuration combinations that contain AnyCPU
as the project’s platform. If no Solution Configuration combination is
relevant, the entire row for that platform is unavailable for
selection. One package is produced for each configuration that you
specify.
8.For each build configuration that you specified, choose the Solution Configuration that you want to build.
When you package an app for the Store, you can specify Release or any
custom solution configuration that you’ve created.
A package will be created for each build configuration that you
specified.
From here we get this:
7.Click Packages to upload your app's packages.
And finally from the previous link:
Signing and publishing
After your app passes the certification testing, its packages are
digitally signed to protect them against tampering after they have
been released. When this phase begins, you cannot cancel your
submission.
Note It might take some time for your app's listing to appear in
search results. This is normal. Also, you can't change a release date
after you submit the app to the Windows Store, but you can cancel the
release, update the release date, and re-submit.
Overview: During the build process you specify all architectures you want your app to work for and it creates a package for each. During the submission process you select all the packages you built for that app. When submitting you app this way only one version will show up in the store.
If you build just a HTML5/javascript Windows Store app, it work on all version (ARM, x86 and x84)
If you create something web with bing api. No worry about what platform doesn't work.
Answer is here: http://developer.android.com/google/play/publishing/multiple-apks.html
TLDR:
Go to your Google Play app developer console
Choose your app
Select APK on the left
Turn on Advanced Mode
Upload your ARM apk
Upload your x86 apk
Google will figure out the rest

How to attach to WWAHOST from Visual Studio 11

If I F5 a Windows 8 JavaScript app and look at the processes pane in VS11, I see that it's WWAHOST.exe that I'm attached to. Is it possible to attach to this after the fact using Debug | Attach to Process? I don't see it in the process list even when I show processes from all users. I see the same thing whether I run locally or in the Simulator. Thanks.
There are effectively two ways to do this. Delay starting the app and attaching the app. You will need to install the remote debugger from Microsoft. As of this writing, it is located on http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=28973
Detailed steps plus explanations are here.
Summary:
Install VS remote tools
On start menu, launch "Debuggable Package Manager" (powershell will start)
using powershell: get-appxpackage (to locate your package)
using powershell: enable-appxdebug PackageFullName
Launch application
Attach to the correct wwahost.exe for your application.
Debugging Topics Located here.

Emulate CMD in Metro Style App For Win 8 on ARM

As we know , we are not going to have a command line prompt as we in traditional Windows system for Windows on ARM.
I am trying to emulate command line prompt. The Question i have is it possible for us to spawn new process/app from a given app (as a background task could also do) with parent app having all information about child app?
You CAN dynamically load and execute assemblies.
Assembly.Load() works fine - as long as the target is a System assembly or in your app's package graph (i.e. in your app's package, or a declared 's package).
You're right, Metro/Desktop are very different. A 'MetroCMD.exe' would by definition be restricted; given the isolated nature of Metro apps, would a Metro CMD.EXE be useful?