Archive for August, 2010

31
Aug
2010

Introducing XPF – A Layout Framework for XNA

by David Wynne

Update (2012-07-05): XPF to be open sourced

We’re very proud to announce the public beta of XPF – a layout framework for XNA on Windows & Windows Phone 7.  For too long performing 2D layouts in XNA has been an arduous task, the simplest of layouts often produces verbose and inelegant code.  If you’ve come from a WPF/Silverlight background, where fluid and logical layouts are second nature, the inability to combine XNA with WPF and/or Silverlight only compounds the frustration.  With XPF, Red Badger is addressing this problem.

Familiar Development Experience

XPF has been specifically designed to be familiar to WPF & Silverlight developers and comes with a collection of out of the box controls, that can be composed together to create flexible layouts in no time at all.  The beta launches with the following controls:

  • Border
  • Button
  • ContentControl
  • Grid
  • Image
  • ItemsControl
  • RootElement (similar to Window)
  • ScrollViewer
  • ScrollContentPresenter
  • StackPanel
  • TextBlock

XPF also supports Dependency Properties, Attached Properties, Animation (currently WP7 only) and Data Binding (one and two-way).

Pure XNA

XPF is designed to run in a pure XNA application, it doesn’t host XNA inside a WPF or Silverlight application.  All the controls have been written from the ground-up to work in XNA 4.0 and fit into XNA’s Update & Draw game loop.

Extensible

XPF has been designed to be modular and extensible in two key ways.  Firstly, creating custom controls to use alongside the controls you get out of the box is easy.  If you’ve ever created a custom control in WPF or Silverlight, using the 2 phase measure and arrange layout system, then XPF gives an almost identical experience.

Secondly, the integration point between XPF and your XNA application has been designed to be extremely flexible.  XPF doesn’t really know anything about XNA, it’s written entirely around agnostic interfaces – so whilst XPF comes with a renderer that you can use out the box, should you want to create your own, or integrate to an existing engine, you simply have to satisfy a few core interfaces.

Try It

As XPF reaches completion we’re looking for early adopters, testers and feedback.  Nightly builds of XPF for Windows and Windows Phone 7 are now available for you to try.  Download a build and read the Getting Started blog now!

We’d really love to hear what you have to say – leave a comment, shoot us an email or find us on twitter @redbadgerteam.

31
Aug
2010

XPF: Getting Started

by David Wynne

Updated 2010-08-09: Brought into line with changes in Build 10+
Updated 2010-09-28: Brought into line with changes in Build 24+

In XPF, the RootElement control is the main host for all your controls, it manages the renderer, user input and is the target for Update/Draw calls.  The RootElement should be thought of akin to the Window control in WPF.  Although it’s possible to create more than one RootElement in an XNA application, it’s more advisable to use one that has a viewport equal to the entire screen and layout our elements within it dynamically.  XPF won’t physically render anything in empty space, so there is no performance overhead to having a large RootElement.

Let’s say we want to build an awesome game and we need a few things dotted around the screen.  We want a player’s score displayed top left, a high score top right and the number of lives remaining bottom left as in the scamp below:

Getting Started

Your XNA instincts might be telling you to think about working out the explicit position for each of the 3 main elements.  In XPF you don’t need to, instead you can use the layout controls to create a logical layout without a vector in sight.

Renderer, Adapters & Primitives Service

Instantiating a RootElement, requires that we pass it an IRenderer.  XPF comes with an out of the box Renderer that implements the required IRenderer interface, which we’ll use.  Its constructor requires ISpriteBatch and IPrimitivesService.

In order to reduce dependencies on XNA and increase the testability of XPF, we don’t directly use any XNA classes, but rather use interfaces that describe the specific XNA functionality we require.  Unfortunately XNA doesn’t implement very many useful interfaces we can leverage, so how do we get an actual SpriteBatch that implements ISpriteBatch?  One answer is to use the the Adapter pattern which essentially wraps SpriteBatch in a new class that does implement ISpriteBatch and delegates the calls down to the real SpriteBatch.  Adapters allow you to bridge the gap between one architecture that isn’t interface driven and one that is.  Creating Adapters is a fairly tedious task, so thankfully XPF comes with a bunch out of the box for you to use.

In the case of SpriteBatchAdapter, it inherits from SpriteBatch directly and implements ISpriteBatch meaning it’s easy to create and behaves just as a normal SpriteBatch object would (because it is one!).

Next up is IPrimitivesService, the only thing it exposes is a single pixel texture that XPF can use to draw borders and backgrounds.  XPF also comes with a pre-baked IPrimitivesService implementation which we can use.

With our SpriteBatchAdapter and PrimitivesService in hand, we can instantiate our Renderer:

public class MyComponent : DrawableGameComponent
{
    private SpriteBatchAdapter spriteBatchAdapter;

    public MyComponent(Game game)
        : base(game)
    {
    }

    protected override void LoadContent()
    {
        this.spriteBatchAdapter = new SpriteBatchAdapter(new SpriteBatch(this.GraphicsDevice));
        var primitivesService = new PrimitivesService(this.GraphicsDevice);
        var renderer = new Renderer(this.spriteBatchAdapter, primitivesService);
    }
}

RootElement

We’re now ready to create our RootElement – when doing so you stipulate the viewport you want XPF to use i.e. what it should consider top left and how much width/height it has to layout it’s children.  In our case we’re going to give it the whole screen, so we can use the handy Viewport.ToRect() extension method in XPF:

protected override void LoadContent()
{
    this.spriteBatchAdapter = new SpriteBatchAdapter(new SpriteBatch(this.GraphicsDevice));
    var primitivesService = new PrimitivesService(this.GraphicsDevice);
    var renderer = new Renderer(this.spriteBatchAdapter, primitivesService);

    this.rootElement = new RootElement(this.GraphicsDevice.Viewport.ToRect(), renderer);
}

RootElement can only contain a single child via it’s Content property.  Typically we would use a layout control such as the Grid to host all our other controls.  Right now, let’s set the RootElement.Content property to a TextBlock so we can see something rendering.

TextBlock

Those familiar with WPF/Silverlight will be familiar with the TextBlock – you want to display text on the screen?  You want a TextBlock.  Creating a TextBlock requires the use of another adapter – the SpriteFontAdapter, which allows us to instantiate TextBlock with an ISpriteFont.

var spriteFont = this.Game.Content.Load<SpriteFont>("MySpriteFont");
var spriteFontAdapter = new SpriteFontAdapter(spriteFont);

var textBlock = new TextBlock(spriteFontAdapter)
    {
        Text = "Hello World",
        Background = new SolidColorBrush(Colors.Red) 
    };

this.rootElement.Content = textBlock;

You’ll notice that I’ve also set the Background of the TextBlock to Red, which a) shows you how easy it is to give something a background in XPF; and b) will let us see where it appears and the space it occupies a little more clearly.  If we were to run our game now, we wouldn’t see much (besides CornflowerBlue) – we need to instruct XPF to Update and Draw and then run our game:

public override void Update(GameTime gameTime)
{
    this.rootElement.Update();
    base.Update(gameTime);
}

public override void Draw(GameTime gameTime)
{
    this.rootElement.Draw();
    base.Draw(gameTime);
}

01 Hello World

Alignment

Pretty exciting – but why so much red?  All controls have horizontal and vertical alignment properties which default to stretch – these attempt to “stretch” the control to fill the area given to it by its parent – in this case, the RootElement and so the whole screen.  Stretch doesn’t mean that a control’s contents are physically stretched (as in transformed), but rather it tries to take up the maximum amount of space its parent has allocated it and then uses that to lay itself out.

If we don’t want our TextBlock to stretch itself, we just change the horizontal/vertical alignment properties to something other than stretch.

var textBlock = new TextBlock(spriteFontAdapter)
{
   Text = "Hello World",
   Background = new SolidColorBrush(Colors.Red),
   HorizontalAlignment = HorizontalAlignment.Left,
   VerticalAlignment = VerticalAlignment.Top
};

02 Hellow World

Text Wrapping, Margins & Padding

TextBlock can also handle dynamically wrapping text.  If we swap our “Hello World” text for some information about Red Badger we’ll unsurprisingly see it run off the screen.

03 Hellow World

But if we turn on text wrapping, add a 10px margin on all sides (and just to show off) add 10px padding on all sides as well, we get something much more pleasing to the eye:

var textBlock = new TextBlock(spriteFontAdapter)
{
    Text =
        "Red Badger is a product and service consultancy, specialising in bespoke software projects, developer tools and platforms on the Microsoft technology stack.", 
    Background = new SolidColorBrush(Colors.Red), 
    HorizontalAlignment = HorizontalAlignment.Left, 
    VerticalAlignment = VerticalAlignment.Top, 
    Wrapping = TextWrapping.Wrap, 
    Margin = new Thickness(10),
    Padding = new Thickness(10)
};  

04 Hello World

StackPanel

Whilst the TextBlock is pretty powerful, it doesn’t make an ideal candidate as the content for a RootElement, because it can only contain text and no other controls.  Rather we need something that supports multiple children; a panel.

The StackPanel is one of the simplest panels – it stacks its children, one after the other, in either a vertical or horizontal direction.  Because all controls ultimately inherit from UIElement, StackPanel has many of the same properties as TextBlock; it can have horizontal/vertical alignment, margins and backgrounds, but it also has a children property which allows us to add multiple controls.  Let’s change our RootElement to contain a StackPanel, set the panel’s background (so we can see the space it occupies) and and add 3 TextBlock controls to the StackPanel:

var stackPanel = new StackPanel
    {
        Background = new SolidColorBrush(Colors.Red),
        Children =
            {
                new TextBlock(spriteFontAdapter) { Text = "Item 1", Margin = new Thickness(10) },
                new TextBlock(spriteFontAdapter) { Text = "Item 2", Margin = new Thickness(10) },
                new TextBlock(spriteFontAdapter) { Text = "Item 3", Margin = new Thickness(10) }
            }
    };
this.rootElement.Content = stackPanel;

01 StackPanel

You’ll note that StackPanel has a default orientation of vertical, so the elements are laid out down the screen.  Notice too all the red (again) – as with the TextBlock, the StackPanel default alignment is stretch in both directions.

Let’s change the orientation of the StackPanel to horizontal, which should lay the child elements out across the screen (rather than down it).  We’ll also change the horizontal/vertical alignment to centre the StackPanel (instead of stretch it).

var stackPanel = new StackPanel
{
    Background = new SolidColorBrush(Colors.Red), 
    Children =
        {
            new TextBlock(spriteFontAdapter) { Text = "Item 1", Margin = new Thickness(10) }, 
            new TextBlock(spriteFontAdapter) { Text = "Item 2", Margin = new Thickness(10) }, 
            new TextBlock(spriteFontAdapter) { Text = "Item 3", Margin = new Thickness(10) }
        }, 
    Orientation = Orientation.Horizontal, 
    HorizontalAlignment = HorizontalAlignment.Center, 
    VerticalAlignment = VerticalAlignment.Center
};

02 StackPanel

Grid

The StackPanel got us a little closer to our awesome game scamp in that it could handle more than one child – but for the layout we require, the StackPanel isn’t going to cut it.  Instead we turn to one of the most powerful layout panels, the Grid.

When you create a Grid, you do so with row and column definitions that define its structure.  Let’s create a 2 by 2 Grid and tell RootElement to use it as the main layout container.

var grid = new Grid
    {
        RowDefinitions =
            {
                new RowDefinition(),
                new RowDefinition()
            },
        ColumnDefinitions =
            {
                new ColumnDefinition(),
                new ColumnDefinition()
            }
    };

this.rootElement.Content = grid;

Grid has no visual properties (besides background), so as it stands nothing will render.  We need to put content into the grid.  Grid inherits from the same base class as StackPanel, so it also has a children property which we can add content to.  Let’s do that and see what happens:

var topLeftTextBlock = new TextBlock(spriteFontAdapter) { Text = "Top Left", Margin = new Thickness(10) };
grid.Children.Add(topLeftTextBlock);

var topRightTextBlock = new TextBlock(spriteFontAdapter) { Text = "Top Right", Margin = new Thickness(10) };
grid.Children.Add(topRightTextBlock);

var bottomLeftTextBlock = new TextBlock(spriteFontAdapter) { Text = "Bottom Left", Margin = new Thickness(10) };
grid.Children.Add(bottomLeftTextBlock);

var bottomRightTextBlock = new TextBlock(spriteFontAdapter) { Text = "Bottom Right", Margin = new Thickness(10) };
grid.Children.Add(bottomRightTextBlock);

Grid 01

The astute amongst you will have noticed that we haven’t given the Grid anyway of knowing which row or column each of the child controls should be placed in, so at the moment they’re all being placed into the first cell, on top of each other.  Whilst this isn’t what we want, it does highlight one of the Grid’s special abilities; to stack content along the z-axis.

Attached Properties

So that the Grid can figure out which cell it should place each child into, we use attached properties – another WPF/Silverlight concept which is supported in XPF.  If you’ve never heard of attached properties before they’re fairly self describing; they’re a mechanism for “attaching” a property to an object that doesn’t physically have that property.  In this case it negates the need for every control to have row and column properties just in case they’re contained within a Grid.  Instead Grid owns the attached property and allows it to be attached to anything that’s valid content for a Grid.  Let’s re-write the previous code, but using attached properties to define their row/column placements:

var topLeftTextBlock = new TextBlock(spriteFontAdapter) { Text = "Top Left", Margin = new Thickness(10) };
Grid.SetRow(topLeftTextBlock, 0);
Grid.SetColumn(topLeftTextBlock, 0);
grid.Children.Add(topLeftTextBlock);

var topRightTextBlock = new TextBlock(spriteFontAdapter) { Text = "Top Right", Margin = new Thickness(10) };
Grid.SetRow(topRightTextBlock, 0);
Grid.SetColumn(topRightTextBlock, 1);
grid.Children.Add(topRightTextBlock);

var bottomLeftTextBlock = new TextBlock(spriteFontAdapter) { Text = "Bottom Left", Margin = new Thickness(10) };
Grid.SetRow(bottomLeftTextBlock, 1);
Grid.SetColumn(bottomLeftTextBlock, 0);
grid.Children.Add(bottomLeftTextBlock);

var bottomRightTextBlock = new TextBlock(spriteFontAdapter) { Text = "Bottom Right", Margin = new Thickness(10) };
Grid.SetRow(bottomRightTextBlock, 1);
Grid.SetColumn(bottomRightTextBlock, 1);
grid.Children.Add(bottomRightTextBlock);

Grid 02

Pretty snazzy right?  Next step is to get our Grid cells to expand to the entire screen, so the “Bottom Right” TextBlock, really is bottom right.  In order to do this, we need to return to the row/column definitions we created earlier.

Row and Column Definitions

When creating a RowDefinition you can optionally specify a height property.  Height can either be set to “auto”, which sizes the height of the row automatically to contain the cells’ contents.  “Pixel”, which allows for an explicit pixel height.  Or “star”, which allows for percentage style values.  The same is true for ColumnDefinition, but in relation to its width property.

At time of writing the XPF beta doesn’t support star heights/widths, which should be the default and allow for truly fluid layouts, but it will do shortly.  Right now the default is auto, which explains why the Grid cells are just big enough to contain their contents and are bunched up in the left hand corner.

For the time being then, we need to alter our row/column definitions to use explicit pixel values:

var grid = new Grid
{
    RowDefinitions =
        {
            new RowDefinition { Height = new GridLength(210) },
            new RowDefinition { Height = new GridLength(210) }
        },
    ColumnDefinitions =
        {
            new ColumnDefinition { Width = new GridLength(200) },
            new ColumnDefinition { Width = new GridLength(200) }
        }
};

Grid 03

Now to get things hugging the side of the screen, we just need to change the alignment properties of each TextBlock.  Because they’re contained within a Grid, the alignment properties only affect their alignment within their cell:

var topLeftTextBlock = new TextBlock(spriteFontAdapter)
    {
        Text = "Top Left",
        Margin = new Thickness(10)
    };
Grid.SetRow(topLeftTextBlock, 0);
Grid.SetColumn(topLeftTextBlock, 0);
grid.Children.Add(topLeftTextBlock);

var topRightTextBlock = new TextBlock(spriteFontAdapter)
    {
        Text = "Top Right",
        Margin = new Thickness(10),
        HorizontalAlignment = HorizontalAlignment.Right
    };
Grid.SetRow(topRightTextBlock, 0);
Grid.SetColumn(topRightTextBlock, 1);
grid.Children.Add(topRightTextBlock);

var bottomLeftTextBlock = new TextBlock(spriteFontAdapter)
    {
        Text = "Bottom Left",
        Margin = new Thickness(10),
        VerticalAlignment = VerticalAlignment.Bottom
    };
Grid.SetRow(bottomLeftTextBlock, 1);
Grid.SetColumn(bottomLeftTextBlock, 0);
grid.Children.Add(bottomLeftTextBlock);

var bottomRightTextBlock = new TextBlock(spriteFontAdapter)
    {
        Text = "Bottom Right",
        Margin = new Thickness(10),
        HorizontalAlignment = HorizontalAlignment.Right,
        VerticalAlignment = VerticalAlignment.Bottom
    };
Grid.SetRow(bottomRightTextBlock, 1);
Grid.SetColumn(bottomRightTextBlock, 1);
grid.Children.Add(bottomRightTextBlock);

Grid 04

Border

Next up we need to get some horizontal lines under the top two TextBlock controls and above the bottom two, we also want the bottom row to have a green background.  To do that let’s use the Border control.  Border has the same base class as RootElement and as such can only contain a single element.  It allows us to place borders on 1, 2, 3 or all 4 sides of the object it contains.  We’re going to create a Border control for each TextBlock, place the TextBlock within it and make each Border the immediate child of the Grid.  The top two borders will only specify a border on the bottom giving a horizontal line that will run across the whole screen.  The bottom two borders will only specify a border on the top giving the same effect and use our pea green colour for the background:

var topLeftBorder = new Border
    {
        BorderBrush = new SolidColorBrush(Colors.Black),
        BorderThickness = new Thickness(0, 0, 0, 2),
        Child = new TextBlock(spriteFontAdapter)
            {
                Text = "Top Left",
                Margin = new Thickness(10)
            }
    };
Grid.SetRow(topLeftBorder, 0);
Grid.SetColumn(topLeftBorder, 0);
grid.Children.Add(topLeftBorder);

var topRightBorder = new Border
{
    BorderBrush = new SolidColorBrush(Colors.Black),
    BorderThickness = new Thickness(0, 0, 0, 2),
    Child = new TextBlock(spriteFontAdapter)
    {
        Text = "Top Right",
        Margin = new Thickness(10),
        HorizontalAlignment = HorizontalAlignment.Right
    }
};
Grid.SetRow(topRightBorder, 0);
Grid.SetColumn(topRightBorder, 1);
grid.Children.Add(topRightBorder);

var bottomLeftBorder = new Border
{
    BorderBrush = new SolidColorBrush(Colors.Black),
    BorderThickness = new Thickness(0, 2, 0, 0),
    Background = new SolidColorBrush(new Color(106, 168, 79, 255)),
    Child = new TextBlock(spriteFontAdapter)
    {
        Text = "Bottom Left",
        Margin = new Thickness(10),
        VerticalAlignment = VerticalAlignment.Bottom
    }
};
Grid.SetRow(bottomLeftBorder, 1);
Grid.SetColumn(bottomLeftBorder, 0);
grid.Children.Add(bottomLeftBorder);

var bottomRightBorder = new Border
{
    BorderBrush = new SolidColorBrush(Colors.Black),
    BorderThickness = new Thickness(0, 2, 0, 0),
    Background = new SolidColorBrush(new Color(106, 168, 79, 255)),
    Child = new TextBlock(spriteFontAdapter)
    {
        Text = "Bottom Right",
        Margin = new Thickness(10),
        HorizontalAlignment = HorizontalAlignment.Right,
        VerticalAlignment = VerticalAlignment.Bottom
    }
};
Grid.SetRow(bottomRightBorder, 1);
Grid.SetColumn(bottomRightBorder, 1);
grid.Children.Add(bottomRightBorder);

Grid 05

So close.  Let’s add another row into the mix for the main content of our game, which will push the top and bottom rows apart giving us the layout we’re after.  We’ll make the [new] middle row large enough that we don’t need to specify heights on the top and bottom rows, they can revert to auto.  We’ll also change the Grid background to white and swap in the correct text:

var grid = new Grid
{
    Background = new SolidColorBrush(Colors.White),
    RowDefinitions =
        {
            new RowDefinition(),
            new RowDefinition { Height = new GridLength(320) },
            new RowDefinition()
        },
    ColumnDefinitions =
        {
            new ColumnDefinition { Width = new GridLength(200) },
            new ColumnDefinition { Width = new GridLength(200) }
        }
};

Grid 06

Finally our design has been achieved, and all without using a single vector!

As you can see, if you’re coming from a background of WPF or Silverlight you’ll find using XPF a breeze.  If on the other hand you’ve never touched either of those technologies, your learning curve maybe slightly steeper, but hopefully you’ll appreciate that XPF allows you to describe the layout you want to achieve using language and constructs that directly relate to the problem domain, creating more elegant and manageable code.

You can download the code for this solution here: Xpf.Samples.zip – but it won’t build until you’ve also downloaded the latest nightly build to go with it and updated the references.  (I know that’s a bit of a pain – more info in the readme).

In future posts in this series we’ll be discussing some of the more powerful features of XPF including the ScrollViewer, ItemsControl, user input, data binding, animation and some of the upcoming features still being developed.

28
Aug
2010

TeamCity, GitHub and SSH Keys

by David Wynne

If you’re a Windows based user of GitHub and using TortoiseGit then it’s highly likely you’ve used PuTTYGen to generate the SSH key you’re using with GitHub and why not – it works fine.  That is until you want to start using TeamCity with GitHub.

If you try to configure your VCS root in TeamCity using the bundled Git plug-in, with a private key generated with PuTTYGen, you’ll likely get the following error: Connection failed!  Repository ‘git@github.com:accountName/repoName.git’: Unable to load identity file: C:\whatever\YourPrivateKey.ppk (passphrase protected)

TeamCity Connection Failed

We spent a while messing around with the different authentication methods available in the TeamCity – trying to configure default .ssh keys for the logged on user, adding SSH config files and nothing worked.

Eventually we re-generated our SSH key using Git Bash, instead of PuTTYGen (as detailed here) and suddenly – Connection successful!

I’ve since discovered that you can get the same result using PuTTYGen, but you have to export your key as a OpenSSH key: Load your existing private key – File/Load private key (enter your passphrase).  Export to OpenSSH – Conversions/Export OpenSSH key.  Use the resulting key as the private key you give to TeamCity.

@dwynne

20
Aug
2010

Hosting XNA within Silverlight on Windows Phone 7 and why you shouldn’t do it

by David Wynne

When anyone starts working with XNA, it doesn’t take too long before they get fed up of dividing vectors by the viewport width and ask whether it’s possible to use the goodness of the WPF/Silverlight layout system to do their 2D stuff and the power of XNA to do the 3D stuff.  The answer is invariably “well, kinda… not really”.  Many have tried, some have had limited success and Microsoft have generally said “it’s something we want to do”.

With the imminent release of Windows Phone 7 the question has never been more relevant – a platform on which you can only develop in Silverlight or XNA.

By far the best implementation of rendering XNA within a WPF app we’ve seen, is that detailed in Nick Gravelyn’s blog post: Rendering with XNA Framework 4.0 inside of a WPF application.  We really liked the pure approach he’d taken and decided to try the same thing on WP7 with Silverlight.  With a few alterations (largely around getting hold of a handle with which to create a Graphics Device) we got it working.  Magic.

So why not do it?  Put simply, it will fail Market Place Ingestion.  If your Silverlight application uses anything from the Microsoft.Xna.Framework.Game or Microsoft.Xna.Framework.Graphics assemblies your app will automatically fail Ingestion.  (As a side note, if your XNA app uses anything from the System.Windows.Controls namespace, you’re also in for ingestion failure.)

So what now?  Back to dividing vectors?  Well here at Red Badger we’ve been busily working away on a new layout system for XNA called XPF.  Expect more announcements soon, but needless to say if you’re longing for some familiar controls like a Grid or a ScrollViewer in XNA – watch this space…

@dwynne

9
Aug
2010

Windows Phone 7 – Avoiding 30% U.S. tax withholding for Limited Companies

by Cain Ullah

Red Badger are currently working with Microsoft to develop a Showcase Windows Phone 7 application. As well as the joys of developing the application for this platform there are a number of far less exciting but necessary things that also need to be set up before your application can be placed on the marketplace. Some of these may include agreeing and signing a JMA (Joint Marketing Agreement) with Microsoft, registering at the Marketplace ($99 for a year – http://developer.windowsphone.com), providing the company VAT number and registering with the IRS.

This blog is a brief guide to registering with the IRS if you are a Limited Company as apposed to an individual developer.

First and foremost, you may ask why you need to do this. If you are intending on developing applications for Windows Phone 7 or for any other US company that is going to pay you money, especially interest, dividends or royalties, the US will first take 30% of that amount in tax withholding and pay it to the US Government, leaving you with 70% of the rest (Which will then also be taxed by your country before you get your share). However, the US Government has tax treaties with a number of different countries/regions (List of countries with tax treaties here: http://bit.ly/aklpyE) which can give you a discount on the 30% rate or an exemption altogether. You will then only have to pay your resident country’s tax on the full amount.

If, like Red Badger, you are a UK company you will get full exemption from paying any tax withholding. To gain this exemption you need to fill in two forms:

1) IRS Form SS-4 – http://www.irs.gov/pub/irs-pdf/fss4.pdf

2) IRS Form W-8BEN – http://www.irs.gov/pub/irs-pdf/fw8ben.pdf

Form SS-4 you will need to send to the IRS to gain an Employer Identification Number (EIN). Once you have the EIN you will then need to fill out the W-8BEN form and send it to the company that will be paying you (in Red Badger’s case the W-8BEN goes to Microsoft).

There are a number of different ways that you can send the SS-4 form to the IRS (See instructions here: http://www.irs.gov/pub/irs-pdf/iss4.pdf) but I found the telephone service very helpful. The member of staff that took me through the process asked me the appropriate questions, filled the data directly into the IRS system and provided me with an EIN number over the phone 15 minutes later. If you mail the form to the IRS it will take at least 4-5 weeks. The telephone number to call the IRS to get an EIN is: 1-269-941-1099.

Filling out the forms…

Red Badger is a Limited Company formed of 3 founding partners. We have not had an EIN before and do not require a 3rd party designee. We are also based in the UK and are VAT registered. Lastly we do not have any notional principle contracts. The advice below on filling out the forms is based on these aspects, so if your situation is different you may have to fill the form out differently as well.

The SS-4 form is made up of 18 sections of required information. Example of the SS-4 form here: SS-4 Form Example (Replace placeholders with your data). Sections 12-15 do not need to be filled in.

The W-8BEN form needs the following information:

1) Part 1 – Company details including EIN number in Part 1 Section 6.

2) Part 2 – Check 9a, b and c (fill in country of residence in 9a). In section 10 enter article 12, 0% and Royalties as the type of income. (Note that this is the type of income for Windows Phone 7 Developers in the Windows Phone Marketplace. If you are not developing for Windows Phone 7 these 3 entries may be different. For different income types see your Country’s specific Tax Treaty agreement: http://bit.ly/aklpyE)

Example of the W-8BEN form here W-8BEN Form Example (Replace placeholders with your data).

Hopefully this blog will help you out and prevent any headaches or pockets that are not quite as full as they should be due to IRS issues. Red Badger can now get on with the fun part developing a kick-ass app for the launch of Windows Phone 7 .