Snowflake SDK - C++ multi-touch application framework

Table of contents

• Snowflake SDK - C++ multi-touch application framework
• Requirements
  • Installing Boost
• Microsoft Visual Studio projects management
  • Using Microsoft Visual Studio solution (manually prepared)
    • Set additional include directories
    • Preprocessor definitions
    • Linker input directories and output file name
    • Additional linker dependencies
    • Installation of application after building
  • Using CMake to auto-generate Microsoft Visual Studio projects
• Compilation of tutorial applications
• Debugging of tutorial applications
  • Setting Visual Studio binaries
  • Setting Visual Studio project
• Adding new applications to main Snowflake Suite menu
• Configuration file
• How to create new Snowflake Suite application
  • Blobz header as main include
  • Implementing functions from BaseApplication class

Requirements

First of all you need to download the Snowflake SDK.

Snowflake SDK is built based on several different libraries. Most libraries are included in the package. Due to the size of the Boost library set, it is not included to keep the size of the download file within proportion. Boost is a collection of C++ libraries, which are Open Source. Boost is freely available for download from http://boost.org/users/download/. Check Installing Boost paragraph for more details.

Back

Installing Boost

To install Boost, go to http://boost.org/users/download/ and download a suitable version not older than the 1.35 version.
Getting Started section, which can be found at www.boost.org, describes in detail the process of the installation and the compilation of Boost libraries.



During the rest of the installation process of Snowflake SDK, it is assumed that Boost is successfully installed.

When utilizing CMake for creating and managing of Visual Studio solutions, it isn't necessary to manually set up VC++ directories, as CMake can find and add directories to Boost automatically for project properties.

Nevertheless, to avoid any problems with compilation or linking, it is advised to add Boost's headers and libraries' directories to the Visual Studio look-up directories list. To do so, follow the steps below:

• in Microsoft Visual Studio go to Tools/Options...,
• in popped up window choose Projects and Solutions/VC++ Directories,
• in right panel switch "Show directories for:" to "Include files",
• click on "New line" icon and browse to your boost directory (e.g. C:/Program Files/boost/boost_1_35_0),
• change "Show directories for:" field to "Library files",
• click on "New line" icon and browse to boost/lib directory (e.g. C:/Program Files/boost/boost_1_35_0/lib),
• confirm with OK at the bottom of the window.

Back

Microsoft Visual Studio projects management

Currently NUITEQ provides two ways of handling Visual Studio projects – one is the manual creation and management using build-in properties of Visual Studio project, the latter is creating and modifying projects using CMake build system.

It is strongly encouraged to use CMake, as it is easy to use and makes it easy to switch between different versions of IDE's. However, for developers unfamiliar with that build system, it might be a bit overwhelming at first. Therefore a manually prepared Visual Studio solution, is provided.

Back

Using Microsoft Visual Studio solution (manually prepared)

Manually created Visual Studio solution for tutorial applications, is placed in VS2005_sln subdirectory of the SDK. As the name suggests, those projects are prepared for Visual Studio 2005 (with Service Pack 1), but are also compatible with Visual Studio 2008.

Set additional include directories

• Set Configuration to All Configurations
• In C/C++/General properties choose Additional Include Directories
• Add paths to directories containing headers for external libraries — for libraries shipped with Snowflake SDK, paste: ..\..\..\extern\Blobz\include;..\..\..\extern\Blobz\include\GLee;..\..\..\extern\SDL\include;..\..\..\extern\OpenAL\include;..\..\..\extern\DevIL\include
• Additional include directories can be set, e.g. Boost include directory, if it is wished to add Boost to the global Visual Studio look-up VC++ directories (check Installing Boost)

Back

Preprocessor definitions

While setting pre-processor definitions, one should NOT use All Configurations, as that will remove all already defined symbols, also necessary ones, as e.g. _DEBUG for Debug build or NDEBUG for Release.
All values (even if those values are equal for different configurations) should be set separately for each building configuration.
Definitions that are required:

• NUI_RELEASE_VERSION is the definition required by Snowflake Suite, to ensure that applications prepared with given versions of the SDK won't be used with incompatible versions of Snowflake Suite.

Back

Linker input directories and output file name

As with adding include directories for external libraries, it is necessary to add directories containing libraries (.lib files) to the linker, so it can link properly application to external libraries.
Browse manually to every path, where the external libraries are located and for libraries shipped within Snowflake SDK, paste the line:
..\..\..\extern\Blobz\lib;..\..\..\extern\SDL\lib;..\..\..\extern\OpenAL\lib;..\..\..\extern\DevIL\lib
Those directories are already set for all tutorial applications, both for manual and CMake generated Visual Studio solutions.

As shown in the above screen capture, it is also necessary to change the output file name of your application. Snowflake Suite can only load Dynamic-Link Libraries (DLL) with the .NUI extension. For debug builds, the application name should contain postfix “_d”, so that Snowflake Suite can distinguish a debug build from a release one and avoid loading debug applications with release runtime and vice versa.





Back

Additional linker dependencies

In case the linker knows which libraries should be linked with the application, libraries' names should by added that are wished to be linked.
Choose All Configurations only, if the names of libraries don't change between different runtime builds (e.g. we provide only one .lib file, but there are two DLL files, both called Blobz.dll, and those can differentiate by location, so one is in bin/debug subdirectory and the other is in bin/release).

Back

Installation of application after building

To test a new application, it is necessary to add the Post-Build Event. That will copy the output to proper location. With CMake a special stage is present, called Installation, that takes care of it. If the non-CMake built solution is called, add the Post-Build Event. Go to pthe roper location (showed at screenshot) and put the copy command as below:
xcopy /Y "$(TargetPath)" "$(SolutionDir)..\..\bin\applications\Tutorial1\"

Don't forget the quotation marks around the paths, to ensure its functioning with paths containing spaces.
Also the last subdirectory in destination path (Tutorial1 in example above) is the location of the application in the applications tree and has to be consistent with the application name, or it won't be found by Snowflake Suite.

Back

Using CMake to auto-generate Microsoft Visual Studio projects

As described in the previous paragraph, the manual preparation of a Visual Studio project, might be quite difficult and time consuming, especially if it is required to set it every time for each new project and each new application. That is the main reason, it is encouraged to use CMake for solution autogeneration.
To do so, download CMake from http://www.cmake.org/cmake/resources/software.html.
For tutorial applications, the main CMakeLists.txt file is located in root SDK directory.
Most of the settings can be easily copied from the tutorial applications CMake files.

The basic CMakeLists file, that can be used to build a Snowflake Suite application is shown below. This file should be placed with the source code, in INSTALL/projects/executable/apps/%Application_name% .
%Application_name% directory should be also added to CMake tree, so follow to INSTALL/projects/executable/apps/ directory and add a line to CMakeLists.txt file:

ADD_SUBDIRECTORY( %Application_name% )

Of course, %Application_name% is name of subdirectory, where your code and your CMakeLists.txt is.

Project(Tutorial1)

FILE(GLOB SRCS *.cpp *.h)
ADD_LIBRARY(Tutorial1 SHARED ${SRCS})
TARGET_LINK_LIBRARIES(Tutorial1 ${APP_LIBRARIES_WINDOWS} blobz.lib)

SET_TARGET_PROPERTIES(Tutorial1 PROPERTIES SUFFIX ".nui")

IF(WIN32)
	INSTALL(TARGETS Tutorial1 RUNTIME DESTINATION ${NUI_APP_DIR}/Tutorial1)
ELSE(WIN32)
	INSTALL(TARGETS Tutorial1 LIBRARY DESTINATION ${NUI_APP_DIR}/Tutorial1)
ENDIF(WIN32)

The first line defines project name.
Then the expression is defined, letting it find files, that should be included into the project.
The ADD_LIBRARY command creates library. Tutorial1 in this line is name of the binary that will be made. The special word SHARED makes the library a shared library (in Windows it is dll library). Last variable, {SRCS}, should contain list of all files, that will be included in the project.
SET_TARGET_PROPERTIES command is used to set ".nui" extension to the output file (see Linker input directories and output file name for more information.
The last command creates installation rules, so the files can be copied in the correct locations after the compilation.
This is the simplest possible file, but it allows to properly compile the code. Compared to manual Visual Studio project setup, writing this kind of file is easier. Most of the setup processes are done in higher CMake files, so they are inherited by subprojects. That is why the file for the application can be that simple.

To create Visual Studio projects, start CMake application. Browse to the INSTALL folder and choose the location, where the projects will be stored (for example it might be INSTALL/build).


Click Configure button, choose the version of Visual Studio that is used and confirm with the OK button.
It will take a while, to configure the projects.
Click Configure one more time and then confirm with OK.


Open Visual Studio and go to File/Open/Project/Solution (or press Ctrl+Shift+o). Go to the directory that is pointed in the CMake GUI as the output location (for example INSTALL/build) and open the TutorialApps solution.


Right-click the INSTALL project and execute Build. It will compile all of the applications and copy the output files around, like set in CMakeLists.txt file.
Set the Debugging properties to start debugging the application (see Debugging of tutorial applications for more information).
Back

Compilation of tutorial applications

If you use non-CMake built solution, just build all projects in solutions. You should be able to build everything right away, but if not – make sure you carefully read whole Snowflake SDK - C++ multitouch application framework manual, especially this paragraph.
Using CMake, make sure you also build INSTALL project that appears in solution. That project doesn't compile anything, but it copies outputs from other projects in proper places (instead of Post-Build Event).

Back

Debugging of tutorial applications

Setting Visual Studio binaries

Snowflake SDK contains binaries for Visual Studio 2005 and Visual Studio 2008. During SDK installation you can choose, if you like to have support for Visual Studio 2005 (as Visual Studio 2008 binaries are default).


First you should choose setup type to Custom.


Then add VS2005 and VS2005_bin packages to install.
This way installer will copy both VS2008 and VS2005 binaries and install the latter as default.

You can switch between 2005 and 2008 binaries using Install VS200x Binaries scripts from Menu Start/Programs/Snowflake SDK directory.
To make sure you're using proper binaries, you can execute install script just after Snowflake SDK installation. It is completely safe to run any of the scripts at any time (e.g. nothing wrong will happen if you'd run VS2008 script even if binaries for Visual Studio 2008 have already been installed).

You should never try to start application built with Visual Studio 2008 using binaries for Visual Studio 2005 and vice versa, as it will always lead to heap corruption and crash.

Setting Visual Studio project

As creation of new applications means writing DLL libraries, we need some executable file to start our application. In our case it is Launcher.exe, main application of Snowflake Suite. To set it as starting program, go to Project Properties. Set Configuration to All Configurations and choose Debugging in left panel.
Set fields as advised below.
Command:
$(SolutionDir)..\..\bin\$(ConfigurationName)\Launcher.exe
Working Directory:
$(SolutionDir)..\..\bin\$(ConfigurationName)\
Using Visual Studio macros lets you set it once for all configurations, and will automatically copy output files to different locations because of $(ConfigurationName) variable, that is defined as property of build configuration.
To debug application, set breakpoint in suitable place and start debugging by pressing F5.

Back

Adding new applications to main Snowflake Suite menu

To add new application to main menu, add new subfolder to “INSTALL_PATH\BIN\applications” folder. Change the name of the folder, for example TutorialApp1, AND the .nui file in it (the name of the folder and .nui MUST have the same name) and fill the Media folder with new content. Copying .nui file should be set in Post-Build Event (check Installation of application after building) or as INSTALL command with CMake. Make new icons and put them in “INSTALL_PATH\BIN\application” named “MenuButtonPressed.png” and “MenuButtonUnpressed.png” accordingly with the function it should represent. Open up Globalmenu.xml and create a new line with application information accordingly to the folder and .nui file names.
For example:

<Button name="TutorialApp1" />

You can find more information about Global Menu in General Manual.

Back

Configuration file

Configuration file is located at INSTALL_PATH/Bin/ directory and is called Config.cfg.
It contains the most important settings for Snowflake Suite to work. All options contain description in Config.cfg file and it's name is consistent with it's functionality. Check General Manual for more information on possible configuration settings.

Back

How to create new Snowflake Suite application

To start writing new application, one should follow several important steps. This tutorial introduces those steps as well as describes how to setup working environment.

Blobz header as main include

To get access to most of our API, you should include header Blobz.h, which includes the most imortant parts of our libraries.
You can check it's content to see what exactly get included in it, but to start with developing Snowflake applications, it is just enough to add this header to your .h file.

Then, one of the most important classes you should get familiar with, is BlobData class.

class BLOBZ_API BlobData
{
	// (...)
public:
	/// ID number of this blob
	int mID;
	/// X position (0 to 1)
	float mX;
	/// Y position (0 to 1)
	float mY;
	/// X movement since last frame
	float mDX;
	/// Y movement since last frame
	float mDY;
	/// Size of blob
	float mArea;
	/// Angle of blob, not used at the moment
	float mAngle;
	/// The amount of time since this blob was detected
	float mTime;
	/// The camera that has spotted this blob
	int mCameraID;
};

This class contains all the information about inputs.

As most of our SDK, BlobData class is part of Blobz namespace.
We advice to add all new application to it's own namespace, to avoid ambiguity.

We start writing our application with adding main application class. This class should inherit from our BaseApplication class.
BaseApplication class introduces interface, that we use inside Snowflake Suite to call proper parts of given application.

Let's say we are going to write simple application, that will load image file, set is as a OpenGL texture and then display it in application window.

Like it was said, we start with simple class, that inherits from BaseApplication

namespace Tutorial
{
	class TutorApp : public Blobz::BaseApplication
	{
	public:
		TutorApp();
		~TutorApp();
	private:
		// Pointer on texture type used in Snowflake SDK.
		Blobz::Texture* mpExampleTexture;
	};
}

Now, we need some way to get around with most important things: loading/unloading resources, updating GUI and rendering objects (in our case - the texture). But there is no problem, because all of the thing is done in Snowflake, and we have quite nice interface in BaseApplication class.
If we look into BaseApplication definition, we will notice some nice functions in there.

namespace Blobz
{
	class Framework;

	/// Acts as the base class for all applications.                              
	class BLOBZ_API BaseApplication
	{
	public:
		BaseApplication();
		virtual ~BaseApplication();
		
		BaseApplication(const BaseApplication& that);
		BaseApplication& operator=(const BaseApplication& that);

	public: // Virtual member functions
		/// Should initialize everything needed in the application
		virtual bool onInitialize() { return false; }
		/// Should release everything needed in the application
		virtual void onDeinitialize(){};

		/// Should reload any OpenGL resources used by the application
		virtual void onReload(){};

		/// Is called when the application goes from shown to hidden
		virtual void onHide() { mVisible = false; }
		/// Is called when the application goes from hidden to shown
		virtual void onShow() { mVisible = true;}

		/// Should update everything in the application
		virtual void onUpdate(float inFrameTime){inFrameTime;}
		/// Should draw everything in the application
		virtual void onDraw(){}
		/// Is called upon an SDL_Event
		virtual void onEvent(SDL_Event &inEvent){inEvent;}

		/// Is called upon a finger down event inside this application
		virtual void onFingerDown(const BlobData& inData) {inData;}
		/// Is called upon a finger up event inside this application
		virtual void onFingerUp(const BlobData& inData) {inData;}
		/// Is called upon a finger update event inside this application
		virtual void onFingerUpdate(const BlobData& inData) {inData;}
		/// Is called when a finger leaves the application area (via a FingerUpdate event)
		virtual void onFingerExit(const BlobData& inData) {inData;}

		/// Is called when a gesture event has occurred inside the application window
		virtual void onGestureEvent(Gesture& inGesture) {inGesture;}
		/// Is called when resource is loaded (and bound) and ready to use
		virtual void onResourceLoaded(BaseResource* inLoadedResource)	{inLoadedResource;};

	public: // Get & Set
		ApplicationWindow& getWindow() 					{ return mWindow; }

		bool getExitState(void) { return mWantsExit; }

		bool getVisible() const							{ return mVisible; }
		void setVisible(bool inVisible)					{ mVisible = inVisible; }

		bool wantsExit() const							{ return mWantsExit; }
		void setWantsExit(bool inWantsExit)				{ mWantsExit = inWantsExit; }

		bool getExclusive() const						{ return mWindow.getExclusive(); }
		void setExclusive(bool inExclusive)				{ mWindow.setExclusive(inExclusive); }

		void setApplicationDirectory(std::string inDirectory) { mApplicationDirectory = inDirectory; }

	protected:

		/// Indicates whether the application is visible or not
		bool mVisible;

		/// Indicates whether the application wants to exit or not
		bool mWantsExit;

		/// A window object used to draw to
		ApplicationWindow mWindow;		

		/// The application's home directory
		std::string mApplicationDirectory;
	};
}

Well, we could use some of those :)
We should start with onInitialize and onDeinitialize events. Those two are called when our application is started and closed, respectively.
So it seems we need those in our application.
Next important would be onUpdate call, that will let us update our GUI.
We also need onDraw function, to draw our objects in application window.
Last set of functions are those responsible for finger events, so all onFinger* functions.

So at this point, our class would look like this.

#ifndef _TUTORAPP_H_
#define _TUTORAPP_H_

#include <Blobz.h>

namespace Tutorial
{
	class TutorApp : public Blobz::BaseApplication
	{
	public:
		TutorApp();
		~TutorApp();

	public:
		// Method called from BaseApplication when application get initialized (loaded).
		virtual bool onInitialize();
		// Method called when application is closing.
		virtual void onDeinitialize();

		// Should update everything in application. inFrameTime is time in seconds from last update.
		virtual void onUpdate(float inFrameTime);
		// Method called when application window is redrawn.
		virtual void onDraw();

		// Method called when finger is placed inside application window.
		virtual void onFingerDown(const Blobz::BlobData& inData);
		// Method called when finger is raised from touch surface (and was in application window before).
		virtual void onFingerUp(const Blobz::BlobData& inData);
		// Method called when finger is moved (update event).
		virtual void onFingerUpdate(const Blobz::BlobData& inData);
		// Method called when finger leaves application window area.
		virtual void onFingerExit(const Blobz::BlobData& inData);

	private:
		// Pointer on texture type used in Snowflake SDK.
		Blobz::Texture* mpExampleTexture;
	};
}

#endif

Basically, that's what we need in our .h file.
Now lets see, how we should implement functions, to get it running.

Implementing functions from BaseApplication class

Snowflake applications are dll libraries. If someone have ever written a dll libarary, then he knows, that it's necessary to export symbols when compiling that libary, and then import that symbols, when using that library. That person should notice, we didn't have any exported symbols in header - why ?
Snowflake Suite is using LoadLibrary function to load symbols from library during runtime, so we don't need header to know, what kind of functions are there. We assume though, that library containing Snowflake application has specific symbols exported.

First of those symbols is function GetInstance.

Blobz::BaseApplication* GetInstance();

As we can see, this function has to create instance of our class and return it as BaseApplication pointer. This way, using type polymorphism, we can easily call functions from given applications while code is executed in Snowflake. And we don't need any other exported symbols to do so.

The other symbol that is necessary is GetAppVersion function.

const char* GetAppVersion()

This function is necessary, to make sure we won't load incompatible application to Snowflake Suite. Although, it puts the resposibility on application developer to make sure application version is equal with Snowflake Suite version he is using (e.g. let's say application is developed with Snoflake SDK 1.8 and then there is update of Snowflake Suite to 1.9 - application developer should change value returned by that method to fit the needs of Snowflake Suite).

Lets see how our .cpp file should look like now.

#include "TutorApp.h"

extern "C" __declspec(dllimport)Blobz::BaseApplication* GetInstance()
{
	Tutorial::TutorApp* pTutor = new Tutorial::TutorApp();
	return (Blobz::BaseApplication*)pTutor;
}

extern "C" __declspec(dllimport)const char* GetAppVersion()
{
	return NUI_RELEASE_VERSION;
}

namespace Tutorial
{
	TutorApp::TutorApp()
	{
	}

	TutorApp::~TutorApp()
	{
	}
}

Now we should load our image file and make it into OpenGL texture, so we can draw it later.
Here we can use ResourceManager, a part of Snowflake SDK. Backbone of ResourceManager is DevIL library, so you can safely try loading all image formats supported by it.
ResourceManager provides both, blocking loading (so the resource is available right away after loading, but it blocks initialization, so application can't be showed until resource is loaded) and threaded loading (which doesn't block initialization phase, but it's handling is more complicated. Threaded loading example is presented in third tutorial included into Snowflake SDK).

In our case we will be loading only one, small image — so we can wait. Initialization and deinitialization part of code should look similar to this.

bool TutorApp::onInitialize()
{
	// Makes sure that the users can't change the aspectratio of the application in runtime.
	mWindow.setUseFixedRatio(true); 

	// Loads an image using the ResourceManager.
	// The bool in the end of the load function states if the loading should be blocking (true)
	// or if the program should continue with execution and data will be loaded in background (false - default).
	// Loading in background requires registration as listener to ResourceManager and handling onResourceLoaded events.
	mpExampleTexture = Blobz::ResourceManager::getInstance().load<Blobz::Texture>("../applications/Tutorial1/data/startPress.png", true);

	return (mpExampleTexture != NULL);
}

void TutorApp::onDeinitialize()
{
	Blobz::ResourceManager::getInstance().unload(mpExampleTexture);
}

As we don't have any GUI elements, we have nothing to update, so implementation of onUpdate method is empty.
The most interesting part of code is the one that draws objects on application window.

void TutorApp::onDraw()
{
	// This is for creating and assigning the render texture for the application.
	mWindow.enableRendering();

	// Screen setup, part of the SnowFlake framework.
	mWindow.defaultRenderSetup();

	/*	
		You can also send in a Blobz::Vector4 to defaultRenderSetup to change the glClearColor.
		mWindow.defaultRenderSetup(Blobz::Vector4(1,0,1,1); as an example.
	*/

	// This segment contains a mixed part of OpenGL and basic vector math.
	// Enables alpha blending.
	glEnable(GL_BLEND);
	glDisable(GL_DEPTH_TEST);
	glEnable(GL_TEXTURE_2D);

	// Binds the texture ID to OpenGL so it can be used.
	glBindTexture(GL_TEXTURE_2D, mpExampleTexture->getID()); 
	// Begin drawing GlQuads.
	glBegin(GL_QUADS); 

	// A standard 2 component vector, Blobz also contains vectors with 3 and 4 components.
	Blobz::Vector2 mPosition(0.3f,0.4f); 
	Blobz::Vector2 mSize(0.05f,0.05f);
	glColor4f(1, 1, 1, 1);
		glTexCoord2f(0,1);
		glVertex2f(mPosition.x-mSize.x,mPosition.y-mSize.y);
		glTexCoord2f(1,1);
		glVertex2f(mPosition.x+mSize.x,mPosition.y-mSize.y);
		glTexCoord2f(1,0);
		glVertex2f(mPosition.x+mSize.x,mPosition.y+mSize.y);
		glTexCoord2f(0,0);
		glVertex2f(mPosition.x-mSize.x,mPosition.y+mSize.y);
	glEnd();
	glDisable(GL_TEXTURE_2D);

	glEnable(GL_DEPTH_TEST);
	glDisable(GL_BLEND);

	mWindow.disableRendering(); // Wraps up the texture and draws it.
}

Most of the code in here is just OpenGL with some basic math. The important calls are mWindow.enableRendering() and mWindow.disableRendering().
Those are necessary to draw anything within the window.
At current state, as we are not have any objects to integrate with, all onFinger* methods can be empty.
Our .cpp file might look like this.

#include "TutorApp.h"

#ifdef WIN32
#ifdef Tutorial1_EXPORTS
#define TUTORIAL_API __declspec(dllexport)
#else
#define TUTORIAL_API __declspec(dllimport)
#endif
#else
#define TUTORIAL_API
#endif
extern "C" TUTORIAL_API Blobz::BaseApplication* GetInstance()
{
	Tutorial::TutorApp* pTutor = new Tutorial::TutorApp();
	return (Blobz::BaseApplication*)pTutor;
}

extern "C" TUTORIAL_API const char* GetAppVersion()
{
	return NUI_RELEASE_VERSION;
}

namespace Tutorial
{
	TutorApp::TutorApp()
	{
	}

	TutorApp::~TutorApp()
	{
	}

	bool TutorApp::onInitialize()
	{
		// Makes sure that the users can't change the aspectratio of the application in runtime.
		mWindow.setUseFixedRatio(true); 

		// Loads an image using the ResourceManager, Blobz::Texture can be replaced with things like Model and Audio.
		// The bool in the end of the load function states if the program should start load the data and proceed (Threaded loading)
		// or if the program should halt until the data is completely loaded.
		mpExampleTexture = Blobz::ResourceManager::getInstance().load<Blobz::Texture>("../applications/Tutorial1/data/startPress.png", true);

		return (mpExampleTexture != NULL);
	}

	void TutorApp::onDeinitialize()
	{
		Blobz::ResourceManager::getInstance().unload(mpExampleTexture);
	}

	void TutorApp::onUpdate(float inFrameTime)
	{
	}

	void TutorApp::onDraw()
	{
		// This is for creating and assigning the render texture for the application.
		mWindow.enableRendering(); 

		// Screen setup, part of the SnowFlake framework.
		mWindow.defaultRenderSetup();

		/*	
		You can also send in a Blobz::Vector4 to defaultRenderSetup to change the glClearColor.
		mWindow.defaultRenderSetup(Blobz::Vector4(1,0,1,1); as an example.
		*/

		// This segment contains a mixed part of OpenGL and basic vector math.
		// Enables alpha blending.
		glEnable(GL_BLEND);
		glDisable(GL_DEPTH_TEST);
		glEnable(GL_TEXTURE_2D);

		// Binds the texture ID to OpenGL so it can be used.
		glBindTexture(GL_TEXTURE_2D, mpExampleTexture->getID()); 
		// Begin drawing GlQuads.
		glBegin(GL_QUADS); 

		// A standard 2 component vector, Blobz also contains vectors with 3 and 4 components.
		Blobz::Vector2 mPosition(0.3f,0.4f); 
		Blobz::Vector2 mSize(0.05f,0.05f);
		glColor4f(1, 1, 1, 1);
		glTexCoord2f(0,1);
		glVertex2f(mPosition.x-mSize.x,mPosition.y-mSize.y);
		glTexCoord2f(1,1);
		glVertex2f(mPosition.x+mSize.x,mPosition.y-mSize.y);
		glTexCoord2f(1,0);
		glVertex2f(mPosition.x+mSize.x,mPosition.y+mSize.y);
		glTexCoord2f(0,0);
		glVertex2f(mPosition.x-mSize.x,mPosition.y+mSize.y);
		glEnd();
		glDisable(GL_TEXTURE_2D);

		glEnable(GL_DEPTH_TEST);
		glDisable(GL_BLEND);

		mWindow.disableRendering(); // Wraps up the texture and draws it.
	}

	void TutorApp::onFingerDown(const Blobz::BlobData& inData)
	{
	}

	void TutorApp::onFingerUp(const Blobz::BlobData& inData)
	{
	}

	void TutorApp::onFingerUpdate(const Blobz::BlobData& inData)
	{		
	}

	void TutorApp::onFingerExit(const Blobz::BlobData& inData)
	{
	}
}

Slightly extended version of this application is included in Snowflake SDK package as Tutorial1 application.

Back

---