This series is devoted to the design and development of my framework, FGF (Focused Games Framework), and aims to cover topics like async content management, WCF services, and many more. In this first article, I cover how to setup Visual Studio 2008 for coding the framework. It is important to understand that I will be using Visual Studio Team System 2008 and thus may have features that are not available in the Express edition. It is possible to get around many of these or ignore them completely, however, so not having Team System does not mean developing FGF is impossible.

The first step is to open up the IDE and create our solution. When starting a large solution such as the one for FGF, I find it useful to create a Blank Solution so that the solution’s name can be different than that of the first project. Again, this can be worked around in Express as well as other versions of the editor.

Read the rest of this entry »

This tutorial covers a basic way of implementing two dimensional fog of war for a game in XNA and assumes you (the reader) has basic knowledge of C# and the XNA Framework. To get things started, create an empty Windows game project. Two textures will be needed: one for the Light and one for the Background. After adding these to the Content Project, go ahead and add the following members to the game class.

1
2
3
4
5
6
7

Texture2D lightTexture;
Texture2D backgroundTexture;
 
RenderTarget2D lightTarget;
RenderTarget2D mainTarget;
 
Effect basicFogOfWarEffect;

While the use of the texture fields is obvious, the use of the render targets may not. The concept behind this fog of war implementation is to draw the light texture to the lightTarget render target and then use the produced texture as the alpha channel for the texture produced from the mainTarget render target.

Read the rest of this entry »

Beware that when you call TouchPanel.GetState twice within the game loop, what touch locations had a Pressed state the first time will have a Moved state the second time. Consider the following lines of code.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

TouchCollection touches = TouchPanel.GetState();
 
foreach (TouchLocation locale in touches)
{
    if (locale.State == TouchLocationState.Released && locale.Id == id1)
        id1 = -1;
    else if (locale.State == TouchLocationState.Pressed && id1 == -1)
        id1 = locale.Id;
    else if (locale.Id == id1)
        pos1 = locale.Position;
}
 
touches = TouchPanel.GetState();
 
foreach (TouchLocation locale in touches)
{
    // Can fail if the first time through it was Pressed.
    if (locale.Id == id1 && locale.State == TouchLocationState.Pressed)
    {
        // Do something important
    }
}

Note that it isn’t important that these are in the same file let alone the same method. You cannot rely on having access to the same state data everytime you call GetState within the game’s loop. So it will probably become important to put the touch code in a global location and store the states for the duration of the loop. For instance you can store the TouchCollection data in a static variable at the top of the Game’s Update method.

One of the first “games” I made for the Zune HD was a simple little application to test how accurate and quick the touch panel is. This How To gives you the code to get started with your own basic testing application.

After creating a Zune game with XNA 3.1, the first thing you need to do is define a basic particle struct to hold some data that we track as the user touches the screen. Specifically we need to track whether or not a particle is active (do we update it and draw it?), its position and its life (how long it has been there). I created this structure within the Game1 class but really it can go anywhere.

Read the rest of this entry »

One of the requirements of the framework I am building (FGF) is cross platform support. For my XNA games this means support for not only Windows but also the Zune and the Xbox 360. For my Windows based projects I often find that X64 can be used (and in the case of IIS in 2008 R2, encouraged) so I also support X64 versions.

The problem is that when using an XNA project template to build a library for the simple fact that XNA projects can automatically synchronized (across platforms), Visual Studio blocks the creation of an X64 build target. Rather you are stuck with X86, Zune or Xbox 360.

The good news is that you can get around this! Open up the Windows project file (csproj) in a suitable text editor and copy the sections for both “Debug|x86″ and “Release|x86″ and paste them right after.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x86' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>..\Bin\x86\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE;WINDOWS</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <NoStdLib>true</NoStdLib>
  <UseVSHostingProcess>false</UseVSHostingProcess>
  <PlatformTarget>x86</PlatformTarget>
  <XnaCompressContent>false</XnaCompressContent>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x86' ">
  <DebugType>pdbonly</DebugType>
  <Optimize>true</Optimize>
  <OutputPath>..\Bin\x86\Release\</OutputPath>
  <DefineConstants>TRACE;WINDOWS</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <NoStdLib>true</NoStdLib>
  <UseVSHostingProcess>false</UseVSHostingProcess>
  <PlatformTarget>x86</PlatformTarget>
  <XnaCompressContent>true</XnaCompressContent>
</PropertyGroup>

Next you simply replace the instances of x86 with x64 and change anything else you need.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
  <DebugSymbols>true</DebugSymbols>
  <DebugType>full</DebugType>
  <Optimize>false</Optimize>
  <OutputPath>..\Bin\x64\Debug\</OutputPath>
  <DefineConstants>DEBUG;TRACE;WINDOWS</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <NoStdLib>true</NoStdLib>
  <UseVSHostingProcess>false</UseVSHostingProcess>
  <PlatformTarget>x64</PlatformTarget>
  <XnaCompressContent>false</XnaCompressContent>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
  <DebugType>pdbonly</DebugType>
  <Optimize>true</Optimize>
  <OutputPath>..\Bin\x64\Release\</OutputPath>
  <DefineConstants>TRACE;WINDOWS</DefineConstants>
  <ErrorReport>prompt</ErrorReport>
  <WarningLevel>4</WarningLevel>
  <NoStdLib>true</NoStdLib>
  <UseVSHostingProcess>false</UseVSHostingProcess>
  <PlatformTarget>x64</PlatformTarget>
  <XnaCompressContent>true</XnaCompressContent>
</PropertyGroup>

One warning – this should only be used for projects that don’t require references to the XNA framework. At this time Microsoft has no support for x64 XNA references.

Looks like we have a platformer contest starting up here… any other entrants? This is the start of a game by ElementCy which apparently go for more of a Conker feel than the fast paced style of Tears.

Check out Zedox’s new platformer, Tears, in this video. I have been wanting a good, fast platformer for many months now. Remember kiddies, Sonic is always better than Mario.

I have taken a quick look at the data gathered by my XBLCG Report Tool and have compiled some of the more basic stats. This is based on 17 reports, 3 of which have incomplete data.

Total Downloads: 100 890
Total Purchases: 9 366

Average Downloads: 5 935
Average Purchases: 551
Average Conversion Rate: 9.28%
Average Cost: 263 MS Points

Total Gross: $25 418.10
Total Net: $17 792.64

Average Gross: $1 495.18
Average Net: $1 046.63

Microsoft
Total Net: $7 625.42
Average Net: $448.55

Thanks to all the creators who submitted reports! As I get more data I will be able to produce better views including the all important price analysis we are all wanting to see.

With the upcoming release of FGF/Thrust comes the return of a more traditional GUI. One of the most problematic requirements of a large GUI system is the notion of focus. The question remains how do you efficiently determine who has focus and how do you pass focus between controls? On Windows this is incredibly easy because we have the mouse pointer. Focus is changed whenever your mouse acts on a control. What about on the Zune or the Xbox 360 though? On both of these systems their is no mouse (although Thrust supports a virtual mouse).

The answer is to look at what Thrust currently supports. What built in system supports all three systems seamlessly? (~ means some support, X means full support)

The problem is we can’t rely on each individual hardware controller being present and useable. For example we can’t rely on a keyboard being a focusing mechanism on the Xbox 360 because it isn’t a guarantee it exists. Likewise, we cannot rely on the GamePad on the Zune because of the lack of buttons.

To get to the point, the UniversalButton system was meant as a virtualization of the various hardware supported for each platform. It turns GamePad, Mouse, and Keyboard events into simple events like Up, Left, Down, Right, Select and Cancel. Because of this we can rely on it and implement a few more events.

• TabPreviousLocal
• TabNextLocal
• TabPreviousGlobal
• TabNextGlobal

You can consider local tabbing to be much like you would on a Windows form: hitting the tab key (or shift-tab) will move you from one control to another based on some order and only in the context of the global focus point (you never tab to a control in another window). The global tabbing can be considered like an Alt-Tab (or shift-alt-tab) where you can switch between windows.

So how do we implement this? We need a managing class (sorry Bjoern) to produce a bottleneck for the input events. As events are channeled through this class, it massages the data and figures out what to do. For instance if a global tab next event is received it has to switch focus to the next window in the system on the same level as the current window. If it receives a local tab event it will pass a message to the current focal point to tab to the next control.

What does this do for us? For one, it unifies the approach to focusing across all the UI subsystems. This means that a Window/Form implementation will focus in much the same way a simple screen will. Unfortunately it also means a complexity requirement for implementation developers. The age of the simple StateManager class is coming to an end. Elements on the screen now need to have a basic state for animation as well as a state for focus (or lack thereof). While it may still be possible to simply unload an element through the StateManager, the reality is that UI elements will have to do a little more management under the hood. Whether this is exposed to the user / developer is still to be decided.

Today, while coding Galactic Wars v2.0, I stumbled upon a problem I have been having with content since I started working with XNA. The following diagram shows how easy it is to create the problem and how devastating it can be to any application. In my case, I have two (or more) menus that are referencing a piece of content.

Each menu references the same managed object which is really a wrapper for a second managed object (Texture2D in this case). The second object is a managed wrapper for the underlying unmanaged data, again in this case it is texture data. The problem is when one menu is being phased out (unloaded) and another is being phased in (loaded). The menu being loaded grabs a reference to the content before the other menu can unload it. The ordering is done this way to ensure that a menu actually loads its content before the current menu is unloaded.

After the menu is done loading content, the second menu is unloaded which drops the content and releases the unmanaged memory. Aha! The problem stems from the last point: I am trying to manage unmanaged memory when I should just let the GC take care of it. The reason I do this is for performance reasons, primarily on the Zune. Instead of letting textures just sit around, I release them when they are no longer needed to avoid piling up the garbage.

So what is the solution?

1. Dereference the Managed Object
   

   I would love to do this but unfortunately it introduces a second problem. If every menu (object using the content) dereferences the asset, it still will not be collected by the GC. The AssetManager still holds a reference which is now being unused and thus memory is wasted. The upside to this is that I do not need to implement the second option…

2. Reference Counting!
   

   By implementing a counter on the asset itself and asking developers to always call Unload or Unload(ILoadable) on the AssetManager, I can guarantee that no Asset will be disposed while another object is using it. The downside is that it is an ugly implementation of something that is done in the GC anyways. The major upside is that even if developers use the previous method, the GC will still eventually catch the wasted memory.

So now Thrust’s AssetManager and IAsset require (and implement) reference counting to avoid the problem described above. And it works wonderfully.