Simulating a Storyboard application is a straightforward process. From the Navigator view, right-click the Storyboard designer file (*.gde) and select the Storyboard Simulator option.

Alternatively, you can select the Storyboard Simulator option from the toolbar ...

or the Storyboard Simulator Configurations from the toolbar ...

which will allow you to customize how the simulator is launched.  

The options include configuring which plug-ins are to be loaded by the simulator and what level of verbosity should be used to run the simulator.

When the simulator is launched it will perform an automatic export to a Storyboard Embedded Engine to a temporary directory and run the application in its own window on the host system.

Export a Storyboard Embedded Engine configuration from the main menu using File > Export.  This launches the export wizard.

Select the Storyboard Embeded Engine (GAPP) option and click Next. Select the Storyboard application file (*.gde) that you want to export and the output location that you want to export to.  

Select Finish to create the specified directory, create a Storyboard Embedded Engine (*.gapp) runtime file, and export the resources from the images, fonts, and scripts directories.

It also possible to perform headless exports of the Storyboard Design files to the Storyboard Embedded Engine files from a command line or scripting environment.

PATH_TO_INSTALL/Storyboard_Designer/storyboard/Storyboard -application com.crank.gdt.ui.gappexport model=<PathToGDEFile> output=<PathToGAPPFile>

Where the model is the full path to the Storyboard Designer model file and the output parameter specifies the filesystem path where the Storyboard Engine file will be created and the associated resources created.

Exporting as an Android application will create an Android package that is suitable for use on Android devices. The packages generated will only work on devices running Android version 2.3.3 and above.

To create an Android package, select File > Export to start the export wizard:

Select the Export as Native Android Application option and click Next. From the export file selection dialog, select the Storyboard application file (*.gde) that you want to export. Choose appropriate names for the application name, android package file name, and the package name. Select the directory you want to export to and options for application orientation and fullscreen. For Android devices version 4.4 and newer, the fullscreen option uses Android's sticky immersion fullscreen.

Click Next to bring up the a page with options for choosing a specific Storyboard Engine to use, setting Storyboard runtime options (see Storyboard Engine Options for list of available runtime options), and selecting the icons for the application. Click the tabs under Advanced Options to modify the default Permissions, Manifest file or Keystore settings (optional). If you don't need to alter the settings, just click Finish to use the defaults.

Select Finish to create the Android application package file (APK) in the directory specified. To transfer this application package to an Android device, simply copy the package onto a USB or SD card.

We have explored two tools for editing and creating translation content. The recommended tool is Open Office Calc as it has the capability to character encode (csv) files in UTF-8. Some applications, such as Microsoft Excel are unable to save (csv) files using UTF-8 character encoding. We discuss two methods to create UTF-8 character encoded (csv) files. One solution is more straightforward and uses Open Office Calc and the other is a solution using Microsoft Excel and Notepad.

Open Office Calc

It is free and can be downloaded from www.openoffice.org.

Microsoft Excel

The solution to create UTF-8 encoded (csv) files using Excel is to create a tab seperated file in Excel by saving as a unicode text file then replace the tabs with commas in Notepad, save the file and change the file extension to (csv) with encoding set to UTF-8.

More information about the Microsoft Excel solution can be found at https://help.salesforce.com/apex/HTViewSolution?id=000003837&language=en_US.

A complete description of OpenGL ES 2.0 shaders is beyond the scope of this document and is better treated in detail in the OpenGL ES Shader Language specification. This document will focus on the shader programming aspects that are relevant to Storyboard developers.

Storyboard provides the ability to hook in a fragment shader and/or a vertex shader to be associated with the rendering of a control element. The shaders are provided as files and are associated with the control through the Advanced tab of the control's properties. Here you can select either a specific file for either shader or bind the shaders to variables that will resolve to files in the project at runtime.

The shaders will be applied to the resulting texture that is the outcome of having all of the current render extensions applied to it. That is to say that the control is effectively rendered as it would be in the normal sense, but the final result is provided as a texture to the shaders to manipulate before it is finally rendered to the display.

Shader programs have three types of variables: attributes, varying, and uniforms. Attributes are passed into the shader from the render manager and contain data such as vertex locations, and texture coordinates. Varying variables are calculated in the vertex shader and passed into the fragment shader after being interpolated based upon the location of the fragment. Uniforms are also passed in from the render manager, but are typically used for purposes other than storing the geometry being rendered, for instance, containing a global alpha value which can be used to blend an entire model.

When writing a shader program, it is important to follow the conventions for attributes and uniforms established by the render manager. Otherwise, it will not be able to pass in geometric data and nothing will be rendered. Below is a minimal vertex shader which matches the functionality of the built in vertex shader for images.

attribute vec4 myVertex;
attribute vec4 myUV;
                            
varying vec2 vtex;

uniform mat4 projMatrix;
uniform mat4 mvMatrix;
                            
void main(void)
{
    gl_Position = projMatrix * mvMatrix * myVertex;
    vtex = myUV.st;
}
                        

The myVertex and myUV attributes contain vertex and texture coordinates respectively. The projMatrix and mvMatrix contain the projection and modelview matrices, which are used to transform the input vertex position, which is then assigned to the gl_Position for the vertex. The varying vtex is used to hold the interpolated texture coordinate which is then passed to the fragment shader. The render manager looks up myVertex, myUV, projMatrix and mvMatrix by name when it loads the shader, so these names must be used in any custom vertex shader. The varying name must match between the vertex shader and the fragment shader.

Below is a fragment shader which matches the functionality of the built in fragment shader for images, and shows the minimal code required to work with the Storyboard render manager.

#ifdef GL_ES
precision mediump float;
#endif
uniform sampler2D sampler2d;
varying vec2 vtex; 

void main (void)
{
    gl_FragColor = texture2D(sampler2d, vtex);
}
                        

The initial precision declaration is required by OpenGL ES, but not supported by OpenGL, and is set with a preprocessor conditional. The sampler2D uniform controls which texture unit is used when sampling a texture. The render manager only supports a single texture. The varying variable is interpolated based upon the vertex values in the vertex shader, and is passed into the sampler to look up the colour at the fragment location. This is assigned to gl_FragColor and becomes the fragment colour.

It is also possible to pass data from Storyboard variables to shader uniform variables, subject to two constraints: the model element for the variable must be the control for which the custom shaders are being used and the variable type must be float. When the custom shader is loaded, a list of all of the uniforms present is created. The name of each uniform is then compared to the list of variables attached to the control, and if a matching name of the appropriate type is found, it is used to the set the value of the uniform when the control is rendered.

As an example, consider animating a custom shader to do a simple fade-in based upon the value of a timer. First, create a variable of type float called "current_time" for the control with the custom shader. Then create an animation using the animation timeline which changes the value of the variable from 0.0 to 1.0 over a few seconds, and create an appropriate trigger for the animation, for instance a mouse press event. Then, edit your fragment shader as follows:

#ifdef GL_ES
precision mediump float;
#endif

uniform float current_time;
uniform sampler2D sampler2d;
varying vec2 vtex; 

void main (void)
{
    gl_FragColor = texture2D(sampler, vtex) * current_time;
}
                        

When the control is rendered, the value of the uniform current_time will be set from the value of the control variable current_time, which will cause the colour read from the texture to be scaled from 0.0 to 1.0 over the duration of the animation, causing a fade in effect.

The OpenGLES 2.0 render manager now supports compressed textures on supported hardware. The formats supported are PVRTC1, both 4BPP and 2BPP. This compression format is supported on most PowerVR graphics chipsets.

To determine if the chipset supports it, running Storyboard with a verbosity level of 6 (-vvvvvv_ will print out, on startup, the GLES extensions supported by the chip. If PVRTC is supported, you will see GL_IMG_texture_compression_pvrtc in the extension string list.

Storyboard will manually decode these images if the runtime being used does not support them. Should a project that was running on a PowerVR chip and using compressed images be run on a SW runtime that does not support them, the images would still decode and render correctly, just without HW acceleration.

PVRTC provides a 8x improvement in memory size (A 1024x1024x4 BMP would take 4MB of memory, whereas a PVRTC image would take 512K)

Compression tools can be found at:

Starting a multi-file application development is the same as starting a regular project since before you can have two projects, you need to have one project. Typically the initial project created will be the master application and will host the majority of the shared resource content. This is only a convention and not a technical requirement.

Once another application is required, for example to represent a distinctly themed area of the unified application, then you will want to create another Designer application model file within the base project.

You can create another application file in several ways:

Create a blank application using: File > New > Storyboard Application ... and select "New Model in Existing Project"

Import PSD content into a application: File > Import > PSD ... and select "Into an Existing Project and Existing File"

You can also simply copy and paste an existing application and rename the *.gde file to bootstrap a new design.

Doing this will result in multiple application model (*.gde) files that are all contained within the same project. They all reference the same image and script resources.

Screen transitions provide the means to tie together multiple applications to form a single, larger, unified application.

In order to indicate that one application (the source application) will be making a reference to screens in another application (external reference), the source application should list the external application in its Properties. Go to Application > Properties > External Model References

Once an application is added as an external reference, the screens from that application will show up in any of the Screen transition selection lists as well as any animation definitions..

Layers from any listed external applications can be added to an application by explicitly importing them using:

Add > Existing Layer > Import External Layer

Once a layer is added as an external layer, then a copy of the original layer from the external application is snapshotted and incorporated directly into the source application. At this point, the external layer can be used with any source application screens just like any other layers.

Once applications have been developed, shared content leveraged, and transitions between application screens established the next step is to simulate or export the unified application.

The Storyboard simulation configuration dialog, accessed via Run > Storyboard Simulator Configurations allows multiple model files to be specified as a comma separated list of model file names, or by selecting multiple files in the "Browse..." file selection dialog.

The first source application in the list will be used to determine the unified application's launch screen.

Similarly exporting a runtime application to be used with Storyboard Engine, Android, or iOS targets also allows multiple Storyboard application files to be selected. In these export scenarios, you will be prompted to select the source application that should be used for the unified application's launch screen.

If there are no conflicts among the selected applications they will be merged together and converted into a single unified application and used for the user-selected operation of simulation or export.

If there are conflicts among the resources then the differences will need to be resolved before continuing with an application merge.

When multiple applications are merged together to form a unified application, the following occurs:

The external referencing of model elements relies on names remaining consistent during the application development. In some instances, if names change it may be possible for content to become unsynchronized and it may need to be resynchronized on an application by application basis.

The application properties page provides a synchronization action that scans the project for externally referenced content and then compares that content to the source reference. If there is a difference, then the difference is flagged as a conflict for resolution and the user is prompted for different ways to solve the conflict based on the nature of the issue

When exporting to an iOS Device all related files and available plugins are packaged into a single application for the device. Since this is the case there is no need to set up environment variables or specify runtime options on the target, since this will all be done in storyboard designer when you export the application.

To configure an iOS device to run your apps you need to set up a few things from Apple first: