Quantcast
Channel: Intel Developer Zone Articles
Viewing all 554 articles
Browse latest View live

An Introduction to Jack and Jill on X86

$
0
0

Download PDF

Jack (Java* Android* Compiler Kit) is a new Google* tool that includes a compiler from Java source code to the Android dex file format. Jack has its own .jack library and provides most toolchain features as part of a single tool: repackaging, shrinking, obfuscation and multidex. There is also a tool that translates existing .jar files to the .jack library format. This is Jill (Jack Intermediate Library Linker).

Overview

When the tool is enabled, Jill will translate any libraries you are referencing to a new Jack library file (.jack). This prepares them to be quickly merged with other .jack files. The Jack and Android Gradle plugin collects any .jack library files along with your source code and compiles them into a set of dex files. During this process Jack also handles any requested code minification (shrinking and/or obfuscation). The output is then assembled into an apk-file as normal.

Jack and Jill App Build

How to Use Jack with the Gradle Plugin

Jack and Jill are available in Build Tools as of version 21.1.1, via the SDK Manager (Figure 1). Complementary Gradle and Android Studio support is also already available in the Android 1.0.0+ Gradle plugin.
The Gradle plugin enables the experimental Jack build tools by adding useJack in your build config (useJack=true).

Jack and Jill App Build
Figure 1

Using Command Lines

To display the usage information for Jack and Jill use the commands below. Some features may be available on the command line before they are made available through the Android Gradle plugin.

  • Jack usage (Figure 2)
    • java –jar <SDK>/build-tools/< Build Tools version>/jack.jar –help
  • Jack usage (Figure 3)
    • java –jar <SDK>/build-tools/< Build Tools version>/jill.jar –help

Jack &amp; Jill command lines
Figure 2

Jack &amp; Jill command lines
Figure 3

Compilation Support

Java programming language 1.7.
Repackaging, shrinking, obfuscation and multidex features are supported.
Annotation processing is not supported.

Shrinking and Obfuscation Support

Proguard configuration files can be specified on the command line through the "--config-proguard" option.

  • Common options:
    @
    -include
    -basedirectory
    -injars
    -outjars // only 1 output jar supported
    -libraryjars
    -dontoptimize // required: Jack does not optimize
    -dontpreverify // required: Jack does not preverify
    -dontskipnonpubliclibraryclasses
    -dontskipnonpubliclibraryclassmembers
    -forceprocessing
    -keep
    -keepclassmembers
    -keepclasseswithmembers
    -keepnames
    -keepclassmembernames
    -keepclasseswithmembernames
    -printseeds
  • Shrinking options:
    -dontshrink
  • Obfuscation options:
    -dontobfuscate
    -printmapping
    -applymapping
    -obfuscationdictionary
    -classobfuscationdictionary
    -packageobfuscationdictionary
    -useuniqueclassmembernames
    -dontusemixedcaseclassnames
    -keeppackagenames
    -flattenpackagehierarchy
    -repackageclasses
    -keepattributes
    -adaptclassstrings

Repackaging Support

Jack is compatible with "rule" rule types, but is not compatible with "zap" or "keep" rule types. Rule files can be specified on the command line through the "—config-jarjar" option.

Using Gradle

Android Gradle plugin support is under development and there are some limitations:

  • The "-applymapping" obfuscation directive is not yet supported
  • Repackaging (similar to the jarjar tool) is not integrated
  • Jacoco instrumentation is not supported
  • Bytecode manipulation is not supported
  • Some users may receive an Out Of Memory exception while building very large apps. You can resolve this by configuring the build system to use 2G of RAM (or more):
dexOptions { javaMaxHeapSize "2048M" }

Now let's go to the useJack tool. Firstly we have to import an existing Android Application Project in Eclipse IDE as shown below.

Using JACK

  1. Click File -> Click Import… (Figure 1)

    File import
    Figure 1

  2. Click 'Existing Android Code Into Workspace' (Figure 2)

    Existing file
    Figure 2

  3. Click Browse… and select the Hello-jni project from the NDK samples directory (Figure 3)

    Browse
    Figure 3

  4. Finally click Finish (Figure 4)

    Finish
    Figure 4

Now we need to edit Application.mk file in the jni directory as follows:

APP_ABI := x86

Then we have to create file build.gradle for our Android Project as shown below.

  1. Right-click on the project. Then select New and click File (Figure 5)
     

    New file
    Figure 5

  2. Enter build.gradle to the File Name field and Click Finish (Figure 6)

    build.gradle
    Figure 6

Next we need to edit the build.gradle file as follows:

buildscript {
    repositories {
        mavenCentral()
    }
    dependencies {
        classpath 'com.android.tools.build:gradle:1.0.0'
    }
}
apply plugin: 'com.android.application'

android {
    lintOptions {
		abortOnError false
    }

    compileSdkVersion 21
    buildToolsVersion "21.1.2"

    defaultConfig {
    	applicationId "com.example.hellojni"
        minSdkVersion 19
		targetSdkVersion 21
		ndk {
            moduleName "hello-jni"
        }
    }

    sourceSets {
        main {
            manifest.srcFile 'AndroidManifest.xml'
            java.srcDirs = ['src']
            resources.srcDirs = ['src']
            aidl.srcDirs = ['src']
            renderscript.srcDirs = ['src']
            res.srcDirs = ['res']
            assets.srcDirs = ['assets']
            jni.srcDirs = []
    		jniLibs.srcDirs = ['libs']
        }

        debug.setRoot('build-types/debug')
        release.setRoot('build-types/release')
    }

    task buildNative(type: Exec, description: 'Compile JNI source via NDK') {
        def ndkDir = android.plugin.ndkFolder
        commandLine "$ndkDir/ndk-build",'-C', file('src/com/example/hellojni').absolutePath,'-j', Runtime.runtime.availableProcessors(),'all','NDK_DEBUG=1'
    }

    task cleanNative(type: Exec, description: 'Clean JNI object files') {
        def ndkDir = android.plugin.ndkFolder
        commandLine "$ndkDir/ndk-build",'-C', file('src/com/example/hellojni').absolutePath,'clean'
    }

    clean.dependsOn 'cleanNative'

    tasks.withType(JavaCompile) {
        compileTask -> compileTask.dependsOn buildNative
    }
}

Notice that the file contains the experimental Jack build tools as useJack = true.

Also to compile the native part of the sample we have to create a local.properties file at the root of the project and edit the file adding the next line:

ndk.dir=<path_to_ndk>

Finally to build the project we will use the next command:

gradle build

After you have seen the message "BUILD SUCCESSFUL" in the directory <path_to_project>/build/outputs/apk/ we can see apk-files.
Run hello-jni-debug.apk (Figure 7).

BUILD SUCCESSFUL
Figure 7

About The Author

Denis Smirnov (denis.smirnov@intel.com) is a Software Intern and has worked at Intel as a Technical Intern. Denis is getting his master's degree in Computer Science in the Nizhny Novgorod State Technical University in the department Applied Mathematics.


Intel® XDK FAQs - Cordova

$
0
0
Q1: How do I set app orientation?

If you are using Cordova* 3.X build options (Crosswalk* for Android*, Android*, iOS*, etc.), you can set the orientation under the Projects panel > Select your project > Cordova* 3.X Hybrid Mobile App Settings - Build Settings. Under the Build Settings, you can set the Orientation for your desired mobile platform.  

If you are using the Legacy Hybrid Mobile App Platform build options (Android*, iOS* Ad Hoc, etc.), you can set the orientation under the Build tab > Legacy Hybrid Mobile App Platforms Category- <desired_mobile_platform> - Step 2 Assets tab. 

[iPad] Create a plugin (directory with one file) that only has a config xml that includes the following: 

<config-file target="*-Info.plist" parent="UISupportedInterfaceOrientations~ipad" overwrite="true"><string></string></config-file><config-file target="*-Info.plist" parent="UISupportedInterfaceOrientations~ipad" overwrite="true"><array><string>UIInterfaceOrientationPortrait</string></array></config-file> 

Add the plugin on the build settings page. 

Alternatively, you can use this plugin: https://github.com/yoik/cordova-yoik-screenorientation. You can import it as a third-party Cordova* plugin using the Cordova* registry notation:

  • net.yoik.cordova.plugins.screenorientation (includes latest version at the time of the build)
  • net.yoik.cordova.plugins.screenorientation@1.3.2 (specifies a version)

Or, you can reference it directly from the GitHub repo: 

The second reference provides the git commit referenced here (we do not support pulling from the PhoneGap registry).

Q2: Is it possible to create a background service using Intel XDK?

Background services require the use of specialized Cordova* plugins that need to be created specifically for your needs. Intel XDK does not support development or debug of plugins, only the use of them as "black boxes" with your HTML5 app. Background services can be accomplished using Java on Android or Objective C on iOS. If a plugin that backgrounds the functions required already exists (for example, this plugin for background geo tracking), Intel XDK’s build system will work with it.

Q3: How do I send an email from my App?
You can use the Cordova* email plugin or use web intent - PhoneGap* and Cordova* 3.X.
Q4: How do you create an offline application?
You can use the technique described here by creating an offline.appcache file and then setting it up to store the files that are needed to run the program offline. Note that offline applications need to be built using the Cordova* or Legacy Hybrid build options.
Q5: How do I work with alarms and timed notifications?
Unfortunately, alarms and notifications are advanced subjects that require a background service. This cannot be implemented in HTML5 and can only be done in native code by using a plugin. Background services require the use of specialized Cordova* plugins that need to be created specifically for your needs. Intel XDK does not support the development or debug of plugins, only the use of them as "black boxes" with your HTML5 app. Background services can be accomplished using Java on Android or Objective C on iOS. If a plugin that backgrounds the functions required already exists (for example, this plugin for background geo tracking) the Intel XDK’s build system will work with it. 
Q6: How do I get a reliable device ID? 
You can use the Phonegap/Cordova* Unique Device ID (UUID) plugin for Android*, iOS* and Windows* Phone 8. 
Q7: How do I implement In-App purchasing in my app?
There is a Cordova* plugin for this. A tutorial on its implementation can be found here. There is also a sample in Intel XDK called ‘In App Purchase’ which can be downloaded here.
Q8: How do I install custom fonts on devices?
Fonts can be considered as an asset that is included with your app, not shared among other apps on the device just like images and CSS files that are private to the app and not shared. It is possible to share some files between apps using, for example, the SD card space on an Android* device. If you include the font files as assets in your application then there is no download time to consider. They are part of your app and already exist on the device after installation.
Q9: How do I access the device’s file storage?
You can use HTML5 local storage and this is a good article to get started with. Alternatively, there is a Cordova* file plugin for that.
Q10: Why isn't AppMobi* push notification services working?
This seems to be an issue on AppMobi’s end and can only be addressed by them. PushMobi is only available in the "legacy" container. AppMobi* has not developed a Cordova* plugin, so it cannot be used in the Cordova* build containers. Thus, it is not available with the default build system. We recommend that you consider using the Cordova* push notification plugin instead.
Q11: How do I configure an app to run as a service when it is closed?
If you want a service to run in the background you'll have to write a service, either by creating a custom plugin or writing a separate service using standard Android* development tools. The Cordova* system does not facilitate writing services.
Q12: How do I dynamically play videos in my app?

1) Download the Javascript and CSS files from https://github.com/videojs

2) Add them in the HTML5 header. 

<config-file target="*-Info.plist" parent="UISupportedInterfaceOrientations~ipad" overwrite="true"><string></string></config-file><config-file target="*-Info.plist" parent="UISupportedInterfaceOrientations~ipad" overwrite="true"><array><string>UIInterfaceOrientationPortrait</string></array></config-file> 

 3) Add a panel ‘main1’ that will be playing the video. This panel will be launched when the user clicks on the video in the main panel.

<div class=”panel” id=”main1” data-appbuilder-object=”panel” style=””><video id=”example_video_1” class=”video-js vjs-default-skin” controls=”” preload=”auto” width=”200” poster=”camera.png” data-setup=”{}”><source src=”JAIL.mp4” type=”video/mp4”><p class=”vjs-no-js”>To view this video please enable JavaScript*, and consider upgrading to a web browser that <a href=http://videojs.com/html5-video-support/ target=”_blank”>supports HTML5 video</a></p></video><a onclick=”runVid3()” href=”#” class=”button” data-appbuilder-object=”button”>Back</a></div>

 4) When the user clicks on the video, the click event sets the ‘src’ attribute of the video element to what the user wants to watch. 

Function runVid2(){

      Document.getElementsByTagName(“video”)[0].setAttribute(“src”,”appdes.mp4”);

      $.ui.loadContent(“#main1”,true,false,”pop”);

}

 5) The ‘main1’ panel opens waiting for the user to click the play button.

Note: The video does not play in the emulator and so you will have to test using a real device. The user also has to stop the video using the video controls. Clicking on the back button results in the video playing in the background.

Q13: How do I design my Cordova* built Android* app for tablets?
This page lists a set of guidelines to follow to make your app of tablet quality. If your app fulfills the criteria for tablet app quality, it can be featured in Google* Play's "Designed for tablets" section.
Q14: How do I resolve icon related issues with Cordova* CLI build system?

Ensure icon sizes are properly specified in the intelxdk.config.additions.xml. For example, if you are targeting iOS 6, you need to manually specify the icons sizes that iOS* 6 uses. 

<icon platform="ios" src="images/ios/72x72.icon.png" width="72" height="72" /><icon platform="ios" src="images/ios/57x57.icon.png" width="57" height="57" />

These are not required in the build system and so you will have to include them in the additions file. 

For more information on adding build options using intelxdk.config.additions.xml, visit: /en-us/html5/articles/adding-special-build-options-to-your-xdk-cordova-app-with-the-intelxdk-config-additions-xml-file

Q15: Is there a plugin I can use in my App to share content on social media?

Yes, you can use the PhoneGap Social Sharing plugin for Android*, iOS* and Windows* Phone.

Q16: Iframe does not load in my app. Is there an alternative?
Yes, you can use the inAppBrowser plugin instead.
Q17: Why are intel.xdk.istablet and intel.xdk.isphone not working?
Those properties are quite old and is based on the legacy AppMobi* system. An alternative is to detect the viewport size instead. You can get the user’s screen size using screen.width and screen.height properties (refer to this article for more information) and control the actual view of the webview by using the viewport meta tag (this page has several examples). You can also look through this forum thread for a detailed discussion on the same.
Q18: How do I work with the App Security plugin on Intel XDK?

Select the App Security plugin on the plugins list of the Project tab and build your app as a Cordova Hybrid app. Building it as a Legacy Hybrid app has been known to cause issues when compiled and installed on a device.

Q19: Why does my build fail with Admob plugins? Is there an alternative?

Intel XDK does not support the library project that has been newly introduced in the com.google.playservices@21.0.0 plugin. Admob plugins are dependent on "com.google.playservices", which adds Google* play services jar to project. The "com.google.playservices@19.0.0" is a simple jar file that works quite well but the "com.google.playservices@21.0.0" is using a new feature to include a whole library project. It works if built locally with Cordova CLI, but fails when using Intel XDK.

To keep compatible with Intel XDK, the dependency of admob plugin should be changed to "com.google.playservices@19.0.0".

Q20: Why does the intel.xdk.camera plugin fail? Is there an alternative?
There seem to be some general issues with the camera plugin on iOS*. An alternative is to use the Cordova camera plugin, instead and change the version to 0.3.3.
Q21: How do I resolve Geolocation issues with Cordova?

Give this app a try, it contains lots of useful comments and console log messages. However, use Cordova 0.3.10 version of the geo plugin instead of the Intel XDK geo plugin. Intel XDK buttons on the sample app will not work in a built app because the Intel XDK geo plugin is not included. However, they will partially work in the Emulator and Debug. If you test it on a real device, without the Intel XDK geo plugin selected, you should be able to see what is working and what is not on your device. There is a problem with the Intel XDK geo plugin. It cannot be used in the same build with the Cordova geo plugin. Do not use the Intel XDK geo plugin as it will be discontinued.

Geo fine might not work because of the following reasons:

  1. Your device does not have a GPS chip
  2. It is taking a long time to get a GPS lock (if you are indoors)
  3. The GPS on your device has been disabled in the settings

Geo coarse is the safest bet to quickly get an initial reading. It will get a reading based on a variety of inputs, but is usually not as accurate as geo fine but generally accurate enough to know what town you are located in and your approximate location in that town. Geo coarse will also prime the geo cache so there is something to read when you try to get a geo fine reading. Ensure your code can handle situations where you might not be getting any geo data as there is no guarantee you'll be able to get a geo fine reading at all or in a reasonable period of time. Success with geo fine is highly dependent on a lot of parameters that are typically outside of your control.

Q22: Is there an equivalent Cordova* plugin for intel.xdk.player.playPodcast? If so, how can I use it?

Yes, there is and you can find the one that best fits the bill from the Cordova* plugin registry.

To make this work you will need to do the following:

  • Detect your platform (you can use uaparser.js or you can do it yourself by inspecting the user agent string)
  • Include the plugin only on the Android* platform and use <video> on iOS*.
  • Create conditional code to do what is appropriate for the platform detected 

You can force a plugin to be part of an Android* build by adding it manually into the additions file. To see what the basic directives are to include a plugin manually:

  1. Include it using the "import plugin" dialog, perform a build and inspect the resulting intelxdk.config.android.xml file.
  2. Then remove it from your Project tab settings, copy the directive from that config file and paste it into the intelxdk.config.additions.xml file. Prefix that directive with <!-- +Android* -->. 

More information is available here and this is what an additions file can look like:

<preference name="debuggable" value="true" /><preference name="StatusBarOverlaysWebView" value="false" /><preference name="StatusBarBackgroundColor" value="#000000" /><preference name="StatusBarStyle" value="lightcontent" /><!-- -iOS* --><intelxdk:plugin intelxdk:value="nl.nielsad.cordova.wifiscanner" /><!-- -Windows*8 --><intelxdk:plugin intelxdk:value="nl.nielsad.cordova.wifiscanner" /><!-- -Windows*8 --><intelxdk:plugin intelxdk:value="org.apache.cordova.statusbar" /><!-- -Windows*8 --><intelxdk:plugin intelxdk:value="https://github.com/EddyVerbruggen/Flashlight-PhoneGap-Plugin" />

This sample forces a plugin included with the "import plugin" dialog to be excluded from the platforms shown. You can include it only in the Android* platform by using conditional code and one or more appropriate plugins.

Q23: How do I display a webpage in my app without leaving my app?

The most effective way to do so is by using inAppBrowser.

Q24: Does Cordova* media have callbacks in the emulator?

While Cordova* media objects have proper callbacks when using the debug tab on a device, the emulator doesn't report state changes back to the Media object. This functionality has not been implemented yet. Under emulation, the Media object is implemented by creating an <audio> tag in the program under test. The <audio> tag emits a bunch of events, and these could be captured and turned into status callbacks on the Media object.

Q25: Why does the Cordova version not match between the Projects tab Build Settings, Emulate tab, App Preview and my built app?

This is due to the difficulty in keeping different components in sync and is compounded by the version convention that the Cordova project uses to distinguish build tools (the CLI version) from frameworks (the Cordova version) and plugins.

The CLI version you specify in the Projects tab Build Settings section is the "Cordova CLI" version that the build system will use to build your app. Each version of the Cordova CLI tools come with a set of "pinned" Cordova framework versions, which vary as a function of the target platform. For example, the Cordova CLI 5.0 platformsConfig file is "pinned" to the Android Cordova framework version 4.0.0, the iOS Cordova framework version 3.8.0 and the Windows 8 Cordova framework version 3.8.1 (among other targets). The Cordova CLI 4.1.2 platformsConfig file is "pinned" to Android Cordova 3.6.4, iOS Cordova 3.7.0 and Windows 8 Cordova 3.7.1.

This means that the Cordova framework version you are using "on device" with a built app will not equal the version number that is in the CLI field that you specified in the Build Settings section of the Projects tab when you built your app. Technically, the target-specific Cordova frameworks can be updated [independently] within a given version of CLI tools, but our build system always uses the Cordova framework versions that were "pinned" to the CLI when it was released (that is, the Cordova framework versions specified in the platformsConfig file).

The reason you may see Cordova framework version differences between the Emulate tab, App Preview and your built app is:

  • The Emulate tab has one specific Cordova framework version it is built against. We try to make that version of the Cordova framework match as closely the default Intel XDK version of Cordova CLI.
  • App Preview is released independently of the Intel XDK and, therefore, may support a different version than what you will see reported by the Emulate tab and your built app. Again, we try to release App Preview so it matches the version of the Cordova framework that is the default version of the Intel XDK at the time App Preview is released; but since the various tools are not released in perfect sync, that is not always possible.
  • Your app always uses the Cordova framework version that is determined by the Cordova CLI version you specified in the Projects tab's Build Settings section, when you built your app.
  • BTW: the version of the Cordova framework that is built into Crosswalk is determined by the Crosswalk project, not by the Intel XDK build system. There is some customization the Crosswalk project team must do to the Cordova framework to include Cordova as part of the Crosswalk runtime engine. The Crosswalk project team generally releases each Crosswalk version with the then current version of the Android Cordova framework. Thus, the version of the Android Cordova framework that is included in your Crosswalk build is determined by the version of Crosswalk you choose to build against.

Do these Cordova framework version numbers matter? Not that much. There are some issues that come up that are related to the Cordova framework version, but they tend to be few and far between. The majority of the bugs and compatibility issues you will experience in your app have more to do with the versions and mix of Cordova plugins you choose and the specific webview present on your test devices. See this blog for more details about what a webview is and why the webview matters to your app: When is an HTML5 Web App a WebView App?.

p.s. The "default version" of the CLI that the Intel XDK uses is rarely the most recent version of the Cordova CLI tools distributed by the Cordova project. There is always a lag between Cordova project releases and our ability to incorporate those releases into our build system and the various Intel XDK components. Also, we are unable to implement every release that is made by the Cordova project; thus the reason why we do not support every Cordova release that is available to Cordova CLI users.

Q26: How do I add a third party plugin?
Please follow the instructions on this doc page to add a third-party plugin: Adding Plugins to Your Intel® XDK Cordova* App -- this plugin is not being included as part of your app. You will see it in the build log if it was successfully added to your build.
Q27: How do I make an AJAX call that works in my browser work in my app?
Please follow the instructions in this article: Cordova CLI 4.1.2 Domain Whitelisting with Intel XDK for AJAX and Launching External Apps.
Q28: I get an "intel is not defined" error, but my app works in Test tab, App Preview and Debug tab. What's wrong?

When your app runs in the Test tab, App Preview or the Debug tab the intel.xdk and core Cordova functions are automatically included for easy debug. That is, the plugins required to implement those APIs on a real device are already included in the corresponding debug modules.

When you build your app you must include the plugins that correspond to the APIs you are using in your build settings. This means you must enable the Cordova and/or XDK plugins that correspond to the APIs you are using. Go to the Projects tab and insure that the plugins you need are selected in your project's plugin settings. See Adding Plugins to Your Intel® XDK Cordova* App for additional details.

Q29: How do I target my app for use only on an iPad or only on an iPhone?

There is an undocumented feature in Cordova that should help you (the Cordova project provided this feature but failed to document it for the rest of the world). If you use the appropriate preference in the intelxdk.config.additions.xml file you should get what you need:

<preference name="target-device" value="tablet" />     <!-- Installs on iPad, not on iPhone --><preference name="target-device" value="handset" />    <!-- Installs on iPhone, iPad installs in a zoomed view and doesn’t fill the entire screen --><preference name="target-device" value="universal" />  <!-- Installs on iPhone and iPad correctly -->

If you need info regarding the additions.xml file, see the blank template or this doc file: Adding Intel® XDK Cordova Build Options Using the Additions File.

Back to FAQs Main 

Optimizing Unity* Games on Android* OS for Intel® Architecture: A Case Study

$
0
0

Download Document

Unity* is one of the most popular game engines for the mobile environment (Android* and iOS*), and many developers are using it to develop and launch games. Before Unity supported Android on Intel platforms, games were executed on an emulator that changed ARM* native code to Intel native code. Some non-native x86 games running on Intel platforms did not work at all and others had performance issues. With the growth in mobile market share of Intel processors, many developers are now interested in supporting Android on x86 architecture and want to know how to optimize their games.

This article will show a performance gain with native support on Android and share some tips for increasing performance on Intel® architecture using Hero Sky: Epic Guild Wars as an example.


Figure 1. Hero Sky: Epic Guild Wars

Innospark, maker of Hero Sky: Epic Guild Wars, has significant experience in mobile game development using a variety of commercial game engines and also has its own in-house game engine. Hero Sky: Epic Guild Wars is its first Unity-based game launched for the global market. With an increasing number of downloads from the Google Play* store, the company began to get complaints that the game did not work and that it lagged on some Intel processor-based devices with Android . So Innospark decided to port and optimize the game for Android OS on Intel architecture. This article explains what Innospark did for optimization with profiling results from Intel® Graphics Performance Analyzers (Intel® GPA), like changing drawing order and removing unneeded alpha blending.

Introduction

Hero Sky: Epic Guild Wars is an online combat strategy style game supporting full 3D graphics. Innospark developed and optimized it on an Intel® Atom™ processor-based platform (code named Bay Trail). The Bay Trail reference design and specifications are listed below.

CPU

Intel® Atom™ processor

Quad Core 1.46 Ghz

OS

Android* 4.4.4

RAM

2GB

Resolution

1920x1200

3DMark* ICE Storm Unlimited Score

10,386

Graphics score

9,274

Physics score

17,899

Table 1. Bay Trail 8” reference design specification and 3DMark* score

Below is a graph showing a performance comparison between non-native x86 and native x86 code on the Bay Trail reference design.


Figure 2. Performance gains with x86 native support

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark* and MobileMark*, are measured using specific computer systems, components, software, operations and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products. For more information go to http://www.intel.com/performance.

After the game was ported for Android on Intel architecture, the CPU load decreased about 7.1%, FPS increased about 27.8% and execution time decreased about 32.6%. However, GPU Busy increased about 26.7% because FPS increased.

Innospark used Intel GPA to find CPU and GPU bottlenecks during development and used the analysis to solve graphics issues and performance.

Intel GPA System Analyzer measured 59.01 FPS as the baseline performance. Graphics Frame Analyzer, which measures FPS only on the GPU side, measured 120.9 FPS. The reason the FPSs are different is that System Analyzer is monitoring live activity of the process, which includes both CPU and GPU work and Graphics Frame Analyzer includes GPU-related work with the CPU activities directly related to submission of data to the driver and GPU.

Deep-dive analysis using Graphics Frame Analyzer


Figure 3 Screen capture of the baseline version

After being ported, the game showed 59.01 FPS. We analyzed it in more detail using the Graphics Frame Analyzer in order to decrease the GPU Busy and CPU Load. The tables below show the information captured using the Graphics Frame Analyzer.

Total Primitive Count

4,376

GPU Duration, ms

8.56 ms

Time to show frame, ms

9.35 ms

Table 2. Baseline frame information

 

Type

Erg

GPU Duration (ms)

GPU Memory Read(MB)

GPU Memory Write(MB)

Sky

1

1.43 ms

0.2 MB

7.6 MB

Terrain

5

1.89 ms

9.4 MB

8.2 MB

Table 3. The high draw call cost of the baseline version

 

Analyze and optimize high draw call

Remove unneeded alpha blending


When a display object uses alpha blending, the runtime must combine the color values of every stacked display object and the background color to determine the final color. Thus, alpha blending can be more processor-intensive than drawing an opaque color. This extra computation can hurt performance on slow devices. So we want to remove unneeded alpha blending.

The Graphics Frame Analyzer can enable or disable each drawing call so a developer can test and measure without source modification. This feature is in the Blend State tab under the State tab.


Figure 4. How to experiment Enable/Disable alpha blending on Graphics Frame Analyzer without source modification.

The table below shows more detailed information about drawing call of the grass after disabled alpha blending and the GPU Duration of the grass is decreased about 26.0%. Also notice that the GPU Memory Read is decreased about 97.2%.

 

Baseline

Changed drawing order(sky)

GPU Clocks

1,466,843

1,085,794.5

GPU Duration, us

1,896.6 us

1,398.4 us

GPU Memory Read, MB

7.6 MB

0.2 MB

GPU Memory Write, MB

8.2 MB

8.2 MB

Table 4. Detailed information of drawing call after disabled alpha blending

 

Apply Z-culling efficiently


When an object is rendered by the 3D graphics card, the 3D data is changed into 2D data (x-y), and the Z-buffer, or depth buffer, is used to store the depth information (z coordinate) of each screen pixel. If two objects of the scene must be rendered in the same pixel, the GPU compares the two depths and overrides the current pixel if the new object is closer to the observer. The process of Z-culling reproduces the usual depth perception correctly by drawing the closest objects first so that a closer object hides a farther one. Z-culling provides performance improvement when rendering hidden surfaces.

Game has two kinds of terrain drawing: sky and grass drawing. The Erg 1 drawing call is for the sky and Erg 5 is the drawing call for the grass. Because large portions of sky are behind grass, lots of sky areas never show during the game. However, the sky was rendered earlier than the grass, which prevented efficient Z-culling.


Figure 5. Drawing call for sky(erg 1) and grass(erg5)

Below is the GPU duration of the sky after changing the drawing order.


Figure 6. Result after changing the drawing order of sky on Graphics Frame Analyzer.

The table below shows more detailed information about the sky after changing the drawing order, and the GPU Duration of grass is decreased about 88.0%. Notice how the GPU Memory Write is decreased about 98.9%.

 

Baseline

Changed drawing order(sky)

GPU Clocks

1,113,276

133,975

GPU Duration, us

1,433 us

174.2 us

Early Z Failed

0

2,145,344

Sample Written

2,165,760

20,416

GPU Memory Read, MB

0.2 MB

0.0 MB

GPU Memory Write, MB

9.4 MB

0.1 MB

Table 5. Detailed information of drawing call after changed drawing order(sky)

 

Results

The next table shows the more detailed data of x86 optimization after removing unneeded alpha blending and changing the drawing order. GPU Duration is decreased about 25% and GPU Memory Read/Write is decreased about 42.6% and 30.0%, respectively. System Analyzer showed the FPS only increased 1.06 because Android uses vsync mode and max FPS is 60 fps, but the FPS on Graphics Frame Analyzer increased about 29.7%.

 

X86 Baseline

X86 optimized

GPU Clocks

6,654,210

4,965,478

GPU Duration, us

8,565.2 us

6,386 us

Early Z Failed

16,592

2,248,450

Sample Written

6,053,311

2,813,997

GPU Memory Read, MB

20.9 MB

12.0 MB

GPU Memory Write, MB

28.6 MB

20.0 MB

FPS on System Analyzer

59.01

60.07

FPS on Graphics Frame Analyzer

120.9

156.8

Table 6. Performance gains after disable alpha blending and changed drawing order(sky)

 


Figure 7. Performance gains after optimized x86 native support

Conclusion

When you start to optimize a game on Android x86, first developers should port their games for Android x86 and next determine where the application bottleneck is. Profiling tools can help you measure performance and see more easily where performance issues are on the GPU side. Intel GPA’s powerful analytic tools can provide the ability to experiment without any source modification.

About the Authors

Jackie Lee is an Applications Engineer with Intel's Software Solutions Group, focused on performance tuning of applications on Intel Atom platforms. Prior to Intel, Jackie Lee worked at LG in the electronics CTO department. He received his MS and BS in Computer Science and Engineering from ChungAng University.

References


Intel® Graphics Performance Analyzers
https://software.intel.com/en-us/gpa

Innospark
http://www.innospark.com/#!home-en/c1vtc

Hero Sky: Epic Guild Wars
https://play.google.com/store/apps/details?id=com.innospark.herosky

Unity
http://unity3d.com

Unity Native X86 Support Shines for Square Enix’s Hitman GO*
https://software.intel.com/en-us/articles/unity-native-x86-support-shines-for-square-enix-s-hitman-go

Alpha Blending
http://help.adobe.com/en_US/as3/mobile/WS4bebcd66a74275c36c11f3d612431904db9-7ffe.html

Marmalade C++ and ShiVa3D: a Game Engine Guide for Android x86

$
0
0

Download Document

Building a cross-platform Android app? Previously, we shared how to add x86 Support to Android* Apps Using the Unity* Game Engine , as well as use game development suites like Unreal* Engine 4. However, in this guide we will detail a step-by-step process of building a cross-platform Android application with the help of Marmalade C++ SDK 7.1 and ShiVa3D game engine specifically for Android x86 architecture.

Marmalade C++ SDK

The Marmalade SDK is a cross-platform software development kit that contains library files, samples, documentation, and tools required to develop, test, and deploy applications for mobile devices.

The underlying concept of the Marmalade SDK is “write once, run anywhere” so that a single codebase can be compiled and executed on all supported platforms rather than writing in different programming languages using a different API for each platform. This is achieved by providing a C/C++ based API that acts as an abstraction layer for the core API of each platform.

The Marmalade SDK comes in a package that contains sample projects and tutorials and also has online documentation.

Setting Up

Below are the steps for using Marmalade on a Windows* platform. For Mac OS*, please refer to this documentation.

For Windows platforms, before actually installing the Marmalade SDK, the following prerequisites are necessary:

  • Windows 7 or above
  • JRE 5 or new version must be installed.
  • Microsoft Visual Studio* 2008SP/2010/2012 Express/Pro editions
  • (C++), Scons (C++), and ZeroBrane (Lua) need to be present
  • Android ADT bundle
  • Android NDK
  • Apache Ant (optional)

A few environment values need to be updated before you can start to build the project:

  • Set ANDROID_SDK_ROOT = Give the complete path to the SDK folder. For example: in my case, I downloaded and extracted the ADT bundle in D:\android\, so my path is: D:\android\adt-bundle-windows-x86_64-20131030\sdk
  • Set NDK_ROOT = the complete path to the NDK folder, my path is: D:\android\android-ndk-r9b
  • Set JAVA_HOME = the path where you have the JAVA JDK installed, for me it is: C:\Program Files\Java\jdk1.7.0_45
  • Set ANT_HOME = the path where you have Apache Ant installed, my path is: C:\ant\apache-ant-1.9.2
  • Update the Path variable to contain the following = path to the JDK folder, JDK bin folder, NDK, path to Ant bin folder, SDK tools folder, and SDK platform-tools folder, each separated by a semi-colon (;). For example, in my case, I will add the following:

    %ANT_HOME%\bin;C:\Program Files\Java\jdk1.7.0_40\bin;D:\android\adt-bundle-windows-x86_64-20131030\sdk\tools;D:\android\adt-bundle-windows-x86_64-20131030\sdk\platform-tools;%JAVA_HOME%\bin

    NOTE: Do not end any variable with \ or ` or any special character.

Now you’re ready to download the Marmalade SDK.

Development for Android x86 Using the Marmalade SDK

Marmalade offers three ways of creating a project:

I. Manually
II. Through a command line
III. Through Marmalade Hub

Below are the steps to create the Hello World project using these processes.

NOTE: The path to the project folder will be referred to as: {$PROJECT PATH}. For example, if the project is in D:\Marmalade_Projs, it is:

{$PROJECT PATH} = D:\Marmalade_Projs

Manually using IDE

To manually make a Hello World project, you have to make the following two files:

  1. HelloWorld.mkb

    Marmalade uses a plain text file format with the extension .MKB to store information about your project, including:

    • Build options
    • Sub-projects
    • Source files
    • Assets (graphics, audio, etc.)
    • Deployment options

    For in-depth knowledge of MKB files, refer to the official documentation.

  2. HelloWorld.cpp

    This will contain the source code of the application.

Steps for running the project:

  1. Navigate to the HelloWorld.mkb file that you created earlier and double-click it.
  2. You will see that it will perform a lot of functions and auto-generate two new sub-folders containing the build files.
  3. The generated Visual Studio project will then be opened in Microsoft Visual Studio for editing, compiling, and/or testing of the project, as shown below:


     
  4. To compile and run using the Marmalade’s x86 simulator, make the following changes:
    1. Click Debug > HelloWorld_vc11x Properties…


       
    2. The following window will open. Then click Configuration Manager (circled on the screen below):


       
    3. Choose the x86 Debug option from the drop-down menu as shown below then click the Close button:


       
    4. Now, click the Debug > Start Debugging option as shown below:


       
    5. You may get an alert as shown below, click Yes:


       
    6. If a warning comes as shown below, again click Yes:


       
    7. The project will debug and run successfully with the following output:


       

Using the Command Line

  1. Open the command prompt.
  2. Navigate to the project directory.
  3. Issue the following command:
    >>mkb.bat Hello.mkb --execute --rebuild
    This will rebuild the project for all variants (ARM and x86).
  4. Configure the option for x86 in the mkb file as follows:
    option
    {
    android-x86
    }
    D:\MarmaladeProject> mkb.bat Hello.mkb --execute --debug
    D:\MarmaladeProject> mkb.bat Hello.mkb --execute --Release

    These will build the project for the variants selected.

    Important: for running in command line, please append s3e binary path to system PATH env,
    For example: set PATH=%PATH%;D:\Marmalade\7.0\s3e\bin;
    or update the PATH system variable found at
    MyComputer->Properties->AdvancedSystemSettings->Advanced->Environment Variables->System variables to contain the s3e binary path

Through Marmalade Hub

Locate “Marmalade Hub” in your Windows Start menu and run it.

When the window comes, click “Marmalade C++” as shown below (left):

If a welcome screen (as shown above right) is displayed, click Close to continue as shown (circled). Then click the Create New Project button as shown below:

After that, you will find the following form:

  1. Project Name: Enter the name of the project. In this case, it is HelloWorld1.
  2. Create In: Enter the folder in which the project is to be created (equivalent to {$PROJECT PATH} in the manual process).

Then click the Create Project button. You will see the following screen:

Marmalade Hub does not enable editing of source files but instead offers an Open in IDE feature that will open the project using the default IDE where you can edit source files. Click the Open in IDE button to open the project in Visual Studio.

To debug and run the project, follow Step 4 in the Steps to Run in the Manual section mentioned earlier in the document. After successful execution, you can run the app by clicking the Run button in the Marmalade Hub screen as shown below:

Output or Binaries:

Once the build procedure is complete, assuming the Visual Studio Xpress 2010 is installed on the host, the binaries are generated as follows:

  1. <projectfolder>/build_<projectName>_vc10x/Debug_IwGx<projectName>_vc10x_gcc_X86_android/IwGx<projectName>.so
  2. <projectfolder>/build_<projectName>_vc10x/Debug_IwGx<projectName>_vc10x_gcc_X86_android/IwGx<projectName>.obj

For example:

  1. C:/Marmalade/7.0/examples/HelloWorld/build_iwgxhelloworld_vc10x/Debug_IwGxHelloWorld_vc10x_gcc_X86_android/IwGxHelloWorld.so
  2. C:/Marmalade/7.0/examples/HelloWorld/build_iwgxhelloworld_vc10x/Debug_IwGxHelloWorld_vc10x_gcc_X86_android/IwGxHelloWorld.obj

Marmalade SDK (7.1) supports only individual APKs based on the option specified/configured for the build in the run Configuration in the IDE or the options tag in the mkb file, but does not support FAT binaries, i.e., the APKs can be generated for either x86 or ARM, one at a time.

Once you generate multiple APKs, you can submit them to the Google Play* store using multiple APK support. This feature allows you to publish different APKs for your application that are targeted to x86 CPU architecture.

ShiVa3D* Game Engine

The ShiVa3D Game Engine is different than Marmalade. ShiVa3D is a 3D game engine with a graphical editor designed to create applications and video games for the Web, consoles, and mobile devices.

It can produce games and 3D graphical simulations for Windows, Mac OS, Linux*, iPhone*, iPad*, BlackBerry* Tablet OS/BlackBerry 10, Android, Palm OS, Wii*, and WebOS, standalone or embedded in web browsers.

The game engine uses OpenGL*, OpenGL ES*, or DirectX*, and can also run in software mode. ShiVa3D supports industry standard plug-ins such as NVIDIA PhysX*, FMOD* sounds library, and ARToolKit.

ShiVa3D Web Edition is a free, unlimited, and full edition that can be used for testing purposes.

In addition to the editor, you have the ShiVa3D Authoring Tool that allows you to compile sources generated by the editor for Windows, Mac OS, Linux, iPhone, iPod, iPad, Android, BlackBerry QNX, and Palm.

ShiVa3D Installation

Before using ShiVa3D, you need to fulfill certain prerequisites. Please note that it is assumed that you will be developing in Windows.

  1. Windows Requirements
    1. Windows 7 or higher is required.
  2. Download list
    1. Download Android ADT Bundle
    2. Download NDK
    3. Download and install Cygwin*: Cygwin is a program that enables you to get a Linux feeling on Windows. You can install certain packages on Cygwin and have a minimal Linux-like environment. When a prompt asks to select packages, search for the packages below and install them:
      • autoconf, automake, binutils, gcc-core, gcc-g++, gcc4-core, gcc4-g++, gdb, pcre, pcre-devel, gawk, make, python

        Note: Select the GUI version of make as well; otherwise, you will not be able to build your project using NDK.
    4. Download JDK
    5. Apache Ant
    6. Microsoft Visual Studio C++ Express: Download Microsoft Visual Studio.
  3. Environmental Variables editing list
    1. Set JAVA_HOME = the path where you have the JAVA JDK installed, for me it is: C:\Program Files\Java\jdk1.7.0_45
    2. Set ANDROID_SDK_ROOT = the complete path to the SDK folder. For example: in my case, I downloaded and extracted the ADT bundle in D:\android\, so my path is: D:\android\adt-bundle-windows-x86-20131030\sdk
    3. Set NDK_ROOT = the complete path to the NDK folder, my path is: D:\android\android-ndk-r9b
    4. Set ANT_HOME = the complete path to the ANT folder, for me it is: C:\ant\apache-ant-1.9.2
    5. Update the Path variable to contain the following = path to the JDK folder, JDK bin folder, NDK, Cygwin bin folder, ANT bin folder, SDK tools folder and SDK platform-tools folder, each separated by a semi-colon (;). For example, I added the following:

      D:\cygwin64\bin;C:\Program Files\Java\jdk1.7.0_40\bin;D:\android\adt-bundle-windows-x86_64-20131030\sdk\tools;D:\android\adt-bundle-windows-x86_64-20131030\sdk\platform-tools;%JAVA_HOME%\bin;%ANT_HOME%\bin

      NOTE: Do not end any variable with \ or ` or any such special character.

Now that the prerequisites are satisfied, you can download and set up ShiVa3D in Windows.

Download ShiVa3D Web Edition

You can download ShiVa3D from: http://www.stonetrip.com/download.html

On that page you will find many options. Please choose the one corresponding to the Web edition as shown below:

This package will include the following: ShiVa Editor, ShiVa Authoring Tool, ShiVa Mobile Development Tools, ShiVa Server PLE, and ShiVa Players.

Steps to export your first application using ShiVa3D

  1. Click General > Game Editor > Game > Export… to export your application as shown below:


     
  2. Fill out the form and click Export as depicted below. My export folder is: D:\ShiVa3D_prog\game_export. You may choose any folder you prefer.



    NOTE: The export should be done as a single .stk file as shown above.

Steps to build your first application using ShiVa3D Authoring tool

  1. Close ShiVa Editor and run ShiVa3D Authoring tool. You will see a window like the one below:


     
  2. Choose the Android option by double clicking it, and a screen like the one below will display:


     
  3. Import the application exported in the previous step in the corresponding places by choosing the folder option (circled) and browsing to that file. Similarly, you can add an image for an icon or a start-up splash screen by clicking their corresponding folder icons (circled) and navigating to the desired file.


     
  4. Click the Settings option in the bottom-right (circled above), and the screen below displays:


     
  5. Add the folders for the required packages like Cygwin, Android NDK, etc. by clicking their corresponding folder icons and navigating to the appropriate folders.
  6. Then click OK, and you will return to the previous screen.
  7. Click Step 2: Authoring as shown below:


     
  8. Write the package name in the circled spot as shown below:


     
  9. Then click Step 3: Build, and a screen like the one shown below displays, where you will see the option to set the minimum Android API level, CPU support, and the output folder:


     
  10. After choosing the appropriate values, click the Build option in the lower right as shown circled above.
  11. On successful build, you will see the following screen:


     

In case of ShiVa3D, we can only build through the ShiVa3D Authoring tool, which has a GUI. There is no command-line option. The steps to configure for GUI option are documented below:

  1. How to configure for x86 platform:
    1. First, develop and export your game using ShiVa Editor. Please make sure that in the exported file you do not use any characters other than: a-z or A-Z or 0-9 or _ (any other characters will cause errors during the build). It is important that the game be first exported by the ShiVa Editor or else we will not be able to work with it using ShiVa3D Authoring tool.
    2. Now open ShiVa3D Authoring tool and double-click the Android option. Follow the steps mentioned above, with the following differences:
      When you are executing steps g-h as mentioned, you will see that there is an option called Authoring Type as shown below:



      By default, the value of this field is APK Package. If you only want the .apk package of the application that can be directly installed onto the device, then leave it as is.

      NOTE: In this case, you will not get any binary files, as they will be stored in the windows temporary folder and will be deleted once the build is completed.

      If you are instead interested in the binaries and not the .apk package, then choose the second option from the drop-down list: Project. This will ensure that a .zip file is generated that contains all the binary files. However, in this case, the .apk package file is not generated.

      The output folder for the generation of the above mentioned .apk or .zip file is specified in Step i. You will see the following window which, as you scroll down, shows the Output folder option:



      Here, you can enter the desired output folder using the folder icon and browsing to your desired folder, or typing in the full path.

      To build for the x86 platform, click the CPU support option, located just above the Output folder option as shown below. From the drop-down menu, choose the x86 option. Note that the default value of this option is Default, which needs to be changed to x86 to build the game for x86 targets.



      You might get error if the value in the Minimum OS Support field is less than API – 9. Please select an appropriate API level as shown below:


       
  2. Build outputs:

    After ensuring that you have incorporated the differences mentioned in the previous sections, you are ready to build the game for x86 target platform. The output depends on whether you chose APK Package or Project, but either one will be located in the Output folder. My output folder is: D:/ShiVa3D_prog/authoring_tool_output

    If you chose APK Package, then this folder contains one .apk file like this:

    D:\ShiVa3D_prog\authoring_tool_output\FistApp_1-debug.apk

    If you chose Project, then this folder contains one .zip file like this:

    D:\ShiVa3D_prog\authoring_tool_output\FistApp_1_Android.zip

    This .zip file will in turn contain all the required binaries, manifest files, make files, resource files, and build files.

Related Articles and Resources

Intel® XDK FAQs - Cordova

$
0
0
Q1: How do I set app orientation?

If you are using Cordova* 3.X build options (Crosswalk* for Android*, Android*, iOS*, etc.), you can set the orientation under the Projects panel > Select your project > Cordova* 3.X Hybrid Mobile App Settings - Build Settings. Under the Build Settings, you can set the Orientation for your desired mobile platform.  

If you are using the Legacy Hybrid Mobile App Platform build options (Android*, iOS* Ad Hoc, etc.), you can set the orientation under the Build tab > Legacy Hybrid Mobile App Platforms Category- <desired_mobile_platform> - Step 2 Assets tab. 

[iPad] Create a plugin (directory with one file) that only has a config xml that includes the following: 

<config-file target="*-Info.plist" parent="UISupportedInterfaceOrientations~ipad" overwrite="true"><string></string></config-file><config-file target="*-Info.plist" parent="UISupportedInterfaceOrientations~ipad" overwrite="true"><array><string>UIInterfaceOrientationPortrait</string></array></config-file> 

Add the plugin on the build settings page. 

Alternatively, you can use this plugin: https://github.com/yoik/cordova-yoik-screenorientation. You can import it as a third-party Cordova* plugin using the Cordova* registry notation:

  • net.yoik.cordova.plugins.screenorientation (includes latest version at the time of the build)
  • net.yoik.cordova.plugins.screenorientation@1.3.2 (specifies a version)

Or, you can reference it directly from the GitHub repo: 

The second reference provides the git commit referenced here (we do not support pulling from the PhoneGap registry).

Q2: Is it possible to create a background service using Intel XDK?

Background services require the use of specialized Cordova* plugins that need to be created specifically for your needs. Intel XDK does not support development or debug of plugins, only the use of them as "black boxes" with your HTML5 app. Background services can be accomplished using Java on Android or Objective C on iOS. If a plugin that backgrounds the functions required already exists (for example, this plugin for background geo tracking), Intel XDK’s build system will work with it.

Q3: How do I send an email from my App?
You can use the Cordova* email plugin or use web intent - PhoneGap* and Cordova* 3.X.
Q4: How do you create an offline application?
You can use the technique described here by creating an offline.appcache file and then setting it up to store the files that are needed to run the program offline. Note that offline applications need to be built using the Cordova* or Legacy Hybrid build options.
Q5: How do I work with alarms and timed notifications?
Unfortunately, alarms and notifications are advanced subjects that require a background service. This cannot be implemented in HTML5 and can only be done in native code by using a plugin. Background services require the use of specialized Cordova* plugins that need to be created specifically for your needs. Intel XDK does not support the development or debug of plugins, only the use of them as "black boxes" with your HTML5 app. Background services can be accomplished using Java on Android or Objective C on iOS. If a plugin that backgrounds the functions required already exists (for example, this plugin for background geo tracking) the Intel XDK’s build system will work with it. 
Q6: How do I get a reliable device ID? 
You can use the Phonegap/Cordova* Unique Device ID (UUID) plugin for Android*, iOS* and Windows* Phone 8. 
Q7: How do I implement In-App purchasing in my app?
There is a Cordova* plugin for this. A tutorial on its implementation can be found here. There is also a sample in Intel XDK called ‘In App Purchase’ which can be downloaded here.
Q8: How do I install custom fonts on devices?
Fonts can be considered as an asset that is included with your app, not shared among other apps on the device just like images and CSS files that are private to the app and not shared. It is possible to share some files between apps using, for example, the SD card space on an Android* device. If you include the font files as assets in your application then there is no download time to consider. They are part of your app and already exist on the device after installation.
Q9: How do I access the device’s file storage?
You can use HTML5 local storage and this is a good article to get started with. Alternatively, there is a Cordova* file plugin for that.
Q10: Why isn't AppMobi* push notification services working?
This seems to be an issue on AppMobi’s end and can only be addressed by them. PushMobi is only available in the "legacy" container. AppMobi* has not developed a Cordova* plugin, so it cannot be used in the Cordova* build containers. Thus, it is not available with the default build system. We recommend that you consider using the Cordova* push notification plugin instead.
Q11: How do I configure an app to run as a service when it is closed?
If you want a service to run in the background you'll have to write a service, either by creating a custom plugin or writing a separate service using standard Android* development tools. The Cordova* system does not facilitate writing services.
Q12: How do I dynamically play videos in my app?

1) Download the Javascript and CSS files from https://github.com/videojs

2) Add them in the HTML5 header. 

<config-file target="*-Info.plist" parent="UISupportedInterfaceOrientations~ipad" overwrite="true"><string></string></config-file><config-file target="*-Info.plist" parent="UISupportedInterfaceOrientations~ipad" overwrite="true"><array><string>UIInterfaceOrientationPortrait</string></array></config-file> 

 3) Add a panel ‘main1’ that will be playing the video. This panel will be launched when the user clicks on the video in the main panel.

<div class=”panel” id=”main1” data-appbuilder-object=”panel” style=””><video id=”example_video_1” class=”video-js vjs-default-skin” controls=”” preload=”auto” width=”200” poster=”camera.png” data-setup=”{}”><source src=”JAIL.mp4” type=”video/mp4”><p class=”vjs-no-js”>To view this video please enable JavaScript*, and consider upgrading to a web browser that <a href=http://videojs.com/html5-video-support/ target=”_blank”>supports HTML5 video</a></p></video><a onclick=”runVid3()” href=”#” class=”button” data-appbuilder-object=”button”>Back</a></div>

 4) When the user clicks on the video, the click event sets the ‘src’ attribute of the video element to what the user wants to watch. 

Function runVid2(){

      Document.getElementsByTagName(“video”)[0].setAttribute(“src”,”appdes.mp4”);

      $.ui.loadContent(“#main1”,true,false,”pop”);

}

 5) The ‘main1’ panel opens waiting for the user to click the play button.

Note: The video does not play in the emulator and so you will have to test using a real device. The user also has to stop the video using the video controls. Clicking on the back button results in the video playing in the background.

Q13: How do I design my Cordova* built Android* app for tablets?
This page lists a set of guidelines to follow to make your app of tablet quality. If your app fulfills the criteria for tablet app quality, it can be featured in Google* Play's "Designed for tablets" section.
Q14: How do I resolve icon related issues with Cordova* CLI build system?

Ensure icon sizes are properly specified in the intelxdk.config.additions.xml. For example, if you are targeting iOS 6, you need to manually specify the icons sizes that iOS* 6 uses. 

<icon platform="ios" src="images/ios/72x72.icon.png" width="72" height="72" /><icon platform="ios" src="images/ios/57x57.icon.png" width="57" height="57" />

These are not required in the build system and so you will have to include them in the additions file. 

For more information on adding build options using intelxdk.config.additions.xml, visit: /en-us/html5/articles/adding-special-build-options-to-your-xdk-cordova-app-with-the-intelxdk-config-additions-xml-file

Q15: Is there a plugin I can use in my App to share content on social media?

Yes, you can use the PhoneGap Social Sharing plugin for Android*, iOS* and Windows* Phone.

Q16: Iframe does not load in my app. Is there an alternative?
Yes, you can use the inAppBrowser plugin instead.
Q17: Why are intel.xdk.istablet and intel.xdk.isphone not working?
Those properties are quite old and is based on the legacy AppMobi* system. An alternative is to detect the viewport size instead. You can get the user’s screen size using screen.width and screen.height properties (refer to this article for more information) and control the actual view of the webview by using the viewport meta tag (this page has several examples). You can also look through this forum thread for a detailed discussion on the same.
Q18: How do I work with the App Security plugin on Intel XDK?

Select the App Security plugin on the plugins list of the Project tab and build your app as a Cordova Hybrid app. Building it as a Legacy Hybrid app has been known to cause issues when compiled and installed on a device.

Q19: Why does my build fail with Admob plugins? Is there an alternative?

Intel XDK does not support the library project that has been newly introduced in the com.google.playservices@21.0.0 plugin. Admob plugins are dependent on "com.google.playservices", which adds Google* play services jar to project. The "com.google.playservices@19.0.0" is a simple jar file that works quite well but the "com.google.playservices@21.0.0" is using a new feature to include a whole library project. It works if built locally with Cordova CLI, but fails when using Intel XDK.

To keep compatible with Intel XDK, the dependency of admob plugin should be changed to "com.google.playservices@19.0.0".

Q20: Why does the intel.xdk.camera plugin fail? Is there an alternative?
There seem to be some general issues with the camera plugin on iOS*. An alternative is to use the Cordova camera plugin, instead and change the version to 0.3.3.
Q21: How do I resolve Geolocation issues with Cordova?

Give this app a try, it contains lots of useful comments and console log messages. However, use Cordova 0.3.10 version of the geo plugin instead of the Intel XDK geo plugin. Intel XDK buttons on the sample app will not work in a built app because the Intel XDK geo plugin is not included. However, they will partially work in the Emulator and Debug. If you test it on a real device, without the Intel XDK geo plugin selected, you should be able to see what is working and what is not on your device. There is a problem with the Intel XDK geo plugin. It cannot be used in the same build with the Cordova geo plugin. Do not use the Intel XDK geo plugin as it will be discontinued.

Geo fine might not work because of the following reasons:

  1. Your device does not have a GPS chip
  2. It is taking a long time to get a GPS lock (if you are indoors)
  3. The GPS on your device has been disabled in the settings

Geo coarse is the safest bet to quickly get an initial reading. It will get a reading based on a variety of inputs, but is usually not as accurate as geo fine but generally accurate enough to know what town you are located in and your approximate location in that town. Geo coarse will also prime the geo cache so there is something to read when you try to get a geo fine reading. Ensure your code can handle situations where you might not be getting any geo data as there is no guarantee you'll be able to get a geo fine reading at all or in a reasonable period of time. Success with geo fine is highly dependent on a lot of parameters that are typically outside of your control.

Q22: Is there an equivalent Cordova* plugin for intel.xdk.player.playPodcast? If so, how can I use it?

Yes, there is and you can find the one that best fits the bill from the Cordova* plugin registry.

To make this work you will need to do the following:

  • Detect your platform (you can use uaparser.js or you can do it yourself by inspecting the user agent string)
  • Include the plugin only on the Android* platform and use <video> on iOS*.
  • Create conditional code to do what is appropriate for the platform detected 

You can force a plugin to be part of an Android* build by adding it manually into the additions file. To see what the basic directives are to include a plugin manually:

  1. Include it using the "import plugin" dialog, perform a build and inspect the resulting intelxdk.config.android.xml file.
  2. Then remove it from your Project tab settings, copy the directive from that config file and paste it into the intelxdk.config.additions.xml file. Prefix that directive with <!-- +Android* -->. 

More information is available here and this is what an additions file can look like:

<preference name="debuggable" value="true" /><preference name="StatusBarOverlaysWebView" value="false" /><preference name="StatusBarBackgroundColor" value="#000000" /><preference name="StatusBarStyle" value="lightcontent" /><!-- -iOS* --><intelxdk:plugin intelxdk:value="nl.nielsad.cordova.wifiscanner" /><!-- -Windows*8 --><intelxdk:plugin intelxdk:value="nl.nielsad.cordova.wifiscanner" /><!-- -Windows*8 --><intelxdk:plugin intelxdk:value="org.apache.cordova.statusbar" /><!-- -Windows*8 --><intelxdk:plugin intelxdk:value="https://github.com/EddyVerbruggen/Flashlight-PhoneGap-Plugin" />

This sample forces a plugin included with the "import plugin" dialog to be excluded from the platforms shown. You can include it only in the Android* platform by using conditional code and one or more appropriate plugins.

Q23: How do I display a webpage in my app without leaving my app?

The most effective way to do so is by using inAppBrowser.

Q24: Does Cordova* media have callbacks in the emulator?

While Cordova* media objects have proper callbacks when using the debug tab on a device, the emulator doesn't report state changes back to the Media object. This functionality has not been implemented yet. Under emulation, the Media object is implemented by creating an <audio> tag in the program under test. The <audio> tag emits a bunch of events, and these could be captured and turned into status callbacks on the Media object.

Q25: Why does the Cordova version not match between the Projects tab Build Settings, Emulate tab, App Preview and my built app?

This is due to the difficulty in keeping different components in sync and is compounded by the version convention that the Cordova project uses to distinguish build tools (the CLI version) from frameworks (the Cordova version) and plugins.

The CLI version you specify in the Projects tab Build Settings section is the "Cordova CLI" version that the build system will use to build your app. Each version of the Cordova CLI tools come with a set of "pinned" Cordova framework versions, which vary as a function of the target platform. For example, the Cordova CLI 5.0 platformsConfig file is "pinned" to the Android Cordova framework version 4.0.0, the iOS Cordova framework version 3.8.0 and the Windows 8 Cordova framework version 3.8.1 (among other targets). The Cordova CLI 4.1.2 platformsConfig file is "pinned" to Android Cordova 3.6.4, iOS Cordova 3.7.0 and Windows 8 Cordova 3.7.1.

This means that the Cordova framework version you are using "on device" with a built app will not equal the version number that is in the CLI field that you specified in the Build Settings section of the Projects tab when you built your app. Technically, the target-specific Cordova frameworks can be updated [independently] within a given version of CLI tools, but our build system always uses the Cordova framework versions that were "pinned" to the CLI when it was released (that is, the Cordova framework versions specified in the platformsConfig file).

The reason you may see Cordova framework version differences between the Emulate tab, App Preview and your built app is:

  • The Emulate tab has one specific Cordova framework version it is built against. We try to make that version of the Cordova framework match as closely the default Intel XDK version of Cordova CLI.
  • App Preview is released independently of the Intel XDK and, therefore, may support a different version than what you will see reported by the Emulate tab and your built app. Again, we try to release App Preview so it matches the version of the Cordova framework that is the default version of the Intel XDK at the time App Preview is released; but since the various tools are not released in perfect sync, that is not always possible.
  • Your app always uses the Cordova framework version that is determined by the Cordova CLI version you specified in the Projects tab's Build Settings section, when you built your app.
  • BTW: the version of the Cordova framework that is built into Crosswalk is determined by the Crosswalk project, not by the Intel XDK build system. There is some customization the Crosswalk project team must do to the Cordova framework to include Cordova as part of the Crosswalk runtime engine. The Crosswalk project team generally releases each Crosswalk version with the then current version of the Android Cordova framework. Thus, the version of the Android Cordova framework that is included in your Crosswalk build is determined by the version of Crosswalk you choose to build against.

Do these Cordova framework version numbers matter? Not that much. There are some issues that come up that are related to the Cordova framework version, but they tend to be few and far between. The majority of the bugs and compatibility issues you will experience in your app have more to do with the versions and mix of Cordova plugins you choose and the specific webview present on your test devices. See this blog for more details about what a webview is and why the webview matters to your app: When is an HTML5 Web App a WebView App?.

p.s. The "default version" of the CLI that the Intel XDK uses is rarely the most recent version of the Cordova CLI tools distributed by the Cordova project. There is always a lag between Cordova project releases and our ability to incorporate those releases into our build system and the various Intel XDK components. Also, we are unable to implement every release that is made by the Cordova project; thus the reason why we do not support every Cordova release that is available to Cordova CLI users.

Q26: How do I add a third party plugin?
Please follow the instructions on this doc page to add a third-party plugin: Adding Plugins to Your Intel® XDK Cordova* App -- this plugin is not being included as part of your app. You will see it in the build log if it was successfully added to your build.
Q27: How do I make an AJAX call that works in my browser work in my app?
Please follow the instructions in this article: Cordova CLI 4.1.2 Domain Whitelisting with Intel XDK for AJAX and Launching External Apps.
Q28: I get an "intel is not defined" error, but my app works in Test tab, App Preview and Debug tab. What's wrong?

When your app runs in the Test tab, App Preview or the Debug tab the intel.xdk and core Cordova functions are automatically included for easy debug. That is, the plugins required to implement those APIs on a real device are already included in the corresponding debug modules.

When you build your app you must include the plugins that correspond to the APIs you are using in your build settings. This means you must enable the Cordova and/or XDK plugins that correspond to the APIs you are using. Go to the Projects tab and insure that the plugins you need are selected in your project's plugin settings. See Adding Plugins to Your Intel® XDK Cordova* App for additional details.

Q29: How do I target my app for use only on an iPad or only on an iPhone?

There is an undocumented feature in Cordova that should help you (the Cordova project provided this feature but failed to document it for the rest of the world). If you use the appropriate preference in the intelxdk.config.additions.xml file you should get what you need:

<preference name="target-device" value="tablet" />     <!-- Installs on iPad, not on iPhone --><preference name="target-device" value="handset" />    <!-- Installs on iPhone, iPad installs in a zoomed view and doesn’t fill the entire screen --><preference name="target-device" value="universal" />  <!-- Installs on iPhone and iPad correctly -->

If you need info regarding the additions.xml file, see the blank template or this doc file: Adding Intel® XDK Cordova Build Options Using the Additions File.

Q30: Why does my build fail when I try to use the Cordova* Capture Plugin?

The Cordova* Capture plugin has a dependency on the File Plugin. Please make sure you both plugins selected on the projects tab.

Q31: How can I pinch and zoom in my Cordova* app?

For now, using the viewport meta tag is the only option to enable pinch and zoom. However, its behavior is unpredictable in different webviews. Testing a few samples apps has led us to believe that this feature is better on Crosswalk for Android. You can test this by building the Hello Cordova sample app for Android and Crosswalk for Android. Pinch and zoom will work on the latter only though they both have:

.

Please visit the following pages to get a better understanding of when to build with Crosswalk for Android:

http://blogs.intel.com/evangelists/2014/09/02/html5-web-app-webview-app/

https://software.intel.com/en-us/xdk/docs/why-use-crosswalk-for-android-builds

Another device oriented approach is to enable it by turning on Android accessibility gestures.

Q32: How to make Android application fullscreen so that status and navigation bar disappears?

The Cordova* fullscreen plugin can be used to do this. In init-app.js which is present under www folder include this function AndroidFullScreen.immersiveMode(null, null); inside app.initEvents = function(). You can get the plugin from here https://github.com/mesmotronic/cordova-fullscreen-plugin

Back to FAQs Main 

Intel® XDK FAQs - Debug & Test

$
0
0
Q1: What are the requirements for Testing on Wi-Fi?
  1. 1) Both Intel XDK and App Preview mobile app must be logged in with the same user credentials.
  2. 2) Both devices must be on the same subnet.

Note: Your computer's Security Settings may be preventing Intel XDK from connecting with devices on your network. Double check your settings for allowing programs through your firewall. At this time, testing on Wi-Fi does not work within virtual machines.

Q2: How do I configure app preview to work over Wi-Fi?

1) Ensure that both Intel XDK and App Preview mobile app are logged in with the same user credentials and are on the same subnet

2) Launch App Preview on the device 

3) Log into your Intel XDK account 

4) Select "Local Apps" to see a list of all the projects in Intel XDK Projects tab 

5) Select desired app from the list to run over Wi-Fi  

Note: Ensure the app source files are referenced from the right source directory. If it isn't, on the Projects Tab, change the 'source' directory so it is the same as the 'project' directory and move everything in the source directory to the project directory. Remove the source directory and try to debug over local Wi-Fi.

Q3: How do I clear app preview cache and memory?

[Android*] Simply kill the app running on your device as an Active App on Android* by swiping it away after clicking the "Recent" button in the navigation bar. Alternatively, you can clear data and cache for the app from under Settings App > Apps > ALL > App Preview. 

[iOS*] By double tapping the Home button then swiping the app away. 

[Windows*] You can use the Windows* Cache Cleaner app to do so.

Q4: What are the Android* devices supported by App Preview?

We officially only support and test Android* 4.x and higher, although you can use Cordova for Android* to build for Android* 2.3 and above. For older Android* devices, you can use the build system to build apps and then install and run them on the device to test. To help in your testing, you can include the weinre script tag from the Test tab in your app before you build your app. After your app starts up, you should see the Test tab console light up when it sees the weinre script tag contact the device (push the "begin debugging on device" button to see the console). Remember to remove the weinre script tag before you build for the store. 

Q5: What do I do if Intel XDK stops detecting my Android* device?

When Intel XDK is not running, kill all adb processes that are running on your workstation and then restart Intel XDK as conflicts between different versions of adb frequently causes such issues. Ensure that applications such as Eclipse that run copies of adb are not running. You may scan your disk for copies of adb: 

[Linux*/OS X*]:

$ sudo find / -name adb -type f 

[Windows*]:

> cd \> dir /s adb.exe

For more information on Android* USB debug, visit the Intel XDK documentation on debugging and testing.

Q6: My third party plugins do not show up on the debug tab. How do I debug an app that contains third party plugins?

If you are using the Debug, Emulate or Test tabs you will not see any third-party plugins. At the moment, the only way to debug an app that contains a third-party plugin is to build it and debug the built app installed on your device. We are working on a solution to work with third-party plugins, but it is still in development. 

[Android*]

1) For Crosswalk* or Cordova for Android* build, create an intelxdk.config.additions.xml file that contains the following lines: 

<!-- Change the debuggable preference to true to build a remote CDT debuggable app for --><!-- Crosswalk* apps on Android* 4.0+ devices and Cordova apps on Android* 4.4+ devices. --><preference name="debuggable" value="true" /><!-- Change the debuggable preference to false before you build for the store. --> 

and place it in the root directory of your project (in the same location as your other intelxdk.config.*.xml files). Note that this will only work with Crosswalk* on Android* 4.0 or newer devices or, if you use the standard Cordova for Android* build, on Android* 4.4 or greater devices.

2) Build the Android* app

3) Connect your device to your development system via USB and start app

4) Start Chrome on your development system and type "chrome://inspect" in the Chrome URL bar. You should see your app in the list of apps and tabs presented by Chrome, you can then push the "inspect" link to get a full remote CDT session to your built app. Be sure to close Intel XDK before you do this, sometimes there is interference between the version of adb used by Chrome and that used by Intel XDK, which can cause a crash. You might have to kill the adb process before you start Chrome (after you exit the Intel XDK). 

[iOS*]

Refer to the instructions on the updated Debug tab docs to get on-device debugging. We do not have the ability to build a development version of your iOS* app yet, so you cannot use this technique to build iOS* apps. However, you can use the weinre script from the Test tab into your iOS* app when you build it and use the Test tab to remotely access your built iOS* app. This works best if you include a lot of console.log messages.

[Windows* 8]

You can use the test tab which would give you a weinre script. You can include it in the app that you build, run it and connect to the weinre server to work with the console.  

Alternatively, you can use App Center to setup and access the weinre console (go here and use the "bug" icon).  

Another approach is to write console.log messages to a <textarea> screen on your app. See either of these apps for an example of how to do that:  

Q7:  Why does my device show as offline on Intel XDK Debug?
“Media” mode is the default USB connection mode, but due to some unidentified reason, it frequently fails to work over USB on Windows* machines. Configure the USB connection mode on your device for "Camera" instead of "Media" mode.
Q8: What do I do if my remote debugger does not launch?

You can try the following to have your app run on the device via debug tab:  

  • Place the intelxdk.js library before the </body> tag
  • Place your app specific JavaScript files after it
  • Place the call to initialize your app in the device ready event function
Q9: Why do I get an "error installing App Preview Crosswalk" message when trying to debug on device?

You may be running into a RAM or storage problem on your Android device; as in, not enough RAM available to load and install the special App Preview Crosswalk app (APX) that must be installed on your device. See this site (http://www.devicespecifications.com) for information regarding your device. If your device has only 512 MB of RAM, which is a marginal amount for use with the Intel XDK Debug tab, you may have difficulties getting APX to install.

You may have to do one or all of the following:

  • remove as many apps from RAM as possible before installing APX (reboot the device is the simplest approach)
  • make sure there is sufficient storage space in your device (uninstall any unneeded apps on the device)
  • install APX by hand

The last step is the hardest, but only if you are uncomfortable with the command-line:

  1. while attempting to install APX (above) the XDK downloaded a copy of the APK that must be installed on your Android device
  2. find that APK that contains APX
  3. install that APK manually onto your Android device using adb

To find the APK, on a Mac:

$ cd ~/Library/Application\ Support/XDK
$ find . -name *apk

To find the APK, on a Windows machine:

> cd %LocalAppData%\XDK> dir /s *.apk

For each version of Crosswalk that you have attempted to use (via the Debug tab), you will find a copy of the APK file (but only if you have attempted to use the Debug tab and the XDK has successfully downloaded the corresponding version of APX). You should find something similar to:

./apx_download/12.0/AppAnalyzer.apk

following the searches, above. Notice the directory that specifies the Crosswalk version (12.0 in this example). The file named AppAnalyzer.apk is APX and is what you need to install onto your Android device.

Before you install onto your Android device, you can double-check to see if APX is already installed:

  • find "Apps" or "Applications" in your Android device's "settings" section
  • find "App Preview Crosswalk" in the list of apps on your device (there can be more than one)

If you found one or more App Preview Crosswalk apps on your device, you can see which versions they are by using adb at the command-line (this assumes, of course, that your device is connected via USB and you can communicate with it using adb):

  1. type adb devices at the command-line to confirm you can see your device
  2. type adb shell 'pm list packages -f' at the command-line
  3. search the output for the word app_analyzer

The specific version(s) of APX installed on your device end with a version ID. For example: com.intel.app_analyzer.v12 means you have APX for Crosswalk 12 installed on your device.

To install a copy of APX manually, cd to the directory containing the version of APX you want to install and then use the following adb command:

$ adb install AppAnalyzer.apk

If you need to remove the v12 copy of APX, due to crowding of available storage space, you can remove it using the following adb command:

$ adb uninstall com.intel.app_analyzer.v12

or

$ adb shell am start -a android.intent.action.DELETE -d package:com.intel.app_analyzer.v12

The second one uses the Android undelete tool to remove the app. You'll have to respond to a request to undelete on the Android device's screen. See this SO issue for details. Obviously, if you want to uninstall a different version of APX, specify the package ID corresponding to that version of APX.

Q10: Why is Chrome remote debug not working with my Android or Crosswalk app?

For a detailed discussion regarding how to use Chrome on your desktop to debug an app running on a USB-connected device, please read this doc page Remote Chrome* DevTools* (CDT).

Check to be sure the following conditions have been met:

  • The version of Chrome on your desktop is greater than or equal to the version of the Chrome webview in which you are debugging your app.

    For example, Crosswalk 12 uses the Chrome 41 webview, so you must be running Chrome 41 or greater on your desktop to successfully attach a remote Chrome debug session to an app built with Crosswalk 12. The native Chrome webview in an Android 4.4.2 device is Chrome 30, so your desktop Chrome must be greater than or equal to Chrome version 30 to debug an app that is running on that native webview.
  • Your Android device is running Android 4.4 or higher, if you are trying to remote debug an app running in the device's native webview, and it is running Android 4.0 or higher if you are trying to remote debug an app running Crosswalk.

    When debugging against the native webview, remote debug with Chrome requires that the remote webview is also Chrome; this is not guaranteed to be the case if your Android device does not include a license for Google services. Some manufacturers do not have a license agreement with Google for distribution of the Google services on their devices and, therefore, may not include Chrome as their native webview, even if they are an Android 4.4 or greater device.
  • Your app has been built to allow for remote debug.

    Within the intelxdk.config.additions.xml file you must include this line: <preference name="debuggable" value="true" /> to build your app for remote debug. Without this option your app cannot be attached to for remote debug by Chrome on your desktop.
Q11: How do I detect if my code is running in the Emulate tab?

In the obsolete intel.xdk apis there is a property you can test to detect if your app is running within the Emulate tab or on a device. That property is intel.xdk.isxdk. A simple alternative is to perform the following test:

if( window.tinyHippos )

If the test passes (the result is true) you are executing in the Emulate tab.

Q12: Never ending "Transferring your project files to the Testing Device" message from Debug tab; results in no Chrome DevTools debug console.

This is a known issue but a resolution for the problem has not yet been determined. If you find yourself facing this issue you can do the following to help resolve it.

On a Windows machine, exit the Intel XDK and open a "command prompt" window:

> cd %LocalAppData%\XDK\> rmdir cdt_depot /s/q

On a Mac or Linux machine, exit the Intel XDK and open a "terminal" window:

$ find ~ -name global-settings.xdk
$ cd <location-found-above>
$ rm -Rf cdt_depot

Restart the Intel XDK and try the Debug tab again. This procedure is deleting the cached copies of the Chrome DevTools that were retrieved from the corresponding App Preview debug module that was installed on your test device.

Back to FAQs Main

Debug SPI BIOS after Power Up Sequence

$
0
0

After PCB assembly and the board power up, the next phase will be SPI BIOS debugging. A lot of system engineers and firmware engineers who had been interested in Intel System Studio (ISS), questioned whether available to use ISS to do SPI BIOS debugging once after CPU reset de-assertion. Answer is YES, and explain below how to make it happen with Intel System Debugger of ISS.

To debug SPI BIOS once after CPU reset de-assertion, is kind of difficult task. Because the connection time from host to target is much longer compared with platform power up sequence, and even including BIOS module boot time. In order to accommodate end users’ demands, Intel System Debugger provides a feature set to halt target once after CPU reset de-assertion. Some steps described below are required for this usage case.

 

1st need to do, is to launch Intel System Debugger of ISS2015 (former name was Intel JTAG Debugger of ISS2014).

2nd connect to target platform

3rd reset the target through using the “restart” console command, or by clicking the restart button as below.

After the target reset, then can debug SPI BIOS.

 

Intel® INDE 2015 Release Notes and Installation Guide

$
0
0

This page provides the Release Notes for Intel® INDE 2015 with the most recent being listed at the top of the page. For more details, please take a look at the documents on the table below.

Intended Audience

Software developers interested in a cross-platform productivity suite that enables them to quickly and easily create native apps from OS X* host for Android* or OS X* targets (or) Windows* host for Android* or Windows* targets

Customer Support

For technical support of Intel® Integrated Native Developer Experience 2015, including answers to questions not addressed in this product, latest online getting started help, visit the technical support forum, FAQs, and other support information at: https://software.intel.com/en-us/intel-inde-support

To seek help with an issue in Intel® INDE (any edition), go to the user forum (https://software.intel.com/en-us/forums/intel-integrated-native-developer-experience-intel-inde)

To submit an issue for Ultimate of Intel® INDE, go to Intel® Premier Support: (https://premier.intel.com/)

Intel® Premier Support is not available for Starter Edition of the product. New Professional Edition users will not have Intel® Premier Support either as it is made free but the users who have had prior access to this support will continue to have the privilege.

For more information on registering to Intel Premier Support, go to: http://software.intel.com/en-us/articles/performance-tools-for-software-developers-intel-premier-support

What is new in Update 2?

Windows* Host:

  • Support for 14nm SoC code named  Cherry Trail
  • Support for Windows* 10 Desktop (Preview) Host and Target
  • Limited Support for Windows* 10 Mobile Target
  • Limited Support for Visual Studio* 2015 (all editions)
  • Graphics Frame Analyzer for OpenGL*
  • New beta or preview features
    • Tamper Protection [Beta]
    • OpenCV Library [Beta]
    • OpenCL™ Code Analyzer Tool for Microsoft* Visual Studio* [Preview]

OS X* Host:

  • Support for 14nm SoC code named Cherry Trail on Android* targets
  • Support for OS X* targets on Intel® C++ Compiler, Intel® IPP and Intel® TBB
  • Graphics Frame Analyzer for OpenGL*
Release Notes for Windows* HostRelease Notes for OS X* HostEnd User License Agreements
Update 2Update 2

EULA for Intel® INDE on Windows* Host

EULA for Intel® INDE on OS X* Host

Update 1Update 1Embedded in Release Notes

Older Updates:

Update 1.1 is available now!

INDE 2015 Update 1.1 is a label change in License only on top of Update 1.  If you already installed Intel INDE 2015 Update 1, then this installation is optional.

If you are an existing user of INDE 2015 Update 1, you will receive a notification in your Intel® Software Manager tool on how to update your installation. If you are a new user, please visit  https://software.intel.com/en-us/intel-inde to see various packages available and download INDE.

What is new in Update 1?

  • Support for Android* Lollipop 32 bit/64 bit apps
  • Support for Nexus Player
  • Visual Studio 2013 Community Edition is supported

 


How to Set Up FMOD*, Cocos2D-x*, and OpenAL* Libraries for Android* on Intel® Architecture

$
0
0

Download Document

Previously, we’ve gone through instructions on how to compile a FFmpeg library on x86 architecture. This step-by-step guide walks you through the process of setting up and compiling different libraries that are used in gaming and multimedia specifically for x86 target platforms. We will go through the setup of FMOD*, Cocos2D-x*, and OpenAL*.

Setup and Prerequisites:

Before starting, we need to fulfill certain download prerequisites.

  1. Download Android ADT Bundle
  2. Download NDK
  3. Download and install Cygwin*: When asked to select packages, search for the following packages and install them:

    Autoconf, Automake, binutils, gcc-core, gcc-g++, gcc4-core, gcc4-g++, gdb, pcre, pcre-devel,
    gawk, make, python

    NOTE: Select the GUI version of make as well; otherwise, you will not be able to build your project using NDK.

  4. Download JDK
  5. Download Apache Ant

Now you need to edit some environmental variables.

  1. Set JAVA_HOME = the path in which you have installed the Java* JDK, for me it is: C:\Program Files\Java\jdk1.7.0_45
  2. Set ANDROID_SDK_ROOT = the complete path to the SDK folder. For example: in my case, I have downloaded and extracted the ADT bundle in D:\android\, so my path is: D:\android\adt-bundle-windows-x86-20131030\sdk
  3. Set NDK_ROOT = the complete path to the NDK folder, my path is: D:\android\android-ndk-r9b
  4. Set NDK_ROOT = the complete path to the NDK folder, my path is: D:\android\android-ndk-r9b
  5. Update the Path variable to contain the following = path to the JDK folder, JDK bin folder, NDK, Cygwin bin folder, ANT bin folder, SDK tools folder and SDK platform-tools folder, each separated by a semi-colon (;). For example, in my case, I will add the following:

    D:\cygwin64\bin;C:\Program Files\Java\jdk1.7.0_40\bin;D:\android\adt-bundle-windows-x86_64-20131030\sdk\tools;D:\android\adt-bundle-windows-x86_64-20131030\sdk\platform-tools;%JAVA_HOME%\bin;%ANT_HOME%\bin

NOTE: Do not end any variable with \ or ` or any such special character.

FMOD

FMOD is a commercial library to manage audio. FMOD is a set of audio content creation tools that plays music files of diverse formats on many different operating system platforms used in games and software applications to provide audio functionality. Below is a step-by-step guide for integrating the FMOD library into an Android application with the help of the Eclipse* IDE specifically for an x86 target platform.

Download FMOD. Download the Android version of FMOD Ex Programmer’s API, as shown below:

To install FMOD, extract “fmodapi44429android.tar.gz” using some tool like 7-zip to any folder of your choice.

Building using Android NDK:

To implement sounds through FMOD Ex API, you must include it as C/C++ programs in your code and reference it through jni in your Android application.

FMOD comes with C/C++ libraries that can be called via JNI, or linked to the C/C++ component of your application:

  • libfmodex.so for general development.
  • libfmodexL.so for the same library, but with debug logging which can help to determine any problems if they exist.

FMOD libraries are currently provided for the armeabi and armeabi-v7a ABIs built against android-3, and the x86 ABI built against android-9.

  • {$FMOD INSTALLED PATH}\api\lib\$(ABI)

The all native audio interface OpenSL is the default playback method for devices that support it (android-9) and requires no additional files. For devices without OpenSL support you will need to use the Audio Track output mode, which requires an FMOD jar file. This jar file must be added to your Java application to initialize and drive the FMOD audio output:

  • fmodex.jar

This is discussed in the next topic.

NOTE: Since the sample application used here is part of the library, we have not included the code for the example; and instead just the modifications necessary are stated in this document.

Java Initialization

To enable audio output through the Audio Track output mode you must include and initialize the FMOD Java audio driver in your application (not required if you use the OpenSL output mode). To do this you will need to ensure fmodex.jar is referenced in your Java project, and you have imported the org.fmod.FMODAudioDevice package. The FMOD Java audio driver also requires that your application loads the fmodex library.

The FMODAudioDevice class has two functions you must call for audio to play. They can be called at any time, but we recommend you put the start() and stop() function calls in the onStart() and onStop() overrides of your Activity.

Building a sample program for Android on the x86 platform

The process for building a program is the same as building one through NDK. Let’s look at an example to demonstrate. For this example, we will be using the sample program located in the folder:

  • {$FMOD INSTALLED PATH}\examples\playsound

We will call this {$PROJECT DIRECTORY}. But before we build it using NDK, we need to make certain changes:

  1. Go to the directory {$PROJECT DIRECTORY}\jni and open the Application.mk file.
  2. Change the following code:

    APP_ABI := armeabi armeabi-v7a
    to
    APP_ABI := x86

Now open Cygwin and perform the following tasks to build the application:

ndk-build

  1. Update the PATH variable in Cygwin as follows:

    export PATH=.:/cygdrive/{$PATH TO NDK}:$PATH

  2. cd to the path of the project:

    cd /cygdrive/{$PROJECT DIRECTORY}

  3. Run the command:
  4. This will build the project and make it ready for deployment.

NOTE: In this case replace all the ‘\’ characters from the Windows* path format to ‘/’ character for GNU based path format.

At the end of a successful build, you will see the following message in Cygwin:

[x86] Prebuilt: libfmodex.so <= jni/../../../api/lib/x86/
[x86] Install: libfmodex.so => libs/x86/libfmodex.so
[x86] Cygwin: Generating dependency file converter script
[x86] Compile: main <= main.c
[x86] SharedLibrary: libmain.so
[x86] Install: libmain.so => libs/x86/libmain.so

Now that your project is built it can be run through the Eclipse IDE.

Running the application through Eclipse IDE

To launch the application from Eclipse IDE, follow these steps:

  1. Start Eclipse and click File > Import:

  2. Choose the Existing Android… option and click Next:

  3. Browse to the root directory of the project, i.e., {$PROJECT DIRECTORY}, then make sure that the Copy projects... option is unchecked and click Finish:

  4. You will notice a red exclamation sign on the imported project in the package explorer tab as shown below:

  5. To resolve that, click Window > Preferences as shown in the previous page, and the following window appears:

  6. Click the New… option and you will see the following:

  7. In place of the “Name” field, type:

    FMOD_LIB

  8. Then click File and browse to locate the following file:

    {$FMOD INSTALLED PATH}/api/lib/fmodex.jar

  9. Click OK.
  10. Then click OK again and the following window will appear; click Yes:

  11. The red exclamation error will be resolved.
  12. Then click Project > Properties.

  13. Then select C/C++ Build > Environment > Add:

  14. Type ANDROID_NDK_ROOT in the Name field and the complete path to the installed folder in the Value field. Then click OK:

  15. Then click Apply and then OK:

Now you may launch the application but only after you copy all the files from the two sets of example media:

{$FMOD INSTALLED PATH}\examples\media\* and
{$FMOD INSTALLED PATH}\fmoddesignerapi\examples\media\*

To a folder called fmod in the root of the SD card.

NOTE: The application may fail to launch in the simulator.

x86 platform specific settings

It is essential when building an application specifically for the x86 platform that you make the following changes: (Please note that these changes were incorporated as a part of the procedure in building the project.)

  1. Go to the directory {$PROJECT DIRECTORY}\jni and open the Application.mk file (create one if not present).
  2. Change the following code:

    APP_ABI := armeabi armeabi-v7a
    to
    APP_ABI := x86

Build Output

The output of the build will be located in the {$PROJECT DIRECTORY} in the following manner:

The generated libraries, libmain.so and libfmodex.so, will be present in the {$PROJECT DIRECTORY}\libs\x86 folder.

The generated objects will be in {$PROJECT DIRECTORY}\obj folder.

Known errors and issues

If there are errors during building through NDK, please set the access permissions to “Full Control” for “Everyone”.

Also please note that the application may fail to launch in the emulator and that you will be able to launch it in your device only after copying all the files from the two sets of example media:

{$FMOD INSTALLED PATH}\examples\media\* and
{$FMOD INSTALLED PATH}\fmoddesignerapi\examples\media\*

To a folder called fmod in the root of the SD card.

Cocos2D-x:

So now, let’s go through the process of building a cross-platform Android application with the help of the Cocos2d-x game engine specifically for x86 target platform.

The sample program used in this document to explain the process is part of the Cocos2d-x Game Engine and can be found in the \samples\Cpp\ folder within the cocos2d-x-2.1.1 folder.

Cocos2d-X is a multi-platform port written in C++ that can be used with iOS*, Android, Windows, Marmalade, Linux*, Bada, and BlackBerry* 10. This port has Lua* and JavaScript* as the script binding. You can read Cocos2d-X support documentation on their site.

Before using Cocos2d-x, be sure you have fulfilled the prerequisites as detailed above in the Prerequisites section.

Download Cocos2d-x:

Download Cocos2d-x and choose the latest version. Also remember to choose the simple Cocos2d-x option not the –html5 option.

Steps to Install and set up Cocos2d-X:

  1. Extract the zip file downloaded in the previous step to your C:\ Drive. I extracted mine to D:\Cocos2d-x.
  2. There should be two folders in the Cocos2d-x folder. For me they are: D:\Cocos2d-x\__MACOSX and D:\Cocos2d-x\cocos2d-x-2.2.1.
  3. Set up the environment variables for Cocos2d-x as shown below:

    COCOS2DX_ROOT = the complete path to the cocos2d-x-2.2.1 folder, in my case it is: D:\Cocos2d-x\cocos2d-x-2.2.1

Before we begin, make note of a few variables as they will be extensively used throughout:

  • {$ADT PATH} = the complete path to the android ADT bundle, in my case, it is: D:\android\adt-bundle-windows-x86_64-20131030
  • {$ECLIPSE PATH} = the complete path to the eclipse supplied along with the ADT bundle, for me, it is: {$ADT PATH}\eclipse
  • {$COCOS2D-X PATH} = the complete path to the cocos2d-x-2.2.1 folder, in my case, it is: D:\Cocos2d-x\cocos2d-x-2.2.1
  • {$WORKSPACE PATH} = the complete path to the Eclipse Android workspace, for me it is: D:\and_proj_coco

Configuring a Cocos2d-x project in Eclipse IDE:

  1. Run Eclipse from the following path: {$ECLIPSE PATH}\eclipse.exe
  2. Create your workspace when prompted. I made mine in {$WORKSPACE PATH}, as shown below:

  3. Click File > Import as shown below:

  4. A window like the one shown below will appear:

  5. Expand the Android section. Then click the Existing Android Code Into Workspace option and click Next, as shown above.
  6. Click Browse… as shown below:

  7. Browse to {$COCOS2D-X PATH}\samples\Cpp\HelloCpp\proj.android as shown below and click OK:

  8. For this sample project, before clicking Finish, make sure you DO NOT CHECK the Copy projects into workspace option:

  9. After import, Eclipse may display a few errors. For the time being ignore them and proceed to the next steps.

    NOTE: In the future, if you do not want to disturb the original project code and are confident that importing the project code into your workspace will not affect code execution, then you may check the above circled option.

  10. Now repeat Steps c – h with the difference that instead of importing {$COCOS2D-X PATH}\samples\Cpp\HelloCpp\proj.android, you will import: {$COCOS2D-X PATH}\cocos2dx\platform\android as shown below, you may check the Copy project into workspace option if you want:

  11. If the errors encountered in Step h are not solved at this point, proceed to the next steps as below.
  12. Now, in the Package Explorer tab in the left, right click libcocos2dx and click Properties, as shown below:

  13. In the window that appears, click the Android option in the left tab and make sure that the Is Library option is checked, as shown below, then click Apply and finally OK.

  14. Similarly, open the Properties window for the HelloCpp project by following Steps j – k for the project HelloCpp. You will then see a window as shown below:

  15. Remove anything in the Library section marked with a red cross and click Add.
  16. Choose libcocos2dx and click OK as shown below:

  17. Now you will see that the Library section is populated with a green check mark as shown below, then click Apply and OK:

  18. At this point, Eclipse will rebuild the project. If all the errors are resolved then ignore this step. If not, then delete the existing HelloCpp project from the Package Explorer tab and make sure that while deleting you DO NOT choose to remove from disk, as it CANNOT BE UNDONE, and redo Steps c – h and Steps m – p:

  19. Now, your project should look like this:

Congratulations! You have successfully opened your project in Eclipse IDE. Now let’s move on to building your project.

Building a Cocos2d-x project in Eclipse IDE:

  1. From the Package Explorer tab, navigate to HelloCpp > jni > Application.mk as shown below:

  2. Add the following line to build for the x86 platform:

    APP_ABI := x86

  3. Now, from the Project tab in the top menu bar, first click Clean, then Build Project, as shown below:

Opening and building a Cocos2d-x project through Cygwin:

  1. Run Cygwin and navigate to the sample HelloCpp project folder using the following command:

    cd /cygdrive/d/Cocos2d-x/cocos2d-x-2.2.1/samples/Cpp/HelloCpp/proj.android

    Note that the path is dependent on {$COCOS2D-X PATH}.

  2. Make sure that the following line is added to the Application.mk file present in the /jni folder:

    APP_ABI := x86

  3. To build the project, while staying in the /proj.android folder, enter the command:

    ./build_native.sh

NOTE: If any errors occur, make sure that:

  • The required packages for Cygwin are downloaded properly.
  • The PATH variable of Cygwin contains the paths to the Android NDK, SDK, JDK, and COCOS2D-X folders as mentioned in the Prerequisite section.

Once the build procedure is followed and completed, the binaries get generated to the following folder:

proj.android\obj\local\x86

For example:

proj.android\obj\local\x86\libhellocpp.so
proj.android\obj\local\x86\libcocos2d.a

OpenAL (Open Audio Library)

OpenAL (Open Audio Library) is a cross-platform audio application programming interface (API). It is designed for efficient rendering of multichannel, three dimensional positional audio. Its API style and conventions deliberately resemble those of OpenGL. Since 1.1, Creative has made its implementation proprietary. However, OpenAL-Soft is a widely used open source alternative. We will use a version of OpenAL-Soft that is specially adapted for Android.

Before we start to work on OpenAL, please download as per the above Prerequisites section.

Download a patched source of OpenAL:

To work with OpenAL, you need a patched source that is specially adapted for Android.

Thanks to Martins Mozeiko and Chris Robinson a version of OpenAL exists that has been adapted to the Android platform. Download the latest version of the patched OpenAL source code.

Alternatively, you can also download this source through your Cygwin terminal:

  1. Run Cygwin and enter the following command:

    git clone http://repo.or.cz/r/openal-soft/android.git OpenAL

  2. Now the repository will get cloned in a folder called OpenAL in your pwd, for me it is: /home/user001 or ~.

NOTE: In the case of the Windows version of Cygwin, the /home folder can be found in the directory in which Cygwin is installed. In my case, it is: D:\cygwin64

How to configure for x86 platform:

Before we start to build, create a normal Hello OpenAL Android project. Let the path for this project folder be {$PROJECT_DIR}, like: D:\openal_proj\HelloOpenAL.

To compile using OpenAL for Android, follow these steps:

  1. To compile OpenAL a file called config.h is needed. Copy it from

    {$OPENAL_DIR}/android/jni
    To
    {$OPENAL_DIR}/include

    NOTE: Here, {$OPENAL_DIR} is the complete path to the downloaded OpenAL directory from the previous step. For me, it is: ~/openal

  2. After making the above change, copy this OpenAL folder to your project folder {$PROJECT_DIR}.
  3. Now add the native interface to the project in the subsequent steps.
  4. I have used the org_pielot_helloopenal_HelloOpenAL.c file to implement the audio playback methods from the native interface.
  5. Then we need to create two make files, Android.mk and Application.mk and put them in the jni folder along with the .c folder and its custom .h header file.

    NOTE: The detail of these files and their arrangement is given at the end of the document.

To configure the project specifically for x86, make sure that the following files are edited to contain the given respective values:

Application.mk

APP_OPTIM := release
APP_ABI := x86

How to build the project:

  1. Open Cygwin and navigate to {$PROJECT_DIR}:

    cd /cygdrive/{$PROJECT_DIR}

    where {$PROJECT_DIR} is the complete path to the project directory. In my case, it is:

    cd /cygdrive/d/openal_proj

  2. Now run the following command to include the path to the NDK folder in your Cygwin PATH environment variable:

    export PATH=.:/cygdrive/{$PATH TO NDK}:$PATH

    For example, in my case:

    export PATH=.:/cygdrive/d/android/android-ndk-r9b:$PATH

  3. Run the command:

    ndk-build

    This will build your OpenAL project for x86 target architecture.

Build output:

The output of the build will be located in the {$PROJECT_DIR}:

The generated libraries, libopenal.so and libopenaltest.so, will be in the {$PROJECT_DIR}\libs\x86 folder.

The generated objects will be in {$PROJECT_DIR}\obj folder.

OpenSSL* libraries:

The following process describes how to build the OpenSSL libraries for Android on x86.

Prerequisites

  1. A host PC running Windows 7 or later.
  2. Since the OpenSSL libraries were developed in native C language, the primary prerequisite for compilation is the Android NDK, which has the built-in support for cross-compiling the libraries for specific architectures (ARM, x86, etc.).

Android OpenSSL source can be downloaded from either the eighthave project or the guardian project on github.

Building for x86:

Cross-platform settings can be made as you would any other Android application using the Application Binary Interface settings.

The following line should be added to the jni/Application.mk file to build the libraries for x86 architecture.

APP_ABI := x86

Once you have the NDK installed and the Android OpenSSL downloaded and unzipped in to a local disk drive (for example, C:\openssl-android-master), follow the instructions below to build the libraries for x86:

  1. Open the command prompt (Start->All Programs->Accessories->Command Prompt).
  2. Move to the OpenSSL Android folder that you downloaded and unzipped, for example,
    >cd C:\openssl-android-master.
  3. Be sure to set the required configuration settings for x86, for example, APP_ABI := x86.
  4. Issue the NDK build command, for example, C:\openssl-android-master > ndk-build.

    This will build the libssl, libcrypto, openssl libraries.

    The libraries generated can be found at the following location:

    C:\openssl-android-master\libs\x86\libcrypto.so
    C:\openssl-android-master\libs\x86\libssl.so

About the Author

Praveen Kundurthy works in the Intel® Software and Services Group. He has a Master’s degree in Computer Engineering. His main interests are mobile technologies, Windows, and game development.

Related Articles and Resources

How to develop a cross platform native application with Intel® INDE for Windows* and Android*?

$
0
0

Hello, I am going to show you how you can develop a native app for Windows* and Android* that can reuse the shared app logic in C++. This is going to be a simple hello world app for you to understand the process. I am using Android Studio installed by Intel® INDE 2015 Update 2 for building the Android UI. (You can update it to 1.2.2 without losing Intel INDE plugins) And Visual Studio 2013 for building the Windows UI and both are going to call the native C++ API that is shared between these two apps. This article assumes that you are aware of the basic process of building and emulating apps on Android Studio and Visual Studio.

Step 1:

The structure of your workspace directory should look like this.

Workspace/CoreCommon (Shared C/C++ files)

  • Hello.c (has print_hello() that is called by both the apps)
  • Hello.h

Workspace/CrossPlatformAndroid

Workspace/CrossPlatformWindows

Step 2:

Letz start with building the Android project in Android Studio.

New Project -> Choose the directory that you just created for Android Project

And choose Intel® INDE plugin “Blank Activity with NDK”

How does Intel® INDE help with building this app?

First of all, the process of NDK build is made very simple in Android Studio with the IDE Integration feature of Intel® INDE. The template has the boiler plate code for your simple hello-jni app that can be readily compiled. The Gradle build script that comes with the feature invokes the NDK-BUILD as part of the app compilation process and app compilation is made dependent on the success of the ndk-build. i.e, only if the C++ library is built successfully, the compilation of the rest of app is successful. You don’t have to invoke the ndk-build separately.

task ndkBuild(type: Exec) {


    if (Os.isFamily(Os.FAMILY_WINDOWS)) {
        def ndkDir = System.getenv("ANDROID_NDK_ROOT")


        commandLine 'cmd', '/C', "$ndkDir/ndk-build",'NDK_PROJECT_PATH=build','APP_BUILD_SCRIPT=src/main/jni/Android.mk','NDK_APPLICATION_MK=src/main/jni/Application.mk','NDK_APP_LIBS_OUT = src/main/jnilibs'

    } else {

        def ndkDir = System.getenv("NDKROOT")
        commandLine "$ndkDir/ndk-build",'NDK_PROJECT_PATH=build','APP_BUILD_SCRIPT=src/main/jni/Android.mk','NDK_APPLICATION_MK=src/main/jni/Application.mk','NDK_APP_LIBS_OUT = src/main/jnilibs'


    }
}
tasks.withType(JavaCompile) {
    compileTask -> compileTask.dependsOn ndkBuild
}

Step 3:

Now, change the jni/Android.mk file to include the files under CoreCommon to build the MyLib library. The above gradle script then builds the MyLib.so file which can be located at app/src/jnilibs

Step 4:

Now go to NativeCode.c file and make the highlighted modification. Basically, print_hello() function is called from the shared library.

If you look at src/main/java/MainActivity.java, the above jni function “getStringFromNative” is called which in turn calls from the shared library to print the hello string.

Step 5:

Build -> Rebuild Project and you will see in Gradle Build terminal (abbreviated):

:app:generateDebugSources

:app:ndkBuild

[x86] Compile        : MyLib <= NativeCode.c

[x86] Compile        : MyLib <= hello.c

[x86] SharedLibrary  : libMyLib.so

:app:compileDebugAndroidTestNdk UP-TO-DATE

:app:compileDebugAndroidTestSources

Information:BUILD SUCCESSFUL

Step 6: Run the app in the Android Emulator.

On similar lines, letz start the Windows* App from Visual Studio 2013.

First, build the shared C++ library.

Step 1: Create an empty C++ project

Open Solution Explorer and add NativeCode.h to the Header Files and NativeCode.cpp to SourceFiles. Contents below:

NativeCode.h:

#include <Windows.h>

#include "hello.h"

using namespace std;
#if defined(_BUILD_DLL)

#   define DLLAPI           __declspec(dllexport) //Export when building DLL

#else

#   define DLLAPI           __declspec(dllimport) //Import when using in other project

#endif

#ifdef __cplusplus

extern "C" {

#endif

DLLAPI char* DisplayHelloFromDLL();

#ifdef __cplusplus

}

#endif


NativeCode.cpp:

#include "NativeCode.h"

char* DisplayHelloFromDLL()

{

       char* str = print_hello();

       return str;

}

Step 2: Add hello.c from CoreCommon to the Source Files of this project and hello.h to Header Files of this project.

Right click Header Files -> Add -> Existing Item -> ../CoreCommon/hello.h

Right click Source Files -> Add -> Existing Item -> ../CoreCommon/hello.c

Remember, you may have to include the CoreCommon directory in your Project Properties:

Step 3: Right click project -> Build.

If your build is successful, you will see the dll under ..\Workspaces\CrossPlatformWindows\Debug

Your shared library is successfully built for your Windows app.

Step 4: Now, letz build the UI for the Windows App. It can be a simple text box to display the string from the hello.c file.

Right click Solution Explorer -> Add -> New Project -> Visual C#

Right Click the project and “Set as StartUp Project”

Step 5:

Open the main .cs file and make reference to the dll that was created in Step 3. Remember to include System.Runtime.InteropServices

Add a simple UI and an event handler that calls the shared CPP code to print the "Hello World" like below:

Step 6:

BUILD -> Rebuild Solution.

If your build is successful, you should see:

1>------ Rebuild All started: Project: NativeCPPLib, Configuration: Debug Win32 ------

2>------ Rebuild All started: Project: HelloCSharp, Configuration: Debug Any CPU ------

2>C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.CSharp.CurrentVersion.targets(448,9): warning MSB3052: The parameter to the compiler is invalid, '/define:/clr' will be ignored.

2>  HelloCSharp -> C:\INDE\Workspaces\CrossPlatformWindows\HelloCSharp\bin\Debug\HelloCSharp.exe

1>  hello.c

1>  NativeCode.cpp

1>     Creating library C:\INDE\Workspaces\CrossPlatformWindows\Debug\NativeCPPLib.lib and object C:\INDE\Workspaces\CrossPlatformWindows\Debug\NativeCPPLib.exp

1>  NativeCPP.vcxproj -> C:\INDE\Workspaces\CrossPlatformWindows\Debug\NativeCPPLib.dll

========== Rebuild All: 2 succeeded, 0 failed, 0 skipped ==========

Step 7:

Run the solution (press F5) and voila, you will see your Windows app in action!

You have successfully built your cross platform app for Windows and Android. And this is how you reuse the shared Native App Logic across different operating systems. Native App Logic is the place where many of Intel® INDE’s SDKs like Media SDK and libraries like Integrated Performance Primitives and Threading Building Blocks fit in to make your apps run in the most optimized way for the underlying architecture.

The code for this application is uploaded from the root directory level for your reference. Please post your feedback or questions below.

You Can Join Selected IDF Sessions From Wherever You Are!

$
0
0

IDF Date: Aug 18 - Aug 20, 2015

Can’t attend IDF in person this year?  We have you covered.  Selected software sessions will be webcasted which will give you the opportunity to join our experts live.  See the schedule below and register now:

 

Cross-Platform Mobile App Development With Native Performance Using Intel® Integrated Native Developer Experience

Abstract: With native look and feel, performance and portability across multiple target mobile OS and architectures, Intel® Integrated Native Developer Experience (Intel® INDE)
is a one-stop productivity suite that brings together a great arsenal of application development tools and libraries to expose advanced platform capabilities.
Come to this session to see:
• Intel INDE in action developing Android* and cross-OS apps with rich media experience
• Live demos showcasing apps built with innovative SDKs and tools included in Intel INDE
• How companies such as Open Labs*, Audible Magic* and 23Snaps* are using Intel INDE to develop native applications for multiple platforms that stand out in the marketplace

Register

 

Parallel Programming Pearls: Inspired by Intel® Xeon Phi™ Products

Abstract: This session dives into real-world parallel programming optimization examples, from around the world, through the eyes and wit of enthusiast, author, editor and evangelist James Reinders.
This session will explore:
• Concrete real world examples of how Intel® Xeon Phi™ products extend parallel programming seamlessly from a few cores to many-cores (over 60) with the same programming models
• Examples from the newly released book, “High Performance Parallelism Pearls Volume 2”, will be highlighted with source code for all examples freely available.

Register

 

Intel® XDK HTML5 Cross-Platform Development Environment - Building Cordova Apps with Crosswalk Project

Abstract: Join Paul Fischer as he discusses how the Intel® XDK HTML5 Cross-Platform Development Environment enables developers to create mobile Cordova apps for Android*, iOS* and Windows* phones and tablets. With the Intel® XDK HTML5 Cross-Platform Development Tools and Crosswalk Project runtime, high-performance apps can be easily debugged and profiled in real-time, directly on-device. By providing a complete set of tools to create, build, test and debug mobile apps, the Intel® XDK helps speed the development cycle for HTML5 apps, by enabling developers to quickly and easily create apps for multiple app stores, across diverse devices.

In this session you will hear about:
• Finding performance and memory bottlenecks in Crosswalk Project HTML5 apps
• Improving app quality with real-time on-device debug and test
• Enhancing performance, especially for games and interactive applications
• Taming the Android native Webview problem with a modern Blink Webview

Register

 

Coding for Maximum Utilization of Next Generation Intel® Processors in the IoT Era

Abstract: Join Noah Clemons as he leads a discussion with a variety of Intel® Architecture based system optimization experts from Intel together to address the following:
• System-on-chip complexity – new features on System-on-Chips (SoCs)
• Application of those features to several different IoT domains
• Fastest ways to maximize new SoC features through software
• In-depth system-wide tracing, debugging, performance and power analysis
• Tools eco-system to support the latest and next generation Intel® Architecture based SoCs

Register

Intel® Selfie App for Android* Privacy Notice

$
0
0

The providing of your email address is optional. If you choose to receive additional information from Intel your email address will be used to keep you informed on activities that pertain to the Intel® Developer Zone. Your email address may also be used to notify you in the event that you win a prize or giveaway through the use of this application.

To learn more about Intel’s privacy practices, please visit http://www.appsflyer.com/privacy-policy/.
Intel is committed to respecting your privacy.

To learn more about Intel’s privacy practices, please visit http://www.intel.com/privacy.

*Other names and brands may be claimed as the property of others. All product information and prices are not determined and set by Intel but by their owner and may be subject to change without notice.

Using OpenCL™ 2.0 Read-Write Images

$
0
0

Acknowledgements

We want to thank Javier Martinez, Kevin Patel, and Tejas Budukh for their help in reviewing this article and the associated sample.

Introduction

Prior to OpenCL™ 2.0, there was no ability to read and write to an image within the same kernel. Images could always be declared as a “CL_MEM_READ_WRITE”, but once the image was passed to the kernel, it had to be either “__read_only” or “__write_only”.

input1 = clCreateImage(
oclobjects.context,
CL_MEM_READ_WRITE|CL_MEM_COPY_HOST_PTR,&format,&desc,&input_data1[0],&err );
SAMPLE_CHECK_ERRORS( err );

Code 1. Image buffer could be created with CL_MEM_READ_WRITE

__kernel void Alpha( __read_write image2d_t inputImage1,
__read_only image2d_t
inputImage2,
uint width,
uint height,
float alpha,
float beta,
int gamma )

Code 2. OpenCL 2.0 introduced the ability to read and write to images in Kernels

The addition, while intuitive, comes with a few caveats that are discussed in the next section.

The value of Read-Write Images

While Image convolution is not as effective with the new Read-Write images functionality, any image processing technique that needs be done in place may benefit from the Read-Write images. One example of a process that could be used effectively is image composition.

In OpenCL 1.2 and earlier, images were qualified with the “__read_only” and __write_only” qualifiers. In the OpenCL 2.0, images can be qualified with a “__read_write” qualifier, and copy the output to the input buffer. This reduces the number of resources that are needed.

Since OpenCL 1.2 images are either read_only or write_image. Performing an in-place modifications of an image requires treating the image as a buffer and operating on the buffer (see cl_khr_image2d_from_buffer: https://software.intel.com/en-us/articles/using-image2d-from-buffer-extension.

The current solution is to treat the images as buffers, and manipulate the buffers. Treating 2d images as buffers many not be a free operation and prevents clamping and filtering abilities available in read_images from being used. As a result, it may be more desirable to use read_write qualified images.

Overview of the Sample

The sample takes two windows bitmap images “input1.bmp” and “input2.bmp” and puts them into an image buffer. These images are then composited based on the value of the alpha, a weight factor in the equation of the calculated pixel, which can be passed in as an option.

Using Alpha value 0.84089642

Figure 1. Using Alpha value 0.84089642

The images have to be either 24/32-bit images. The output is a 24-bit image. The images have to be of the same size. The images were also of the Format ARGB, so when loading that fact was taken into consideration.

Using Alpha value of 0.32453

Figure 2. Using Alpha value of 0.32453

The ARGB is converted to RGBA. Changing the value of the beta value causes a significant change in the output.

Using the Sample SDK

The SDK demonstrates how to use image composition with Read write images. Use the following command-line options to control this sample:

Options

Description

-h, --help

Show this text and exit

-p, --platform number-or-string

Select platform, devices of which are used

-t, --type all | cpu | gpu | acc | default | <OpenCL constant for device type>

Select the device by type on which the OpenCL Kernel is executed

-d, --device number-or-string

Select the device on which all stuff is executed

-i, --infile 24/32-bit .bmp file

Base name of the first .bmp file to read. Default is input1.bmp

-j, --infile 24/32-bit .bmp file

Base name of the second .bmp file to read Default is input2.bmp

-o, --outfile 24/32-bit .bmp file

Base name of the output to write to. Default is output.bmp for OCL1.2 and 20_output.bmp for OCL2.0

-a, --alpha floating point value between 0 and 1

Non-zero positive value that determines how much the two images will blend in composition. Default alpha is 0.84089642. Default beta value is 0.15950358.

The sample SDK has a number of default values that allow the application to be able to run without any user input. The user will be able to use their input .bmp files. The files have to be either 24/32 bmp files as well. The alpha value is used to determine how much prominence image one will have over image 2 as such:

calculatedPixel = ((currentPixelImage1 * alpha) + (currentPixeImage2 * beta) + gamma);

The beta value is determined by subtracting the value of the alpha from 1.

float beta = 1 – alpha;

These two values determine the weighted distribution of images 1 to image 2.

The gamma value can be used to brighten each of the pixels. The default value is 0. But user can brighten the overall composited image. 

Example Run of Program

Read Write Image Sample Program running on OCL2.0 Device

Figure 3. Program running on OpenCL 2.0 Device

Limitations of Read-Write Images

Barriers cannot be used with images that require synchronization across different workgroups. Image convolution requires synchronizing all threads. Convolution with respect to images usually involves a mathematical operation on two matrices that results in the creation of a third matrix. An example of an image convolution is using Gaussian blur. Other examples are image sharpening, edge detection, and embossing.

Let’s use Gaussian blur as an example. A Gaussian filter is a low pass filter that removes high frequency values. The implication of this is to reduce detail and eventually cause a blurring like effect. Applying a Gaussian blur is the same as convolving the image with a Gaussian function that is often called the mask. To effectively show the functionality of Read-Write images, a horizontal and vertical blurring had to be done.

In OpenCL 1.2, this would have to be done in two passes. One kernel would be exclusively used for the horizontal blur, and another does the vertical blur. The result of one of the blurs would be used as the input of the next one depending on which was done first.

__kernel void GaussianBlurHorizontalPass( __read_only image2d_t inputImage, __write_only image2d_t outputImage, __constant float* mask, int maskSize)
{
    int2 currentPosition = (int2)(get_global_id(0), get_global_id(1));
    float4 currentPixel = (float4)(0,0,0,0);
    float4 calculatedPixel = (float4)(0,0,0,0);
    for(int maskIndex = -maskSize; maskIndex < maskSize+1; ++maskIndex)
    {
        currentPixel = read_imagef(inputImage, imageSampler, currentPosition + (int2)(maskIndex, 0));
        calculatedPixel += currentPixel * mask[maskSize + maskIndex];
    }
    write_imagef(outputImage, currentPosition, calculatedPixel);
}

__kernel void GaussianBlurVerticalPass( __read_only image2d_t inputImage, __write_only image2d_t outputImage, __constant float* mask, int maskSize)
{
    int2 currentPosition = (int2)(get_global_id(0), get_global_id(1));
    float4 currentPixel = (float4)(0,0,0,0);
    float4 calculatedPixel = (float4)(0,0,0,0); 
    for(int maskIndex = -maskSize; maskIndex < maskSize+1; ++maskIndex)
    {
        currentPixel = read_imagef(inputImage, imageSampler, currentPosition + (int2)(0, maskIndex));
        calculatedPixel += currentPixel * mask[maskSize + maskIndex];
    }
    write_imagef(outputImage, currentPosition, calculatedPixel);
}

Code 3. Gaussian Blur Kernel in OpenCL 1.2

The idea for the OpenCL 2.0 would be to combine these two kernels into one. Use a barrier to force the completion of each of the horizontal or vertical blurs before the next one begins.

__kernel void GaussianBlurDualPass( __read_only image2d_t inputImage, __read_write image2d_t tempRW, __write_only image2d_t outputImage, __constant float* mask, int maskSize)
{
    int2 currentPosition = (int2)(get_global_id(0), get_global_id(1));
    float4 currentPixel = (float4)(0,0,0,0);  
    float4 calculatedPixel = (float4)(0,0,0,0)
    currentPixel = read_imagef(inputImage, currentPosition);
    for(int maskIndex = -maskSize; maskIndex < maskSize+1; ++maskIndex)
    {
        currentPixel = read_imagef(inputImage, currentPosition + (int2)(maskIndex, 0));     
        calculatedPixel += currentPixel * mask[maskSize + maskIndex];
    }
    write_imagef(tempRW, currentPosition, calculatedPixel);

    barrier(CLK_GLOBAL_MEM_FENCE);

    for(int maskIndex = -maskSize; maskIndex < maskSize+1; ++maskIndex)
    {
        currentPixel = read_imagef(tempRW, currentPosition + (int2)(0, maskIndex));
        calculatedPixel += currentPixel * mask[maskSize + maskIndex];
    }
    write_imagef(outputImage, currentPosition, calculatedPixel);
}

Code 4. Gaussian Blur Kernel in OpenCL 2.0

Barriers were found to be ineffective. Using a barrier does not guarantee that the horizontal blur is completed before the vertical blur begins, assuming you did the horizontal blur first. The implication of this was an inconsistent result in multiple runs. Barriers can be used to synchronize threads within a group. The reason the problem occurs is that edge pixels are read from multiple workgroups, and there is no way to synchronize multiple workgroups. The initial assumption that we can implement a single Gaussian blur using read_write images proved incorrect because the inter-workgroup data dependency cannot be synchronized in OpenCL.

References

About the Authors

Oludemilade Raji is a Graphics Driver Engineer at Intel’s Visual and Parallel Computing Group. He has been working in the OpenCL programming language for 4 years and contributed to the development of the Intel HD Graphics driver including the development of OpenCL 2.0.

 

Robert Ioffe is a Technical Consulting Engineer at Intel’s Software and Solutions Group. He is an expert in OpenCL programming and OpenCL workload optimization on Intel Iris and Intel Iris Pro Graphics with deep knowledge of Intel Graphics Hardware. He was heavily involved in Khronos standards work, focusing on prototyping the latest features and making sure they can run well on Intel architecture. Most recently he has been working on prototyping Nested Parallelism (enqueue_kernel functions) feature of OpenCL 2.0 and wrote a number of samples that demonstrate Nested Parallelism functionality, including GPU-Quicksort for OpenCL 2.0. He also recorded and released two Optimizing Simple OpenCL Kernels videos and GPU-Quicksort and Sierpinski Carpet in OpenCL 2.0 videos.

 

You might also be interested in the following:

Optimizing Simple OpenCL Kernels: Modulate Kernel Optimization

Optimizing Simple OpenCL Kernels: Sobel Kernel Optimization

GPU-Quicksort in OpenCL 2.0: Nested Parallelism and Work-Group Scan Functions

Sierpiński Carpet in OpenCL 2.0

Downloads

Intel® XDK FAQs - General

$
0
0
Q1: How can I get started with Intel XDK?

There are plenty of videos and articles that you can go through here to get started. You could also start with some of our demo apps that you think fits your app idea best and learn or take parts from multiple apps.

Having prior understanding of how to program using HTML, CSS and JavaScript* is crucial to using Intel XDK. Intel XDK is primarily a tool for visualizing, debugging and building an app package for distribution.

You can do the following to access our demo apps:

  • Select Project tab
  • Select "Start a New Project"
  • Select "Samples and Demos"
  • Create a new project from a demo

If you have specific questions following that, please post it to our forums.

Q2: Can I use an external editor for development in Intel® XDK?

Yes, you can open your files and edit them in your favorite editor. However, note that you must use Brackets* to use the "Live Layout Editing" feature. Also, if you are using App Designer (the UI layout tool in Intel XDK) it will make many automatic changes to your index.html file, so it is best not to edit that file externally at the same time you have App Designer open.

Some popular editors among our users include:

  • Sublime Text* (Refer to this article for information on the Intel XDK plugin for Sublime Text*)
  • Notepad++* for a lighweight editor
  • Jetbrains* editors (Webstorm*)
  • Vim* the editor
Q3: How do I get code refactoring capability in Brackets*, the code editor in Intel® XDK?

You will have to add the "Rename JavaScript* Identifier" extension and "Quick Search" extension in Brackets* to achieve some sort of refactoring capability. You can find them in Extension Manager under File menu.

Q4: Why doesn’t my app show up in Google* play for tablets?

...to be written...

Q5: What is the global-settings.xdk file and how do I locate it?

global-settings.xdk contains information about all your projects in the Intel XDK, along with many of the settings related to panels under each tab (Emulate, Debug etc). For example, you can set the emulator to auto-refresh or no-auto-refresh. Modify this file at your own risk and always keep a backup of the original!

You can locate global-settings.xdk here:

  • Mac OS X*
    ~/Library/Application Support/XDK/global-settings.xdk
  • Microsoft Windows*
    %LocalAppData%\XDK
  • Linux*
    ~/.config/XDK/global-settings.xdk

If you are having trouble locating this file, you can search for it on your system using something like the following:

  • Windows:
    > cd /
    > dir /s global-settings.xdk
  • Mac and Linux:
    $ sudo find / -name global-settings.xdk
Q6: When do I use the intelxdk.js, xhr.js and cordova.js libraries?

The intelxdk and xhr libraries are only needed with legacy build tiles. The Cordova* library is needed for all. When building with Cordova* tiles, intelxdk and xhr libraries are ignored and so they can be omitted.

Q7: What is the process if I need a .keystore file?

Please send an email to html5tools@intel.com specifying the email address associated with your Intel XDK account in its contents.

Q8: How do I rename my project that is a duplicate of an existing project?

Make a copy of your existing project directory and delete the .xdk and .xdke files from them. Import it into Intel XDK using the ‘Import your HTML5 Code Base’ option and give it a new name to create a duplicate.

Q9: How do I try to recover when Intel XDK won't start or hangs?
  • If you are running Intel XDK on Windows* it must be Windows* 7 or higher. It will not run reliably on earlier versions.
  • Delete the "project-name.xdk" file from the project directory that Intel XDK is trying to open when it starts (it will try to open the project that was open during your last session), then try starting Intel XDK. You will have to "import" your project into Intel XDK again. Importing merely creates the "project-name.xdk" file in your project directory and adds that project to the "global-settings.xdk" file.
  • Rename the project directory Intel XDK is trying to open when it starts. Create a new project based on one of the demo apps. Test Intel XDK using that demo app. If everything works, restart Intel XDK and try it again. If it still works, rename your problem project folder back to its original name and open Intel XDK again (it should now open the sample project you previously opened). You may have to re-select your problem project (Intel XDK should have forgotten that project during the previous session).
  • Clear Intel XDK's program cache directories and files.
    On a [Windows*] machine this can be done using the following on a standard command prompt (administrator not required):
    > cd %AppData%\..\Local\XDK
    > del *.* /s/q
    To locate the "XDK cache" directory on [OS X*] and [Linux*] systems, do the following:
    $ sudo find / -name global-settings.xdk
    $ cd <dir found above>
    $ sudo rm -rf *
    You might want to save a copy of the "global-settings.xdk" file before you delete that cache directory and copy it back before you restart Intel XDK. Doing so will save you the effort of rebuilding your list of projects. Please refer to this question for information on how to locate the global-settings.xdk file.
  • If you save the "global-settings.xdk" file and restored it in the step above and you're still having hang troubles, try deleting the directories and files above, along with the "global-settings.xdk" file and try it again.
  • Do not store your project directories on a network share (Intel XDK currently has issues with network shares that have not yet been resolved). This includes folders shared between a Virtual machine (VM) guest and its host machine (for example, if you are running Windows* in a VM running on a Mac* host). This network share issue is a known issue with a fix request in place.

Please refer to this post for more details regarding troubles in a VM. It is possible to make this scenario work but it requires diligence and care on your part.

  • There have also been issues with running behind a corporate network proxy or firewall. To check them try running Intel XDK from your home network where, presumably, you have a simple NAT router and no proxy or firewall. If things work correctly there then your corporate firewall or proxy may be the source of the problem.
  • Issues with Intel XDK account logins can also cause Intel XDK to hang. To confirm that your login is working correctly, go to the Intel XDK App Center and confirm that you can login with your Intel XDK account. While you are there you might also try deleting the offending project(s) from the App Center.

If you can reliably reproduce the problem, please send us a copy of the "xdk.log" file that is stored in the same directory as the "global-settings.xdk" file to mailto:html5tools@intel.com.

Q10: Is Intel XDK an open source project? How can I contribute to the Intel XDK community?

No, It is not an open source project. However, it utilizes many open source components that are then assembled into Intel XDK. While you cannot contribute directly to the Intel XDK integration effort, you can contribute to the many open source components that make up Intel XDK.

The following open source components are the major elements that are being used by Intel XDK:

  • Node-Webkit
  • Chromium
  • Ripple* emulator
  • Brackets* editor
  • Weinre* remote debugger
  • Crosswalk*
  • Cordova*
  • App Framework*
Q11: How do I configure Intel XDK to use 9 patch png for Android* apps splash screen?

Intel XDK does support the use of 9 patch png for Android* apps splash screen. You can read up more at http://developer.android.com/tools/help/draw9patch.html on how to create a 9 patch png image. We also plan to incorporate them in some of our sample apps to illustrate their use.

Q12: How do I stop AVG from popping up the "General Behavioral Detection" window when Intel XDK is launched?

You can try adding nw.exe as the app that needs an exception in AVG.

Q13: What do I specify for "App ID" in Intel XDK under Build Settings?

Your app ID uniquely identifies your app. For example, it can be used to identify your app within Apple’s application services allowing you to use things like in-app purchasing and push notifications.

Here are some useful articles on how to create an App ID for your

iOS* App

Android* App

Windows* Phone 8 App

Q14: Is it possible to modify Android* Manifest through Intel XDK?

You cannot modify the AndroidManifest.xml file directly with our build system, as it only exists in the cloud. However, you may do so by creating a dummy plugin that only contains a plugin.xml file which can then be add to the AndroidManifest.xml file during the build process. In essence, you need to change the plugin.xml file of the locally cloned plugin to include directives that will make those modifications to the AndroidManifext.xml file. Here is an example of a plugin that does just that:

<?xml version="1.0" encoding="UTF-8"?><plugin xmlns="http://apache.org/cordova/ns/plugins/1.0" id="com.tricaud.webintent" version="1.0.0"><name>WebIntentTricaud</name><description>Ajout dans AndroidManifest.xml</description><license>MIT</license><keywords>android, WebIntent, Intent, Activity</keywords><engines><engine name="cordova" version=">=3.0.0" /></engines><!-- android --><platform name="android"><config-file target="AndroidManifest.xml" parent="/manifest/application"><activity android:configChanges="orientation|keyboardHidden|keyboard|screenSize|locale" android:label="@string/app_name" android:launchMode="singleTop" android:name="testa" android:theme="@android:style/Theme.Black.NoTitleBar"><intent-filter><action android:name="android.intent.action.SEND" /><category android:name="android.intent.category.DEFAULT" /><data android:mimeType="*/*" /></intent-filter></activity></config-file></platform></plugin>

You can check the AndroidManifest.xml created in the apk, using the apktool with the command line:  

aapt l -M appli.apk >text.txt  

This adds the list of files of the apk and details of the AndroidManifest.xml to text.txt.

Q15: How can I share my Intel XDK app build?

You can send a link to your project via an email invite from your project settings page. However, a login to your account is required to access the file behind the link. Alternatively, you can download the build from the build page, onto your workstation, and push that built image to some location from which you can send a link to that image. 

Q16: Why does my iOS build fail when I am able to test it successfully on a device and the emulator?

Common reasons include:

  • Your App ID specified in the project settings do not match the one you specified in Apple's developer portal.
  • The provisioning profile does not match the cert you uploaded. Double check with Apple's developer site that you are using the correct and current distribution cert and that the provisioning profile is still active. Download the provisioning profile again and add it to your project to confirm.
  • In Project Build Settings, your App Name is invalid. It should be modified to include only alpha, space and numbers.
Q17: How do I add multiple domains in Domain Access? 

Here is the primary doc source for that feature.

If you need to insert multiple domain references, then you will need to add the extra references in the intelxdk.config.additions.xml file. This StackOverflow entry provides a basic idea and you can see the intelxdk.config.*.xml files that are automatically generated with each build for the <access origin="xxx" /> line that is generated based on what you provide in the "Domain Access" field of the "Build Settings" panel on the Project Tab. 

Q18: How do I build more than one app using the same Apple developer account?

On Apple developer, create a distribution certificate using the "iOS* Certificate Signing Request" key downloaded from Intel XDK Build tab only for the first app. For subsequent apps, reuse the same certificate and import this certificate into the Build tab like you usually would.

Q19: How do I include search and spotlight icons as part of my app?

Please refer to this article in the Intel XDK documentation. Create an intelxdk.config.additions.xml file in your top level directory (same location as the other intelxdk.*.config.xml files) and add the following lines for supporting icons in Settings and other areas in iOS*.

<!-- Spotlight Icon --><icon platform="ios" src="res/ios/icon-40.png" width="40" height="40" /><icon platform="ios" src="res/ios/icon-40@2x.png" width="80" height="80" /><icon platform="ios" src="res/ios/icon-40@3x.png" width="120" height="120" /><!-- iPhone Spotlight and Settings Icon --><icon platform="ios" src="res/ios/icon-small.png" width="29" height="29" /><icon platform="ios" src="res/ios/icon-small@2x.png" width="58" height="58" /><icon platform="ios" src="res/ios/icon-small@3x.png" width="87" height="87" /><!-- iPad Spotlight and Settings Icon --><icon platform="ios" src="res/ios/icon-50.png" width="50" height="50" /><icon platform="ios" src="res/ios/icon-50@2x.png" width="100" height="100" />

For more information related to these configurations, visit http://cordova.apache.org/docs/en/3.5.0/config_ref_images.md.html#Icons%20and%20Splash%20Screens.

For accurate information related to iOS icon sizes, visit https://developer.apple.com/library/ios/documentation/UserExperience/Conceptual/MobileHIG/IconMatrix.html

NOTE: The iPhone 6 icons will only be available if iOS* 7 or 8 is the target.

Cordova iOS* 8 support JIRA tracker: https://issues.apache.org/jira/browse/CB-7043

Q20: Does Intel XDK support Modbus TCP communication?

No, since Modbus is a specialized protocol, you need to write either some JavaScript* or native code (in the form of a plugin) to handle the Modbus transactions and protocol.

Q21: How do I sign an Android* app using an existing keystore?

Uploading an existing keystore in Intel XDK is not currently supported but you can send an email to html5tools@intel.com with this request. We can assist you there.

Q22: How do I build separately for different Android* versions?

Under the Projects Panel, you can select the Target Android* version under the Build Settings collapsible panel. You can change this value and build your application multiple times to create numerous versions of your application that are targeted for multiple versions of Android*.

Q23: How do I display the 'Build App Now' button if my display language is not English?

If your display language is not English and the 'Build App Now' button is proving to be troublesome, you may change your display language to English which can be downloaded by a Windows* update. Once you have installed the English language, proceed to Control Panel > Clock, Language and Region > Region and Language > Change Display Language.

Q24: How do I update my Intel XDK version?

When an Intel XDK update is available, an Update Version dialog box lets you download the update. After the download completes, a similar dialog lets you install it. If you did not download or install an update when prompted (or on older versions), click the package icon next to the orange (?) icon in the upper-right to download or install the update. The installation removes the previous Intel XDK version.

Q25: How do I import my existing HTML5 app into the Intel XDK?

If your project contains an Intel XDK project file (<project-name>.xdk) you should use the "Open an Intel XDK Project" option located at the bottom of the Projects List on the Projects tab (lower left of the screen, round green "eject" icon, on the Projects tab). This would be the case if you copied an existing Intel XDK project from another system or used a tool that exported a complete Intel XDK project.

If your project does not contain an Intel XDK project file (<project-name>.xdk) you must "import" your code into a new Intel XDK project. To import your project, use the "Start a New Project" option located at the bottom of the Projects List on the Projects tab (lower left of the screen, round blue "plus" icon, on the Projects tab). This will open the "Samples, Demos and Templates" page, which includes an option to "Import Your HTML5 Code Base." Point to the root directory of your project. The Intel XDK will attempt to locate a file named index.html in your project and will set the "Source Directory" on the Projects tab to point to the directory that contains this file.

If your imported project did not contain an index.html file, your project may be unstable. In that case, it is best to delete the imported project from the Intel XDK Projects tab ("x" icon in the upper right corner of the screen), rename your "root" or "main" html file to index.html and import the project again. Several components in the Intel XDK depend on this assumption that the main HTML file in your project is named index.hmtl. See Introducing Intel® XDK Development Tools for more details.

It is highly recommended that your "source directory" be located as a sub-directory inside your "project directory." This insures that non-source files are not included as part of your build package when building your application. If the "source directory" and "project directory" are the same it results in longer upload times to the build server and unnecessarily large application executable files returned by the build system. See the following images for the recommended project file layout.

Q26: I am unable to login to App Preview with my Intel XDK password.

On some devices you may have trouble entering your Intel XDK login password directly on the device in the App Preview login screen. In particular, sometimes you may have trouble with the first one or two letters getting lost when entering your password.

Try the following if you are having such difficulties:

  • Reset your password, using the Intel XDK, to something short and simple.

  • Confirm that this new short and simple password works with the XDK (logout and login to the Intel XDK).

  • Confirm that this new password works with the Intel Developer Zone login.

  • Make sure you have the most recent version of Intel App Preview installed on your devices. Go to the store on each device to confirm you have the most recent copy of App Preview installed.

  • Try logging into Intel App Preview on each device with this short and simple password. Check the "show password" box so you can see your password as you type it.

If the above works, it confirms that you can log into your Intel XDK account from App Preview (because App Preview and the Intel XDK go to the same place to authenticate your login). When the above works, you can go back to the Intel XDK and reset your password to something else, if you do not like the short and simple password you used for the test.

Q27: How do I completely uninstall the Intel XDK from my system?

See the instructions in this forum post: https://software.intel.com/en-us/forums/topic/542074. Then download and install the latest version from http://xdk.intel.com.

Q28: Is there a tool that can help me highlight syntax issues in Intel XDK?

Yes, you can use the various linting tools that can be added to the Brackets editor to review any syntax issues in your HTML, CSS and JS files. Go to the "File > Extension Manager..." menu item and add the following extensions: JSHint, CSSLint, HTMLHint, XLint for Intel XDK. Then, review your source files by monitoring the small yellow triangle at the bottom of the edit window (a green check mark indicates no issues).

Q29: How do I manage my Apps in Development?

You can manage them by logging into: https://appcenter.html5tools-software.intel.com/csd/controlpanel.aspx. This functionality will eventually be available within Intel XDK after which access to app center will be removed.

Q30: I need help with the App Security API plugin; where do I find it?

Visit the primary documentation book for the App Security API and see this forum post for some additional details.

Q31: When I install my app onto my test device Avast antivirus flags it as a possible virus, why?

If you are receiving a "Suspicious file detected - APK:CloudRep [Susp]" message it is likely due to the fact that you are side-loading the app onto your device (using a download link or by using adb) or you have downloaded your app from an "untrusted" store. See the following official explanation from Avast:

Your application was flagged by our cloud reputation system. "Cloud rep" is a new feature of Avast Mobile Security, which flags apks when the following conditions are met:
  1. The file is not prevalent enough; meaning not enough users of Avast Mobile Security have installed your APK.
  2. The source is not an established market (Google Play is an example of an established market).
If you distribute your app using Google Play (or any other trusted market) your users should not see any warning from Avast.

Back to FAQs Main

Intel Resources for Game Developers

$
0
0


"Thank you for making games! Intel is a strong supporter of game development, and we've assembled all our best information to help you get your game running great on Intel hardware. Intel® HD Graphics and Intel® IrisTM/IrisTM  Pro Graphics parts are some of the most commonly used graphics solutions in PCs worldwide (see http://store.steampowered.com/hwsurvey/videocard/). By following the advice on these pages and using the tools we provide, you'll ensure that your game is able to be enjoyed by millions of gamers. We want you to be successful! Get what you need here, and if you can't find something, let us know in our game developer forum." - Aaron Coday, Director, Visual Computing Engineering, Intel Corporation

Intel wants to help game developers optimize their programs so they run, look, and play great on the developers' platforms of choice. Intel offers documentation, tools, code samples, case studies and events to help with development and optimization. The below lists are provided to quickly direct you to information of interest.

Developer Guides and Reference Manuals

Intel provides comprehensive graphics API usage guides for our hardware, going back to 2011, as well as other documentation:

Code Samples (https://software.intel.com/gamecode)

Considered the most helpful pieces by many developers, Intel offers a wide variety of code samples. Here's some links but be sure to see OpenCL code samples below.

Tools for Optimizing Games and Graphics for Intel® Processors

At Intel, we believe we have created the best processing hardware for computing. We know that it's not always easy to harness that processing power, so we've built powerful software tools for analyzing your application on Intel hardware. Our best tools for graphics are collected here.

Intel® Graphics Performance Analyzers (Intel® GPA)

This tool covers OpenCL and DirectX and shows high-level performance metrics for the CPU. You can capture a frame for detailed analysis and on-the-fly tweaking. Intel GPA Platform View can show you detailed interaction between the CPU and graphics. Articles and Guides on Intel GPA include:

Intel® VTune™ Amplifier XE 2015 

Performance analysis tool targeted for users developing serial and multithreaded applications. The tool is delivered as VTune Amplifier XE Performance Profiler and VTune Amplifier for Systems Performance Profiler and Intel Energy Profiler

Analyzing Applications Using Intel® HD Graphics

Intel® Integrated Native Developer Experience (Intel® INDE)

Intel® C++ Compiler 15.0

OpenCL Optimization

At Intel, we know that OpenCL is for more than just image manipulation. Here's our best resources for game developers who want to leverage OpenCL.

OpenCL Code Samples

OpenGL (Android)

Unity

DirectX* 12

Case Studies

Many PC game developers have already had success using our tools to improve their games' performance. For some, we've written about what challenges they faced and what solutions they found. We hope these case studies will be helpful for your own efforts. Maybe we'll be writing about your game next!    https://software.intel.com/en-us/gamedev/learn

Presentations from GDC2015 

Upcoming events- https://software.intel.com/en-us/game-dev/events
 

Achievement Unlocked: Site and Q&A

For more info about game development on Intel processor graphics, visit the Intel® game development community. There you’ll find useful references for everything from multithreading to audio. If you have more questions, including driver questions, head to the forums. If you can’t find the answer to your question above, you can visit the Intel® HD Graphics support page.


Step by Step guide to build iOS apps using UI builder of Multi-OS Engine of Intel INDE

$
0
0

Author: Yash Oswal

If you have reached this article, I presume you know what Intel Multi-OS Engine is capable of and its cool new features. If not, refer to these articles - Why Multi-OS Engine? and the Technical Overview of Multi-OS Engine.

This article specifically talks about the UI Builder. Multi-OS Engine(MOE) provides its own UI builder to build iOS apps which is similar to Android layout to build but has view objects similar to that of iOS. In this tutorial I am going to build a simple Quiz application for iOS using MOE and its UI builder.

Step 1: To build any MOE application first make a stock Android sample application like this:       

Step 2: Then right click on the android project and select Intel MOE Module to create a new module.

Step 3: Then select stock Hello World Application as a starting point for making the app.

Step 4: Name your application and click finish

Step 5: These are the files that are created by MOE.

Step 6: Next click on the sample_design.ixml file to start editing your UI.

Step 7: As you can see some parameters are already set as default like initialViewController and its viewController. You can set parameters according to your own needs.

Step 8: After deleting the default label and button you can start adding your own view objects. Method of adding object is quite simple you just have to drag and drop just like android layout.

Step 9: You can set all the parameters related to your UI in the properties tab. The parameters here are quite similar to those seen on Xcode.

Step 10: Here add two labels and two buttons to make the UI of the app.

Step 11: Name the iboutlets for all the view objects that you place in your UI.

Step 12: And set up your IBActions for buttons under events. 

Step 13: The MOE auto-generates all the IBOutlets and IBActions in the corresponding Java viewcontroller file.

Step 14: Now add the class variables corresponding to all the view objects in UI and assign them their corresponding IBOutlets in viewDidLoad method.

Step 15: Now create a QuizDataSet.java file which can work as a data source for the app and instantiate its object in the AppViewController class.

Step 16: Next set the texts of the Question and Answer Labels in the Action methods showQuestion and showAnswer.

Step 17: After this just run the app. 

Voila! You have designed your first iOS app with the UI designer of the Multi-OS Engine.

PhonoPaper Optimization using Intel® tools

$
0
0

Download PDF

PhonoPaper is a technology and an application that allows you to play audio converted into a picture of a special format, called a spectrogram on paper or any other surface. The process is roughly as follows: 10 seconds of audio (voice, song excerpt, etc.) are converted into a picture of a special format. The printed picture can, for example, be stuck to a wall. Passersby, noticing the code, launch the PhonoPaper scanner on their phones, aim the camera at the image and in an instant begin to hear the sound encoded in it. The user is fully involved in the process—the direction and speed of playback depend on the movement of the user's hands (although there is also an automatic mode). All the necessary information is stored in the image and Internet access is not required.

An example of Phonopaper in action:

PhonoPaper aroused keen interest among musicians, artists, and fans of unusual experiments. In the 3rd quarter of 2014, the application took first place in the Intel Developer Rating project on the Apps4All.ru website. Thanks to an x86-based Android* tablet Intel loaned me for testing, the app has been improved and optimized. Here, I’ll show how I optimized PhonoPaper.

Video capture

The first thing I did was to connect the Intel® INDE Media for Mobile set of libraries, specifically, the GLCapture class which captures video with an OpenGL ES* surface in real time (in HD sound quality). Why is this necessary? First, the process of capturing and playing PhonoPaper codes is a fun, exciting spectacle like playing an unusual musical instrument. Second, PhonoPaper can operate in free mode, when the sound is converted indiscriminately, such as with a carpet and cat. Both would be great to record and upload to YouTube*.

Free mode example: any camera image is perceived as a sound spectrum.

PhonoPaper codes, drawn by hand


The process of connecting GLCapture has been described in several  articles (1, 2 ). I'll just mention a few points that are good to know before starting.

You should use Android version 4.3 or later. For older devices, I created a cross-platform MJPEG recorder, the speed and quality of which is of course much inferior to hardware-accelerated GLCapture which writes in mp4. But still, it gets the job done.

The application must be built on the basis of OpenGL ES 2.0. My program historically used version 1.1, so I had to rewrite the code. But the transition to OpenGL ES 2.0 ultimately had a positive impact on productivity, as it gave the opportunity to manually adjust the shaders.

GLCapture can write sound from a microphone. This is good if you want video that accompanies your comments. If you need high-quality sound directly from the application, you should record it in a separate file and then combine it with the mp4. For combining them, you can use MediaComposer with the SubstituteAudioEffect effect from the Media for Mobile set. Another way is recording to WAV, encoding WAV to AAC, and adding the AAC track to the mp4 file using the mp4parser library.

Since PhonoPaper is written in Pixilang programming language, the function of captu­ring video can later be used with other pixilang-based applications (PixiTracker, PixiVisor, Nature - Oscillator, Virtual ANS), and most importantly, will be available for all developers using Pixilang. At the same time, access is very easy (there are only a few options: start capture, stop, and save).

Pixilang is an open cross-platform programming language, customized to work with sound and graphics. The language syntax is highly minimalistic and is a hybrid of BASIC and C, which together with other features (the ability to write code without functions and universal containers for storing any data) reduces the entry threshold.

Intel® C++ Compiler and optimization

The next step was to assemble the x86 Android version of PhonoPaper using the Intel® C Compiler and compare the results with GCC 4.8. I use Debian Linux*, and a rather old version at that. Therefore, the first problem was to find the appropriate version of the Intel C++ Compiler. Fortunately, the right installation package was found – Intel® System Studio 2015. Despite the warning during installation, everything worked well and the first assembly was successful.

The compilation works with the following keys: -xATOM_SSSE3 -ipo -fomit-frame-pointer -fstrict-aliasing -finline-limit=300 -ffunction-sections -restrict. To test the performance of the Pixilang virtual machine (it is the basis of all my applications) small tests were written, and the sources and results of them can be viewed in this archive (zip). As a result, even without preparation, some code fragments were accelerated 5-fold(!). This is quite impressive!

In PhonoPaper, most of the load is for the spectral synthesizer function (table-wave, not FFT) – wavetable_generator (). For it, a single test was written that renders an audio stream with a random spectrum within four seconds. At the end of the test, the highest possible sampling frequency is produced. Unfortunately, the Intel C Compiler did not perform well here: 105 kHz compared to 100 kHz on GCC. By adding the -qopt-report=2 key during compilation, this message displays in the report:

loop was not vectorized: vector dependence prevents vectorization.

The main loop within our function could not be vectorized because input data indicators can point to overlapping memory areas:

int* amp = (int*)amp_cont->data

int* amp_delta = (int*)amp_delta_cont->data;


Viewing the code, I see that at this point the intersection has been eliminated and I just need to tell the compiler. In C/C++ there is a special keyword, restrict, stating that the declared indicator points to a block of memory, which is not pointed to by any other indicator. Therefore, I replace the above code with this:

int* restrict amp = (int*)amp_cont->data;

int* restrict amp_delta = (int*)amp_delta_cont->data;


Then, I assemble the application and see that the cycle is successfully vectorized. With some additional changes (in the process, it proved that it is possible to eliminate a few bit operations), the result is now 190 kHz. Taking these amendments into account, GCC gave 130 kHz—a 1.46-fold performance increase!

What is next?

As you can see, the results are very positive. PhonoPaper now runs faster (thanks largely to the Intel C++ compiler) and was extended with the functionality of the video capture. In addition, the video recording will appear in a few simple functions in the next Pixilang 3.6 update.

This optimization helped with even doing things like recording, printing, and then playing back voice codes.

There’s lots to explore with PhonoPaper!

About the Author

Alexander Zolotov is a software developer, demoscener, composer, and sound and graphics designer. He is the owner of WarmPlace.ru website. He developed several audio-visual applications: SunVox (modular synth and tracker), Virtual ANS, PhonoPaper, PixiTracker, and Pixilang programming language.

Tutorial: Using Intel® INDE GPA to improve the performance of your Android* game

$
0
0

Download PDF

Introduction

This tutorial presents a step-by-step guide to performance analysis, bottleneck identification, and rendering optimization of an OpenGL ES* 3.0 application on Android*. The sample application, entitled “City Racer,” simulates a road race through a stylized urban setting.  Performance analysis of the application is done using the Intel® INDE Graphics Performance Analyzers (Intel® INDE GPA) tool suite.

City Racer Icon
The combined city and vehicle geometry consists of approximately 230K polygons (690K vertices) with diffuse mapped materials lit by a single non-shadow casting directional light.  The provided source material includes the code, project files, and art assets required to build the application, including the source code optimizations identified throughout this tutorial.

 

Acknowledgements

This tutorial is an Android and OpenGL ES 3.0 version of the Intel Graphics Performance Workshop for 3rd Generation Intel® Core™ Processor (Ivy Bridge) (PDF) created by David Houlton.  It ships with Intel INDE GPA.

Tutorial Organization

This tutorial guides you through four successive optimization steps.  At each step the application is analyzed with Intel INDE GPA to identify specific performance bottlenecks.  An appropriate optimization is then toggled within the application to overcome the bottleneck and it is analyzed again to measure the performance gained.  The optimizations applied are generally in line with the guidelines provided in the Developer’s Guide for Intel® Processor Graphics (PDF).

Over the course of the tutorial, the applied optimizations improve the rendering performance of City Racer by 83%.

Prerequisites

 

City Racer Sample Application

City Racer is logically divided into race simulation and rendering subcomponents.  Race simulation includes modeling vehicle acceleration, braking, turning parameters, and AI for track following and collision avoidance.  The race simulation code is in the track.cpp and vehicle.cpp files and is not affected by any of the optimizations applied over the course of this tutorial.

The rendering component consists of drawing the vehicles and scene geometry using the OpenGL ES 3.0 and our internally developed CPUT framework.  The initial version of the rendering code represents a first-pass effort, containing several performance-limiting design choices.

Mesh and texture assets are loaded from the Media/defaultScene.scene file.  Individual meshes are tagged as either pre-placed scenery items, instanced scenery with per-instance transformation data, or vehicles for which the simulation provides transformation data.  There are several cameras in the scene:  one follows each car and an additional camera allows the user to freely explore the scene.  All performance analysis and code optimizations are targeted at the vehicle-follow camera mode.

For the purpose of this tutorial, City Racer is designed to start in a paused state, which allows you to walk through each profiling step with identical data sets.  City Racer can be unpaused by unchecking the Pause check box in the City Racer HUD or by setting g_Paused = false at the top of CityRacer.cpp.

 

Optimization Potential

Consider the City Racer application as a functional but non-optimized prototype.  In its initial state it provides the visual result desired, but not the rendering performance.  It has a number of techniques and design choices in place that are representative of those you’d find in a typical game-in-development that limits the rendering performance.  The goal of the optimization phase of development is to identify the performance bottlenecks one by one, make code changes to overcome them, and measure the improvements achieved.

Note that this tutorial addresses only a small subset of all possible optimizations that could be applied to City Racer.  In particular, it only considers optimizations that can be applied completely in source code, without any changes to the model or texture assets.  Other asset-changing optimizations are excluded here simply because they become somewhat cumbersome to implement in tutorial format, but they can be identified using Intel INDE GPA tools and should be considered in a real-world game optimization.

Performance numbers shown in this document were captured on an Intel® Atom™ processor-based system (codenamed Bay Trail) running Android.  The numbers may differ on your system, but relative performance relationships should be similar and logically lead to the same performance optimizations.

The optimizations to be applied over the course of the tutorial are found in CityRacer.cpp. They can be toggled through City Racer’s HUD or through direct modification in CityRacer.cpp.

CityRacer.cpp

CityRacer.cpp

bool g_Paused = true;
bool g_EnableFrustumCulling = false;
bool g_EnableBarrierInstancing = false;
bool g_EnableFastClear = false;
bool g_DisableColorBufferClear = false;
bool g_EnableSorting = false;

They are enabled one by one as you progress through the optimization steps.  Each variable controls the substitution of one or more code segments to achieve the optimization for that step of the tutorial.

 

Optimization Tutorial

The first step is to build and deploy City Racer on an Android device.  If your Android environment is set up correctly, the buildandroid.bat file located in CityRacer/Game/Code/Android will perform these steps for you. 

Next, launch Intel INDE GPA Monitor, right click the system tray icon, and select System Analyzer.

System Analyzer will show a list of possible platforms to connect to. Choose your Android x86 device and press “Connect.”

System Analyzer - Choose your Android x86 device

When System Analyzer connects to your Android device, it will display a list of applications available for profiling. Choose City Racer and wait for it to launch.

System Analyzer - a list of applications available for profiling

While City Racer is running, press the frame capture button to capture a snapshot of a GPU frame to use for analysis.

Capture a snapshot of a GPU frame to use for analysis

Examine the Frame

Open Frame Analyzer for OpenGL* and choose the City Racer frame you just captured, which will allow you to examine GPU performance in detail.

Open Frame Analyzer for OpenGL* to examine GPU performance

The timeline corresponds to an OpenGL draw call

The timeline at the top is laid out in equally spaced ‘ergs’ of work, each of which usually corresponds to an OpenGL draw call.  For a more traditional timeline display, select GPU Duration on the X and Y axis. This will quickly show us which ergs are consuming the most GPU time and where we should initially focus our efforts.  If no ergs are selected, then the panel on the right shows our GPU time for the entire frame, which is 55ms.

GPU duration

Optimization 1 – Frustum Culling

When viewing all of the draws, we can see that there are many items drawn that are not visually apparent on the screen.  By changing the Y-axis to Post-Clip Primitives the gaps in this view serve to point out which draws are wasted because the geometry is entirely clipped.

A view-frustum culling routine

The buildings in City Racer are combined into groups according to spatial locations. We can cull out the groups not visible and thus eliminate the GPU work associated with them. By toggling the Frustum Culling check box, each draw will be run through a view-frustum culling routine on the CPU before being submitted to the GPU.

Turn on the Frustum Culling check box and use System Analyzer to capture another frame.  Once the frame is captured, open it again in Frame Analyzer.

Frame Analyzer after frustum culling option enabled

By viewing this frame we can see the number of draws is reduced by 22% from 740 to 576 and our overall GPU time is reduced by 18%.

Frustum Culling Draw calls

Frustum Culling GPU duration

Optimization 2 – Instancing

While frustum culling reduced the overall amount of ergs, there are still a great number of small ergs (highlighted in yellow) which, when taken cumulatively, add up to a non-trivial amount of GPU time.

A non-trivial amount of GPU time

By examining the geometry for these ergs we can see the majority of them are the concrete barriers which line the sides of the track.

Concrete barriers which line the sides of the track

We can eliminate much of the overhead involved in these draws by combining them into a single instanced draw.  By toggling the Barrier Instancing check box the barriers will be combined into a single instanced draw thus removing the need for the CPU to submit each one of them via a draw to the GPU.

Turn on the Barrier Instancing check box and use System Analyzer to capture another frame.  Once the frame is captured, open it with Frame Analyzer.

Frame Analyzer - after barrier instancing enabled

By viewing this frame we can see the number of draws is reduced by 90% from 576 to 60.

Draw calls before concrete barrier instancing

Draw calls after concrete barrier instancing

Draw calls before concrete barrier instancing (top) and after instancing (bottom)

Additionally, the GPU duration is reduced by 71% to 13ms.

Instancing gpu duration

Optimization 3 – Front to Back Sorting

The term “overdraw” refers to writing to each pixel multiple times; this can impact pixel fill rate and increase frame rendering time.  Examining the Samples Written metric shows us that each pixel is being written to approximately 1.8 times per frame (Resolution / Samples Written).

Output Merger

Sorting the draws from front to back before rendering is a relatively straightforward way to reduce overdraw because the GPU pipeline will reject any pixels occluded by previous draws.

Turn on the Sort Front to Back check box and use System Analyzer to capture another frame.  Once the frame is captured, open it with Frame Analyzer.

Frame Analyzer after enabling sort front to back

By viewing this frame we can see the Samples Written metric decreased by 6% and our overall GPU time is reduced by 8%.

Output Merger after enabling sort front to back

GPU duration after enabling sort front to back

 

Optimization 4 – Fast Clear

A final look at our draw times shows the first erg is taking the longest individual GPU time.  Selecting this erg reveals that it’s not a draw but a glClear call.

First erg taking the longest individual GPU time

glClear call

Intel’s GPU hardware has an optimization path that performs a ‘fast clear’ in a fraction of the time it takes a traditional clear.  A fast clear can be performed by setting the glClearColor to all black or all white (0, 0, 0, 0 or 1, 1, 1, 1).

Turn on the Fast Clear check box and use System Analyzer to capture another frame.  Once the frame is captured, open it with Frame Analyzer.

Frame Analyzer after enabling fast clear

By viewing this frame we can see the GPU duration for the clear has decreased by 87% over the regular clear, from 1.2ms to 0.2ms.

GPU duration for the clear decreased

GPU duration for the clear decreased

As a result, the overall frame duration of the GPU is decreased by 24% to 9.2ms.

The overall frame duration of the GPU decreased

 

Conclusion

This tutorial has taken a representative early-stage game application and used the Intel INDE GPA to analyze application behavior and make targeted changes to improve performance.  The changes made and improvements realized were:

OptimizationBeforeAfter% Improvement
Frustum Culling55.2ms45.0ms82%
Instancing45.0ms13.2ms71%
Sorting13.2ms12.1ms8%
Fast Clear12.1ms9.2ms24%
Overall GPU Optimizations55.2ms9.2ms83%

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark* and MobileMark*, are measured using specific computer systems, components, software, operations and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products. For more information go to http://www.intel.com/performance.

Overall, from the initial implementation of City Racer to the best optimized version, we demonstrate rendering performance improvement of 300%, from 11 fps to 44 fps.  Since this implementation starts out significantly sub-optimal, a developer applying these techniques will probably not see the same absolute performance gain on a real-world game.

Nevertheless, the primary goal of this tutorial is not the optimization of this specific sample application, but the potential performance gains you can find by following the recommendations in Developer’s Guide for Intel Processor Graphics and the usefulness of Intel INDE GPA in finding and measuring those improvements.

Porting Guide for Unity* Game on Intel® Architecture for China Market

$
0
0

Download PDF

Overview

Unity* software is one of the most popular game engines for the mobile environment (Android* and iOS*). As technology improves, especially as GPUs in mobile chips get faster, players are demanding more 3D mobile games. According to Wikipedia, there are over 1.2 billion of mobile deivce users in China in 2014, nearly 4 times than that of United States. With the growth in mobile market share of Intel® processors in the People’s Republic of China (PRC), developers want to know how to enable their Unity-based games for Intel® Architecture for Android phones/tablets in China,  a unique booming market where apps are not distributed/sold by Google Play. China has some unique situations that require game developer to take certain measures when developing and porting their games for this most active and fast growing country, which this article covers.

 

General porting guide for a Unity game

It is very easy to port an ARM*-based Unity game to Intel Architecture if the game doesn’t have any plugins. We will show you how.

First, download Unity version 4.6 or higher. Then open your game project with Unity. On the File menu select Build settings. You will see the window below.

Unity game - Project Build settings

After choosing Android and clicking the Player Settings button, a configuration window will be shown as below.

Unity Build settings - Android player settings

Make sure the device filter option is FAT or x86, then build the project. You will get an APK that supports x86 native.

However, we’re not done yet. Mobile games are a bit more complicated because they contain third-party plugins for performing various tasks.

 

The impact of plugins  on game porting

Most Unity games use plugins that provide added-value services. In China, the plugins tend to be the ones listed below:

Plugin TypeComments
Payment SDKIn-app purchase
Security SDKProtect app with re-compile
Exception Handler SDKDebug game in remote
Advertisement SDKProvide advertisement within game
Platform Access SDKProvide account services for online game
Data Statistics SDKCollect users’ information to back-end server
Cloud Push SDKPush notification from server

More complete descriptions of each plugin are given below.

Payment SDK

Many independent software vendors (ISV) focus on revenue collection in game development. An effective way to do this is in-app purchase, which needs a payment plugin. In China there are lots of payment vendors such as Alipay, Caifutong, and Wechat payment to name a few. Additionally, telecom operators, such as China Mobile, China Unicom, and China Telecom, have payment plugins for ISVs.

Security SDK

Most game code for the Android platform is developed in Java*, which is compiled to a DEX file. This file is an easy target of a decompile hack. Because of this, security for --- is needed. Ijiami, 360, Bangbang, and Najia are all main security vendors in China market.

Exception handler SDK

Debugging software for Android usually includes checking logs, setting breakpoints, and observing running parameters step by step. When a crash happens, it can be more effective to dump the crash information, especially after the application has been released. This information includes platform registers and the call stack. Some ISVs combine exception handlers to games for tracking log information. So, as an example, PRC ISV Tencent developed an SDK called Bugly that integrates all Tencent’s applications and games exceptions.

Advertisement SDK

Like in-app purchases, advertising integrated in games is yet another business model for game developers to make revenue.

Platform Access SDK

Many games, especially online games, want players to have accounts in order to record their progress and store scores in back servers. So popular PRC account systems like QQ and Wechat have been embedded in games.

Data Statistics SDK

Data Statistic SDKs record game player’s statistics, which developers can then use to optimize and modify the game.

Cloud Push SDK

This SDK sends notification to users from a server.

When enabling an Android game to x86 native, all related SDKs must be ported to x86 before plug into Unity; otherwise, the game will not run well on Intel Architecture-based platforms.

Here is good example for Unity plugin to enable to x86 native.

Unity plugin to enable to x86 native

 

Case Study: We Fire

We Fire is the first 3D first person shooter mobile game from Tencent Lightspeed Studio. It has more than 137 million registered users and 26 million active users per month; it’s one of the most popular mobile games in China right now.

The ARM version of We Fire has 11 libraries in the lib/armeabi-v7a folder, but only three libraries, libunity.so, libmain.so, and libmono.so, are actually responsible for the gaming rendering. The others are all plugins. For example, libtpnsSecurity.so is a plugin SDK for game security with anti-theft and anti-reverse engineering.

We fire - ARM version has 11 libraries

First, we need to port all libraries in this folder to x86 native like below.

We Fire - porting 11 libraries to x86 native

However, the game crashed when this APK was installed on x86 Android 5.0 due to a libwbsafeedit library, which is an ARM binary hidden in the assets folder.

We Fire - ARM binary hidden in the assests folder

When we enabled this library for x86 as below, the app worked well on an Intel Architecture-based device.

We Fire - app works on an intel architecture based device

But not all libraries can be ported to x86 native easily. Take the library libBugly.so as an example. It is responsible for tracing crash information and uploading it to the cloud. It also gets stack information from NDK C/C++ code, so it involves ASM functions of the system platform. Before it can be compiled to x86 native successfully, we had to rewrite parts of the code from ARM to x86.

 

Performance Comparison

We ran some performance comparisons between the ARM version and x86 version on an x86 device. The results are below.

Performance Comparison between the ARM version and x86 version

After porting, the average power consumption improved about 10% than when running via Native Bridge. And the CPU and RAM utilization rates were reduced 26% and 21% respectively.

In addition, the APK size of Fat (ARM+x86) is just 9 MB more than the ARM version.

We FireAPK Size
ARM234M
Fat (X86+ARM)243M

Software and workloads used in performance tests may have been optimized for performance only on Intel microprocessors. Performance tests, such as SYSmark* and MobileMark*, are measured using specific computer systems, components, software, operations and functions. Any change to any of those factors may cause the results to vary. You should consult other information and performance tests to assist you in fully evaluating your contemplated purchases, including the performance of that product when combined with other products. Configurations: [describe config + what test used + who did testing]. For more information go to http://www.intel.com/performance.

 

Conclusion

For creating Android games with Unity, you’ll see a performance benefit on Intel Architecture by porting to x86 native. But the Unity engine is not the only thing that must be ported; all the related plugins must be ported as well. If you want to successfully port a Unity game to x86 native, you should do the porting for these plugins in advance.

 

About the Author

Tao Peng is a software apps engineer in the Intel Software and Services Group. He currently focuses on gaming enabling and performance optimization, in particular on Android mobile platforms.

 

Adaptive Volumetric Shadow Maps for Android* Using OpenGL* ES 3.1

$
0
0

 

Download PDF

As a follow-up to Adaptive Volumetric Shadow Maps for DirectX* 11, we present a port of the same algorithm adapted for Android* devices that support OpenGL ES* 3.1 and the GL_INTEL_fragment_shader_ordering OpenGL* extension.

Beyond being just a simple port, this version includes a number of optimizations and tradeoffs that allow the algorithm to run on low power mobile devices (such as tablets and phones), in contrast to the previous sample which targeted Ultrabook™ system-level hardware.

The AVSM algorithm allows for generation of dynamic shadowing and self-shadowing for volumetric effects such as smoke, particles, or transparent objects in real-time rendering engines using today’s Intel® hardware.

To achieve this, each texel of the AVSM shadow map stores a compact approximation of the transmittance curve along the corresponding light ray.

Transmittance curve expressed using 4 nodes
Transmittance curve expressed using 4 nodes

The main innovation of the technique is a new streaming compression algorithm that is capable of building a constant-storage, variable-error representation of a visibility curve that represents the light ray’s travel through the media that can be used in later shadow lookups. This essentially means that every time a new partial shadow caster (light occluder) is added to the shadow map, the algorithm performs an optimal lossy compression of the transmittance curve – for each texel individually.

 reduction from 4 to 3 nodes by removal of the least visually significant node (A)
Lossy compression: reduction from 4 to 3 nodes by removal of the least visually significant node (A)

This algorithm relies on the GL_INTEL_fragment_shader_ordering OpenGL extension that enforces deterministic shader execution order on the per-pixel level based on triangle submission order. This accomplishes two important goals that are needed by the AVSM algorithm:

  • Synchronization, allowing for thread-safe data structure access.
  • Per-pixel shader execution ordering (based on triangle submission order), allowing for deterministic behavior of lossy compression between subsequent frames, which prevents temporal visual artifacts (“flickering”) that otherwise appear.

On DirectX 11 this feature is available through Intel Pixel Synchronization Extension, or, more recently, natively through DirectX 11.3 and DirectX 12 feature called Raster Order Views.

Example of AVSM smoke shadows (disabled - left, enabled - right) in Lego Minifigures* Online
Example of AVSM smoke shadows (disabled - left, enabled - right) in Lego Minifigures* Online by Funcom Productions A/S

Below is a list of the main differences between the Android and the original DirectX implementations. The differences are mostly focused on optimizing the algorithm performance for low power target hardware such as tablets and phones:

  1. Transparent smoke particles are rendered into a lower resolution frame buffer and blended to the native resolution render target to reduce the blending cost of the high overdraw. This is not an AVSM-specific optimization but was necessary for such an effect to be practical on the target hardware.
  2. In some scenarios, mostly when shadow casters are not moving too quickly in reference to the AVSM shadow map matrix, the shadow map can be updated only every second frame to reduce the cost. To balance computation across both frames, some operations (such as clearing the buffers) can then be performed in the alternate frame.
  3. Only every second smoke particle can be added to AVSM map but with twice the opacity. This slightly reduces visual quality but improves insertion performance by a factor of two.
  4. To reduce the cost of sampling the AVSM shadows, the sampling can be moved from per-pixel to per-vertex frequency. The old (DirectX11) sample uses screen space tessellation to achieve this at no quality loss compared to per-pixel sampling. This sample, however, uses a geometry shader to output a fixed billboard quad made up of four triangles and five vertices. AVSM sampling and interpolation using a five vertex quad (one in the middle in addition to four corners) provides good balance between quality and performance better suited to target hardware.
  5. For receiver geometry that is always behind shadow casters (such as the ground), full sampling is unnecessary and replaced by only reading the value of the last node.

Sample running on Tesco hudl2* device with Android*
Sample running on Tesco hudl2* device with Android*

The sample UI provides ways of toggling on/off or tweaking most of the above listed optimizations, as a way of demonstrating the cost and visual quality tradeoffs.

The sample code will run on any OpenGL ES 3.1 device that supports GL_INTEL_fragment_shader_ordering extension. Devices that support that extension include Intel® Atom™ processor-based tablets (code named Bay Trail or Cherry Trail).

Please refer to README.TXT included in the archive for build instructions.

Based on Adaptive Volumetric Shadow Maps, EGSR 2010 paper by Marco Salvi.

Viewing all 554 articles
Browse latest View live