Monday, 27 August 2012

Intel Ultimate Coder Challenge - Part Three

The Past

Welcome back to my six part expedition into the development of my feature-packed Ultrabook app called Love Hearts®. 

I hope you had a great week and that you’re ready to go spelunking into the very heart of my code. Last week we took a detailed look at the app design and the development set-up. You may recall my insidious plan (or is that; insane plan), to write my own OpenGL library to replace the one that’s not there on the platform formerly known as Metro.

The Present

This week we’ll be looking at the code, and shedding some light on the challenges you will face when developing for the Ultrabook.  You may recall the project is split into a high level app which we call Love Hearts® and a low level technology we call AGK ( The low level code talks directly to the hardware through an API called WinRT, and for coders who have thousands of lines written for Win32, the journey is far from smooth.

Removing “Windows.h”

The first thing you will notice after creating a blank Visual Studio C++ project for WinRT is that there is no place for “Windows.h” and will actually fail to compile if you try to include it.  Instead you need to pick out the individual C runtime’s you are actually using, and there can be quite a few if your legacy Win32 code base is large. Hours into my conversion, my own header code looked like this:

/// #include “windows.h”
#include “memory.h” // memset
#include “string.h” // strcpy
#include “wtypesbase.h” // DWORD

The list goes on but you get the idea. When you compile under WinRT, your legacy code will have a lot of complains without “Windows.h”.

My first attempt to compile my engine in WinRT

Removing Old APIs

Once you’ve dealt with the basic house-keeping code, you’ll start to stray into more exotic API usage, such as HttpConnect, Threads, Locks, Sound, File and so forth. None of these exist untouched in the new WinRT universe, and new APIs replace each one. With patience, you will be able to find like for like replacement functions for all of them with simple searches on Google. If you are porting your code over however, I highly recommend you use #IFDEF WINRT #ENDIF or platform specific files when you replace legacy code to retain your ability to build standard Win32 applications.

During my engine conversion, I decided to skip porting the ancillary features such as network, sound, sockets and files and jump straight in at the deep end with the OpenGL library.

Amongst the errors, OpenGL code was much highlighted

DirectX and OpenGL are different enough to prevent a like for like conversion, and any developer with sufficient time would have coded an abstraction layer to hide the platform specific differences. My engine code has no such abstraction, just a bunch of files littered with OpenGL calls.

Step one was to re-create the OpenGL header file and create dummy functions for every call. Each function would in turn output that call to a log file so I knew which parts of the library I needed to wrap.

The final step was to empty the engine’s core functions of legacy code by commenting them out, and continuing to do so until the engine compiled successfully.

An Empty WinRT Engine

I used the DirectX 3D application as my template for the new project and left the 3D commands in place for a working reference. I then merged the refactored engine code with the template, and ran as a new Windows 8 app.

Split screen allows two apps to run side by side

Windows 8 has a cool mode which allows me to split the view 75/25 so that I can see the application window running whilst stepping through code. Formerly this would have been a case of using a remote computer, or messing with floating windows, so this was a welcome improvement for developers.  It also gave rise to an important observation that the end users of the Love Hearts® app would also potentially split the view and so this would be an important test case towards the end of the project.

Replacing the template artwork is a breeze

I replaced the stock graphics in the template with my own artwork. There are four assets you can replace and the process is very simple. In the past you had to deal with CUR, ICO and BMP files to form the graphical elements of your executable. With Windows 8 apps, they’re all alpha friendly PNGs with fixed sizes so you just need to hand them over to your artist and get back to coding.

Adding WinRT Meat

It’s no small achievement to have your engine compile and run, but I refused to get to the next blog without mastering the issue of running my potpourri of OpenGL code through DirectX. Getting my engine to render a blank screen without tampering with the original OpenGL code was my next mission.

Deciding to have a little fun, I installed some software on the Ultrabook which would grab a screenshot every 30 seconds whilst I coded the next part. It may give you an interesting perspective on what a typical 12 hour stint looks like when a programmer under the microscope marches into unknown territory.

Along the way I picked up a few tips which might save future explorers into the world of Metro style development a few hours of their lives.

Inside Tip 1: Building WinRT Static Libraries

When building static libraries (LIB) for Metro style apps you need to make a few changes before Visual Studio will let you build the final lib file. Ensure that option /ZW is enabled for your project, but ‘disabled’ for specific files that are ‘C’ only. This option controls whether the compiler handles the new C++/CX extensions such as the new ^ hat operator. You also need to add the following string to your C/C++ command options “/FU Platform.winmd /FU Windows.winmd /AI "C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\vcpackages" /AI "$(WindowsSDK_MetadataPath)"”, and the following to your Librarian command options “/force:allowzwobj”.

Until the final release of VS 2012, you need to hack

Fail to do the above and you will notice your namespace code will not be recognised and the line Windows::UI::Core would highlight the UI element as not known to the compiler.

Insider Tip 2: No run-time shaders

The CSO file is a compressed byte code of the HLSL shader

Metro style apps do support run time compilation of shaders for development but not for deployment, which means if you want your app to consume different shaders at run-time, you can’t.  All shaders need to be pre-compiled and included with your app package which presents something of a problem if your legacy code relies on compiling on the fly.

Insider Tip 3: Don’t put WinRT code in Static Libs

After about four hours of Google research, and putting code all over the place I have come to the conclusion that I will not profit from using a Static Library to place all my WinRT code. Asynchronous operations, which represent every API call in WinRT over 50 milliseconds long, do not perform the same outside of the main application. 

Notice the new syntax .THEN() - parallel here we come!

In fact, they crash in a number of random and completely unfathomable ways. Trying to find posts from fellow coders who have managed to get WinRT code running asynchronously in a static library is amazingly difficult. I am sure it is possible, somehow, but it will take a fresh pair of eyes to solve this one.

A Simpler Approach and Success

After 12 hours it became clear I was not going to win the battle of the static library, and I would have to compile the ‘module’ code directly with the app. This means I cannot distribute a convenient platform LIB for fellow AGK users right away, but it does mean debugging becomes slightly easier.

Just two hours after making this decision I had my first DirectX based OpenGL function. In the code below, I am using a modified version of the VS template CubeRenderer class to contain all my abstracted OpenGL call(s):

void DXRenderer::glClear (GLbitfield mask)
          if ( mask & GL_COLOR_BUFFER_BIT )
                             tempcolor      );
          if ( mask & GL_DEPTH_BUFFER_BIT )
                             0      );

An hour after that I quickly tied the Ultrabook accelerometer to the renderer. After many hours of gorping at crash dialogs, I wanted to treat myself to a little light relief:

void DXRenderer::ReadingChanged(Accelerometer^ sender, AccelerometerReadingChangedEventArgs^ e)
    AccelerometerReading^ reading = e->Reading;

As you might see, the app will now change the colour of the rendered screen when I tilt the Ultrabook right and backwards.

With a single OpenGL command now running under WinRT, the rest should follow quickly. It is fortunate that our Win32 engine is based on shaders, essentially because both DirectX and OpenGL go through pretty much the same process to set-up and then render polygons to the screen. The exciting part about this conversion is that I don’t have to re-factor the original C++ engine code, or create a graphics abstraction layer and carefully align the behaviour with what AGK is doing right now. When I have finished, the WinRT app will be graphically identical to the native OpenGL version, with the small difference that it’s actually DirectX 11.

Making Your Ultrabook Go Ping

One of the features I hinted at last week was the Always On Notification component which could bleep the user’s closed Ultrabook and present them with the app when they open it up. I have no clue what API it belonged to or where to start looking. As an antidote to spending too much time on DirectX, I switched tracks to do some research into this key area.

During my development, I have found the WinRT API reference site hosted by Microsoft to be of great help. The portal ( gives you an overview of EVERY feature category, and was the starting point of my search. It did not take long to find it, and drill into the page to learn all about it:

Further digging revealed a great article ( which explains the process in detail, and provides a good starting point for adding this exciting feature. One thing that needs more research is whether the Smart Connect technology is entirely low-level with no API to call? I’m also finding very little information about the ability to get the device to ‘ping’, ‘bleep’ or ‘scream’ during the device’s momentary dip into consciousness. I do wonder whether I actually dreamed this feature up during one of my fevered imaginings. If there is a way though, I’ll find it!

What I suspected was a speaker (or exhaust port)

The good news is that push notifications are definitely supported in the Metro style, and the code within the client is actually quite simple. The tricky icky part is setting up the cloud service to manage the notifications, and connecting with the Windows Store server to authenticate everything and bring the Ultrabook Start Page to life.

One Final Feature

Not content with writing OpenGL in DirectX, or getting the Ultrabook to sound a claxon while sleeping, I also wanted to tap into the raw processing power hiding amongst the silicon. The 3D graphics used by my app will push the GPU but we needed something to push the multi-core processor too.

The majority of the app logic is pretty sequential and would not benefit from a touch of parallel code, but the built-in games are another story. To this end, we have modified Box2D to run on multiple cores so any time AGK has to process a lot of 2D physics, it will split the solver across all available processors.

AGK Box2D Physics commands - simplicity itself!

This task only took a few days, and the performance benefit on the multi-core Ultrabook was immediate. We have created a small video showing the technology demo we used to test the performance of the optimisation:

When the time comes, I will be able to drop the latest n-core Box2D code directly into our WinRT engine without further modification, thanks largely to the fact that we're writing it in C.

Incidentally, another benefit of writing for WinRT is that the API is largely asynchronous, which means the app does not wait for sections of slow code such as loading, processing and buffer allocation. It will run those sections in parallel and dive straight into the main loop as quickly as possible. This is partly due to the new C++\CX technology which gently prods you to use a parallel paradigm, and in some cases preventing programmers from choosing a synchronous alternative.

The Future

Steve is back this week, which means the next blog will have lots of cool new app content to share. I would have liked to show you the new artwork Peter has produced, but as usual, he’s hoarding the files. I’ll probably get an email this week with a salvo of two hundred new files to climb through. Fortunately, Steve is adept at climbing mountains of art.

With the engine (one command of it) now rendering under DirectX, the rest of the functions should quickly follow. Rather than completely convert the engine, I can select those parts needed by the Love Hearts® app to save some time. Time I can use to add new touch, sensor and notification commands to the app and start testing what I hope becomes the ultimate Ultrabook app. Join me next time when you will see the app actually running under WinRT and tapping into the technology we've developed so far.

More Information

For more information about the Ultimate Challenge, check out the official website at:

Blog Timelapse

For everyone who likes time lapses, I have prepared a small video showing the entire 14 hour coding session which starts with an OpenGL engine and finishes with a "1 command" DirectX engine. 

Sunday, 19 August 2012

Intel Ultimate Coder Challenge - Part Two

The Story So Far

For the benefit of those joining us, you are reading the second instalment of a six part blog which tracks the antics of a developer hoping to win a $10,000 prize by creating a Windows 8 Metro app from scratch to take full advantage of a technology-packed Ultrabook. Last time I introduced myself and the technology I would be using, leaving details about the app itself cloaked in mystery.

So What Exactly Is The App?

The Love Hearts® app makes it possible to quickly create media messages on your Ultrabook and send them to your friends on Facebook, Twitter, Email and App-To-App.

A Love Hearts Sweet
The message can be tailored to include text, camera, photo album images and even your own doodles using the built-in art tool. The app then builds the message as a single image and sends it to your friend. If you send it to a friend who has the Ultrabook app installed, their device will notify them that they have a message and will present that message when they open their Ultrabook.

The App-to-App is an opportunity to experiment with a special feature of the Ultrabook called Always On Notifications. The idea is that when you close your Ultrabook, the app runs in low-power mode, and if someone sends you a new Love Hearts message, the Ultrabook will 'ping' you, even when closed. You can then open it up, and see the message running in the app.

Send messages any way you like

In addition, the app has a collection of daily surprises. For each day you own this free app, you are awarded a ‘surprise sweet’ which when tapped will open up to reveal what it contains. If you don’t like the wrapping, you can swipe it away and look at another one. When you see the one you like, you simply tap to unwrap.

Some of the actual Love Hearts(r) sweets

The surprise can be any number of things, from simple games, to pieces of puzzle that you can later assemble, or additional gadgets and tools to improve the messages you can send. Messages sent direct to another Ultrabook will additionally include music, sound and animation effects, all to make that message that little bit more special.  And to show you really care, you can include a sweet you have already unlocked in your message, which might be a game you quite like, or a vital piece of your friends puzzle.

So how does it make money?

No app is complete without a monetisation strategy, and no developer is complete without a freezer full of pizzas.

If you don’t wish to wait and prefer to unlock more than one sweet per day, you can buy ‘Love Credit’ top-ups, allowing you to unlock as many sweets as you like. I am toying with the idea that the daily credit is cumulative to encourage repeat usage. How to make your app pay is a little bit like alchemy, knowledge only takes you so far.

So What Will Make It an Ultrabook App?

It’s a great question and one that I will be wrestling with for the next few weeks. From using the Ultrabook over the last few days, I have gained a sense of what it does well and how it wants to deliver an app experience. Selecting tiles gracefully unfolds the app for you. Switching between Desktop and the Start page is slick and untroubled. I’m not left waiting for anything, and after an hour of playing I knew where everything was.

The new Windows 8 start screen

My gut feel is that the app should be an extension of this experience. I should be able to operate the app entirely from the touch screen, swiping and touching my way through every feature. If my keyboard fell off tomorrow, my app should carry on regardless. In practise, the full range of the accelerometer can only be enjoyed by putting the Ultrabook on my lap, but I have noticed the Z axis works great when I lift the keyboard up from the front, something I would never have thought without playing with the device itself.  As I continue using the Ultrabook, I am sure more insights will emerge, and I am keen to see how pre-installed apps are making use of other sensors like gyroscope and ambience.

And What Does It Do Right Now?

In anticipation of this question, I asked our tomb raiding, whip cracking coder Steve to knock up a version that I could demonstrate. Please excuse everything you see right now, and try to see past the app to a much better app buried deep within.

To protect ourselves from law suits, and to avoid strange looks in cafĂ©’s, we've decided to remove the requirement to pick-up and shake your Ultrabook. Instead, we’ve added a much nicer swipe gesture. In 3D, this will completely spin the packet in the direction and speed of your gesture so you get a real tactile experience right from the get-go. Your reward is a lovely wrapped sweet. The first one is by way of a tutorial and you are asked to ‘tap to unwrap it’. This will open the sweet and it gets added to your collection which is displayed at the top of the screen.

Sweets you own appear at the top

The tutorial continues into this freshly unlocked feature; a tool for designing and sending custom messages.

Have fun creating a custom message

As you can see, you can make some crazy media messages very quickly and with a single touch, the app sends it to your friend. A friends list will be added in a week or so.

Back in the main screen, you are free of the initial tutorial and you can use the app as normal. Swiping the packet will again spin the 3D model and a new sweet will fall out and float to the foreground. The sweet is supposed to be wrapped so you don’t see what’s inside. If you don’t like the shape, colour or style of the wrapping, you can swipe to fling the sweet away and it will curl its way back into the packet, and the packet will obligingly push out another sweet.  It just so happens in this demo the next ‘wrapped’ sweet looks fine so I tap to open and it gets added to my collection. I now have access to this sweet any time I like, and tapping this one reveals a game menu, with the game I discovered highlighted as available. In this demo, I can also play a bare bones version of this side scrolling game of skill.

An early screen shot of the game 'Wings Of Love'

Returning to the main screen, I can continue to swipe and spin the packet, and each time I do I am spending those most precious Love Credits. When I run out, I cannot have any more spins. The good news is that everything I unlocked I keep, so whether it’s playing the game again for a better score or sending an amusing message to a loved one, the app will be there for you. Better than that, each day you visit you get a free spin and a surprise to brighten up your day. For a complete list of surprises we have in store for you, you’ll have to play the app to find out!

Starting With Windows 8

Hopefully no-one has trademarked the word WINRT by the time this blog goes out, and I can explain what it is and how to use it before someone changes the name.  Before I can present my app in all its glory, I first need to get to grips with the new programming paradigm of Windows 8. That is, try to get “Hello World” running on my Ultrabook.

Windows 8 boot time is very quick

Writing an app from scratch using the templates provided by Visual Studio Express 2012 is simply a matter of studying how they work, and tweaking enough bits until you’ve got your own program. Trying to port a years’ worth of Win32 C++ engine code and squeezing it into the template is going to be trickier.  Step one is selecting the right template to start from.

New Project:Visual C++:Windows Metro style:Direct3D App

I recommend starting with the Direct3DApp project, NOT the Blank App (XAML). Chose XAML, and by the time you’ve got through the layers of helpful abstraction, it will be time for you to retire! I am an old school coder which means I need a main(), a loop() and an exit(), preferably in the same function!

Direct3D Application Template from VS Express 2012

You can compile and run this 3D demo and see a lovely spinning 3D cube, but the good stuff is the framework in which all that confusing 3D code sits. Look at the bottom of the “Direct3DApp1.cpp”, and you will find main().  Place a breakpoint there, run the demo and step into the functions and you will find yourself a few lines up in the Run() function which creates a timer and establishes a main loop, where it will sit happily until the window is closed. Pop in some clean-up code after the loop and presto, you have the makings of a no-frills, super-fast Windows 8 application.

It is this stripped down template that I will be using as the basis of my Ultrabook application. I have added it to a newly created FTP Area we can use to share files and demos in the coming weeks:

USERNAME: ultimatecoder
PASSWORD: ultimatecoder


Veteran coders who report to a higher power may wonder why I have just thrown away all the bits that actually do something and produced an app that does absolutely nothing. The more observant will go one step further and ask, “where does it say Hello World?”.

Essentially, I need to start from scratch to make room for my own C++ engine code. In theory, I should be able to drop it in, add some dependencies, click compile and go for an early lunch.

Researching Win32 vs. Metro Style

Before I commit to what in reality is a few days of work, I need to make certain of some basic requirements. Can I use standard C includes such as <stdio.h>, <malloc.h>.  Secondly, can I use <gl\gl.h> to access my precious OpenGL calls?  Already, I can feel the hairs on the back of my neck bristle. Is it me, or is that the sound of a thousand DirectX programmers laughing at me, surely not?

Two hours later, I arrived at the conclusion everyone reading this blog made right away and confirmed by a thousand DirectX programmers. A metro-style app is unable to include the OpenGL headers, and they are strictly for Desktop apps only. I can’t even ‘trick’ a Metro style app to render an OpenGL context. Even hacked, the metro style app would not be a valid app within the Metro style store as it would break the second it hit a device that did not have those legacy Desktop APIs. So that’s it friends, its metro style with no AGK graphics or desktop style with no access to WinRT. At least that’s what I thought. During my research hope was restored by an article published recently by Intel which goes into great length on how to access WinRT sensors from a Windows 8 Desktop app. When you have a few hours to spare, check out the article:

The limited WinRT desktop solution has enough COM code to put hairs on your chest, but it gets the job done and it will integrate instantly into my existing Win32 engine. I don’t even need to use VS2012 or learn what those ‘ref’ and ‘^’ symbols do, I can have sensors plugged in within the day.

Developer Dilemma

A question occurs. Is that the kind of thing the Ultimate Coder would do? Pick the easiest solution, slap in some cut and paste COM code then go for a little lie down somewhere. Fob off the judges with a desktop mode application that isn’t a real metro style app? I don’t think so.

The universe has put me in this challenge, and has just turned the heat up to see if I explode. I’ve looked at it from every angle, and there is only one way through. Write my own OpenGL library in DirectX 11.

Maybe not all of it, but enough bits that my AGK OpenGL routines compile normally, behave exactly as they would running under OpenGL but driven by DirectX.  As luck would have it, a few months ago we started updating our fixed function OpenGL ES 1.1 code to use OpenGL ES 2.0 shaders in anticipation of adding 3D commands to AGK. It further transpires that DirectX 11 likes shaders too. It transpires yet further that a few years ago I created a product called FPS Creator X10. Its claim to fame was a tech demo, one of the first third party demos to exploit the DirectX 10 graphics API.

From further research, it gets worse! Not only do metro style apps limit developers to DirectX, they also remove certain other liberties such as relative paths, unlimited system access and a blanket eviction of anything that might remind it of Win32. AGK is a full programming language, which means I’ll have to replace file, input and device code. The only things I think I can keep are physics, core logic and higher level graphics commands.

Don’t think me crazy though; there is method behind the mission to cure metro style apps of their clear lack of Win32 and OpenGL. Once complete, AGK programs will be able to run as genuine metro style apps, which means they will run on Windows tablets, and possibly Windows phones and consoles in the future.

I invite you to check back next week to see whether (a) I have achieved a small measure of success or (b) gone completely loco.

The AGK Advantage

You might be wondering how I can be demonstrating a running Love Hearts® app and at the same time agonise over how to render even one pixel to the Ultrabook. The good news for me is that AGK, the programming language we are using to run the BASIC script, already runs fine on Windows and several other platforms.  This means Steve, my back-up coder, can busy himself developing on Windows 7 while I set about making AGK work well with Windows 8. The magic happens in the next few weeks when I take the BASIC script that Steve has produced and drop it onto the new Ultrabook platform.

In addition, AGK has touch and sensor commands for many other platforms, so Steve will be able to add multi-touch and accelerometer functionality in his BASIC program long before I figure out how to do it on the Ultrabook.

What’s Next?

Are you kidding! Next week we will find out whether I can pull off even half of what I’ve just blogged. Steve is taking a short holiday, and I’ll be taking the opportunity to change all his code around and start the process of commissioning the artwork, so we might have some nice graphics to show. The real reveal will be a demo showing OpenGL calls that render to a metro style app context using DirectX as the underlying API. I’ve done some Googling, and there is not much on the subject, so it should be a good read!

More Information

For more information about the Ultimate Challenge, check out the official website at:

Blog Videos

For everyone who likes videos, I have created two. One features the latest version of the Love Hearts® app, and a second takes a quick peek at my shiny new Ultrabook.  Until next time, have an app-y day!

Monday, 13 August 2012

Intel Ultimate Coder Challenge - Part One

When Intel asked me to write an app, in just six weeks, with a mission to tap into every facet of a next generation pre-production Ultrabook, I started to giggle.

The Guy

My name is Lee Bamber, an over-worked, under-appreciated developer from a British company called The Game Creators. I’ve been a programmer for almost 30 years and still get the giggles when someone gives me a crazy coding mission.

Your intrepid guide on this journey of digital discovery

The App

With discretion over the design of the app, I decided to pick an idea from the ideas pile that would really show off what an Ultrabook could do. Coming from an engineering background, I plumbed for features, and lots of them. So I made a list of what I suspected the new Ultrabook could do; Multi-touch screen, instant notifications, 3D graphics, multi-core performance boost and sensors.

The app itself is called Love Hearts ®, and is an ambitious attempt to combine social messaging and gaming into a single fun and surprising experience. The initial idea came from those crazy 8-balls you shake, resulting in some random fortune cookie style advice to your most pressing questions. What if you could shake your device and a game would pop up or a piece of a puzzle, or a tool to create new things with. Naturally the idea was not fully formed, and asking users to pick up and shake their Ultrabooks would not win me any favours. Even so, the initial idea grew into an app design that would encourage creativity, sharing and fun, whilst at the same time tapping into the unique features of the Ultrabook.

The Love Hearts ® brand has been officially licensed from the UK confectionery company (Swizzels Matlow ) that makes these popular sweets here in the UK. By using a recognised brand we increase our chances of creating a popular app that will be recognised by millions of customers who have experienced this fun and well known candy.

The Technology

These days, you can’t throw a stone without hitting a solution for developing apps. From drag and drop wizards to notepad and compilers, there was no shortage of ways to develop such an app within the time allowed. As luck would have it, in a former life, I used to create programming languages for a living and it just so happens, the last one created, App Game Kit (AGK) , meets my needs just fine.

AGK – App Game Kit – Create cross platform applications in easy to use BASIC

Capable of producing apps on seven different platforms, and written entirely from scratch, I would be able to tailor and add commands for the Windows platform as and when I need them.

The Unboxing

Everybody likes a good unboxing, but due to the fact I live out on the frontiers of Wales, I suspected the courier had delivered my device to a long lost tribe of druids. Nonetheless, a large and ominous box arrived on Wednesday 8th August, and inside, the object of my challenge; a drop dead gorgeous next generation Ultrabook.

The Ultrabook - A universe crammed full of new and exciting technology

The App Development

With the why, who, what and when out of the way, I will dedicate the rest of the blogging to the best bit, the how.  How do you start such a project, how do you support new features or how do you stay sane and still get it finished in six weeks?

It was clear from the size of the app design and the tight deadline that I needed to assemble a small team to help out. I recruited a few fellow developers to help with the heavy lifting, including an extra pair of coding hands who for the purpose of our story we shall call Steve, a 2D artist - Peter and a 3D artist - Mark.

When not exploring lost civilizations, Steve explores his code for long forgotten bugs

Many apps consist of the same basic ingredients and these can be sourced and prepared ahead of time. One such ingredient is the functional prototype, which defines the basic shape of the app, and highlights very quickly where the majority of the development work will focus.

An early draft of the app in a native Ultrabook landscape format

The above prototype is two days old and shows a basic panoramic backdrop, and then a number of functional foreground elements. As you can see from the proportions, we are designing the layout to be form-factor friendly so the same app can run on a small screen as well as the ample screen proportions of the Ultrabook. It also makes for a great touch experience!

Anticipating future devices by building portrait awareness from day three

Using AGK, we are able to instantly broadcast the app directly to an iPad and Android phone to test screen layout constraints, give the button sizes a quick tweak, and then carry on developing on a larger screen. This saves us huge amounts of porting pain later when more of the app is coded.

The 2D sweet packet in the foreground will eventually be replaced with a 3D model so we can have more fun with rotation, position and shake effects, but we needed a nice looking place holder to give us a sense of the finished graphical style.

I'll reveal more about what the app actually does in the next blog, when I can show you rather than tell you.

Aside from the prototype app and the new 3D commands, we are also developing a set of social commands to allow the app to connect with Facebook, Twitter, Email and direct App-to-App communication via a custom server script and database. We have those commands working great on iOS already, and during these blogs we will be converting them to the Windows platform.

The Technology Development

In an ideal world, we should have access to every kind of feature through a few simple commands, but we don’t live there. We have to dig around websites, API documentation and snatch fragments of conversation from frustrated programmers in the hopes of finding a clue on how to solve the next puzzle.

My first puzzle is how to read the Accelerometer, Ambient Light Sensor and Geographic Location from my Ultrabook under Windows. After some Googling, I found a link that seemed to fit the requirements on MSDN. After some extensive reading, I finally narrowed down the actual code which would poll a sensor in Windows:

Although I am comfortable programming with COM interfaces, that does not mean I have to like it and I can guarantee a lot of fellow programmers would prefer to avoid it altogether. In AGK, the entire code above would be reduced to something like:

If GetAmbientLightExists()=1 then Print(GetAmbientLightValue())

Theory is all well and good, but nothing beats running real code on real hardware. I wanted to see actual readings from one of the Ultrabook sensors so I turned my attention to the device itself.

The World of Metro

In order to give my new Ultrabook a real hammer test, I decided to park my monster desktop PC and install all the development tools I would need directly onto the Ultrabook.  I installed Visual Studio Express 2012, Windows SDK for Windows 8 and Chrome. I compiled and ran some sample code from the SDK to read and display Accelerometer values, which worked a charm. At once I noticed the C++ source code looked a little strange:

void Scenario1::ReadingChanged(Accelerometer^ sender, AccelerometerReadingChangedEventArgs^ e)
    auto ignored = Dispatcher->RunAsync(
        ref new DispatchedHandler(
            [this, e]()
                AccelerometerReading^ reading = e->Reading;
                ScenarioOutput_X->Text = reading->AccelerationX.ToString();
                ScenarioOutput_Y->Text = reading->AccelerationY.ToString();
                ScenarioOutput_Z->Text = reading->AccelerationZ.ToString();

Feeling outside of my comfort zone, I foolishly tried to copy what I had created to a Windows 7 machine only to find the executable did not run there. It would never run there, it was a Metro app. Further research lead me to the news that VS Express 2012 has ‘switched off’ the ability to produce regular ‘run anywhere’ executables until later in the year. Given my need to support legacy operating systems, I uninstalled Express 2012 and installed Express 2010. Many hours later it was apparent that installing VS2010 was a mistake, as there is no way on Titan I was going to be allowed to develop Windows 8 applications from the comfort of my Win32 world. Apparently Win32 has had its decade in the sun, and it’s now time for a new star. That star is WinRT and is the beating heart of all Metro apps.

With VS2012 installed for the second time, my hope is that I can combine the new WinRT calls with the existing Win32 based AGK. I don’t have a clue whether this is possible but it will be a lot of fun finding out! 

The Next Blog

Over the next few days, I’ll have some first impressions about coding on and for the new Ultrabook, with a specific focus on whether I can build WinRT code inside my Win32 project. I’ll also report on the evolving app prototype and any new features. The goal is to create an amazing Ultrabook experience, and using the device every day should provide some useful insights.

Until next time, have a great week and for my fellow challengers, the best of luck with your projects and I’ll see you at the finish line!  May all your apps go top ten!

More Information

For more information about the Ultimate Challenge, check out the official website at:

Blog Photos

For everyone who likes photos, I have selected a few from the hundreds I took during this weeks blog.