New to the input engine within the Focused Games Framework is the gesture recognition capabilities, housed in the GestureTracker class. The gesture recognition class currently supports a small subset of the gestures I plan on supporting, but all are useful none-the-less. The included gestures are press, two fingered press, swipe, two fingered swipe, zoom and pinch. To use the gesture recognition, instantiate a GestureTracker object, add it to the IGame.Modules list and then listen to its GestureTracked even. You will also need an instance of the InputManager class added to the list of modules.

The following is a small sample taken from one of my games that handles some simple menu swiping (a full sample is on the way).

If you do happen to use FGF, I would love to hear what you think! Drop me a line via the Contact form or leave a comment here.

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
26
27
28
29
30

private void OnGestureTracked(object sender, GestureArgs args)
{
    // If it wasn't a swipe, we don't care!
    if (args.Gesture != Gesture.Swipe) return;
 
    // Get the direction of the swipe to determine what way
    // the menus should move
    if (args.Direction.X < 0)
    {
        // If we are capped at the right side of the menus, return
        if (current == menus.Length - 1) return;
 
        // Transition the menus
        menus[current].Transition(Menu.MoveDir.OffToLeft);
 
        current++;
 
        menus[current].Transition(Menu.MoveDir.OnFromRight);
    }
    else
    {
        if (current == 0) return;
 
        menus[current].Transition(Menu.MoveDir.OffToRight);
 
        current--;
 
        menus[current].Transition(Menu.MoveDir.OnFromLeft);
    }
}

 Download FGF 0.1.2.0 Bin

Read the rest of this entry »

As you no doubt saw in the writing of the Application class, FGF implements its own version of the XNA Framework’s component classes. The first major reason for doing so is that the builtin component classes require you to pass in a (Framework) Game object through the constructor. While this dependency can be circumvented by implementing the interfaces directly and supplying a manual workaround, the attempt is exactly that: a workaround. The second major reason for my implementation is that by controlling the interfaces and base classes, I can easily support more advanced situations such as the separation between initialization and content loading/unloading. You will see more of this later on when I modify the classes to support asynchronous content loading.

For now, the focus is being put on building a robust base for developers to start working with my framework. Because the goal is to fix the XNA Framework’s implementation, we begin with a simplification of the IGameComponent, IUpdateable and IDrawable interfaces. We combine these three into a single, multi-purpose interface, IModule.

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

public interface IModule
{
    event EventHandler DrawOrderChanged;
    event EventHandler UpdateOrderChanged;
 
    void Initialize(IGame game);
 
    void Draw(GameTime gameTime);
    void Update(GameTime gameTime);
 
    int DrawOrder { get; }
    int UpdateOrder { get; }
 
    bool IsVisible { get; set; }
    bool IsEnabled { get; set; }
    bool IsInitialized { get; set; }
 
    IModule Parent { get; set; }
    ModuleCollection Modules { get; }
}

Read the rest of this entry »

After you’ve read about the Display Orientation features of FGF, a natural question to ask is “How do I draw and take input with a rotated display?” Fortunately FGF has some methods to help in this department that sit alongside the rotation methods and properties in the Application class.

Application.OrientedDisplaySize

If you need to draw something relative to the size of the screen, use the OrientedDisplaySize property of the Application class. This property differs from DisplaySize, which is used to change the actual size of the display, in that OrientatedDisplaySize reacts to the selected rotation of the display, set with the DisplayOrientation property.

1
2
3
4

DisplaySize = new Vector2(272, 480);
DisplayOrientation = DisplayOrientation.Rotated;
 
Console.WriteLine(OrientedDisplaySize.ToString());

Because the display is set to be rotated (landscape on the Zune HD), the above code will actually print out a display size of (480, 272) rather than the standard (272, 480) size.

Read the rest of this entry »

New in the Focused Games Framework is the support for rotating and resizing the display on the fly. The main reason for this functionality is for mobile platforms like the Zune HD that support games in a landscape mode as well as a portrait mode. Supporting either in your game is made easy with FGF-you just need to know the right properties. In the standard display mode, the Zune HD has a display resolution of 272 pixels by 480 pixels. In landscape mode those two measurements are switched: 480 pixels by 272 pixels. While it is important to know the standard resolution, mucking about with a render target and backbuffer size is no longer necessary.

The one hitch? Your game class needs to inherit from FocusedGames.Xna.Application instead of Microsoft’s Game class. The following code block sets a Zune HD game up for landscape rendering.

1
2
3
4
5
6
7
8
9
10
11

public class Game1 : Application
{
    public Game1()
    {
        // Set the display size and the rotation
        DisplaySize = new Vector2(272, 480);
        DisplayOrientation = DisplayOrientation.Rotated;
    }
 
    // ...
}

Note that to keep the device in portrait mode, you don’t need to change the value of DisplayOrientation but setting the DisplaySize property to the standard value is a good idea. Happy landscaping!

One of the major themes present in the design of FGF is abstraction of functionality from its implementation. The major reason for this is because one of the major goals of FGF is to provide functionality without forcing developers into a corner. The idea is if the base of the framework is modular and open, the rest of the framework will fall into place very easily. So I begin the implementation of FGF by fixingimproving the XNA Framework’s Game class with an abstraction of its functionality. The reason for which will become apparent when the component classes are improved at a later time.

The important question to ask here is what can a game do? We can run a game, and exit a game but also add and remove components and services. Thus the IGame interface is born (within the FocusedGames.Xna project):

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

using Microsoft.Xna.Framework;
 
namespace FocusedGames.Xna
{
    public interface IGame
    {
        void Run();
        void Exit();
 
        Vector2 ObjectToScreen(Vector2 objectVector);
        Vector2 ScreenToObject(Vector2 screenVector);
 
        GraphicsDeviceManager DeviceManager { get; }
 
        DisplayOrientation DisplayOrientation { get; set; }
        Vector2 DisplaySize { get; set; }
 
        bool IsLoaded { get; }
 
        float TargetFrameRate { get; set; }
 
        ModuleCollection Modules { get; }
    }
}

Read the rest of this entry »

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.