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!

A design pattern made famous in the .NET community by Microsoft’s ASP.NET, the provider model explains is a pattern that supplies the end-developer with a plug-and-play architecture. The provider model is most often used when you have a consumer object that is dependent on specific functionality that can be supplied by one or more underlying systems. The major benefit of which is an increase in manageability and reusability.

Read the rest of this entry »

It disgruntles me when poor arguments are put forth. For instance, Silverlight should be avoided is an argument that relies on a very biased opinion rather than fact. The problem, of course, isn’t that the argument is being made against Silverlight but rather that the argued points are unfounded and poorly written. Below is a point-by-point analysis and counter-point piece based on what I know of Silverlight as well as what Bing can tell me.

Hyperlinks

The author chooses, of course with no evidence, to make the point that Silverlight doesn’t support deep linking. I agree that providing a uri for each page, document, video, et cetera, is an important part of what makes the web accessible. Anyone who has visited an all Flash site from the late 90′s knows why: without a Uri, users cannot gain quick and consistent access to content. It is fortunate that Silverlight provides deep linking support, otherwise I would have to agree with the author. A quick Bing or Google search could have provided the author with this information, but then again what are facts to an argument?

Read the rest of this entry »

Before I begin this post, big thanks to Eibx and David over at the Community Forums for helping me find these methods. I have modified the CheckTexture method a bit, but its purpose remains unchanged.

As of the last FGF article, the Application class was implementing the IGame interface but was missing the ability to create a render target object on the PC and Xbox 360. For PC games this can be a troubling problem since different hardware can obviously require different formats and dimensions of render target. Rather than bake this functionality into the Application class itself, it is moved to a static helper class so that all developers can make good use of its functionality at any point in time.

To start off, a simple default creation method is included to give the basic functionality an easy access point.

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

using System;
 
using Microsoft.Xna.Framework;
using Microsoft.Xna.Framework.Graphics;
 
namespace FocusedGames.Xna.Graphics
{
    public static class GraphicsHelper
    {
        public static RenderTarget2D CreateRenderTarget(GraphicsDevice device)
        {
            return CreateRenderTarget(
                device, 
                device.PresentationParameters.BackBufferWidth, 
                device.PresentationParameters.BackBufferHeight, 
                1, 
                device.PresentationParameters.BackBufferFormat
            );
        }

Read the rest of this entry »

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.

Rather than writing an actual letter, which would do no good, I have chosen to write this post with the idea that as an MVP I should lead and teach by example. One of the most important design principles that factor into designing a framework is that of dependency hierarchies. In less fancy terms it simply means what classes implement what interfaces and where these things are maintained in the framework. Recently I placed a suggestion on Connect to Move INotifyCollectionChanged to System.dll so that more projects that do not require WindowsBase.dll (WPF) could use the functionality. Fortunately for .NET developers everywhere the suggestion was taken (although I won’t claim sole responsibility) and the move is happening.

This post is about the reasons for such a move, and such reasons are incredibly basic to realize. Consider a platform other than Windows whether it be Linux, Windows Mobile, the Xbox 360 or even the Zune HD. Now think about how you would write a framework that supports some of (or all) these platforms and consider the problem of developing a class that implements something like INotifyCollectionChanged. The problem, of course, is that not all the platforms have access to WindowsBase.dll. Thus the developers come to a crossroads: either recreate the functionality for the platforms or don’t implement the functionality.

While that may not seem too unreasonable a dilemma, the problem is that Microsoft implemented functionality in a branched assembly that really has no dependency on any classes or interfaces within that assembly. Here the principle is simple: when possible, move functionality up the assembly hierarchy so as to reduce cross dependencies. In layman’s terms, by moving the INotifyCollectionChanged interface to System.dll, many more projects can take advantage of it without requiring any sort of platform dependent code. And here it is important to remember that one of the original goals of .NET was to enable true cross platform development.

To say that this case is the only one of its kind would be ignorant. The scary thing is that I don’t think anyone actually has a list of where these mistakes exist and what can be done about them. Even scarier than that is the fact that Microsoft is making these mistakes. Consider the following which further demonstrates this point.

While helping someone today with a few questions on the System.Reflection namespace, a point was made about how odd it is to compare generic types. When you have a generic class such as Nullable<T> you cannot do something as simple as if(foo is Nullable) because the generic parameter can make a difference. While this isn’t too much of a problem, Microsoft later also developed the System.Data assembly and included an interface called INullable within this assembly under the System.Data.SqlTypes namespace. This, like INotifyCollectionChanged, constricts the use of this interface to only assemblies that reference System.Data.dll. Furthermore, the interface contains a single boolean property and has not a single dependency on anything within the System.data assembly.

The problem and its solution should be obvious: move INullable to the System namespace in System.dll and make Nullable<T> implement it. This allows developers to easily check whether or not a type represents a nullable type while not creating a single problem in the entire framework’s design. Furthermore it would allow developers to treat System.Nullable and System.Data.SqlTypes.* as the same types which can come in handy.

Update: I added a suggestion on Connect for moving INullable to System.dll.