The above output was generated by an Orc entity with an associated finite state machine (FSM). Although a FSM can be used for many things, in game development it’s typically used to model character behaviour. Why? It’s simple and easy to debug.

Let’s have a look at Main to get a high-level feel for using an Orc entity:

static void Main(string[] args)
{
    Orc o = new Orc();

    o.Event = OrcEvent.Wander;
    o.UpdateState();

    o.Event = OrcEvent.Eat;
    o.UpdateState();

    o.Event = null;
    o.UpdateState();

    Console.ReadLine();
}
 

In a real game loop the UpdateState method would be called once per frame. Continuing with a top-down approach, let’s see the components that make up an Orc entity. First, we find a enum to represent simple event identifiers.

enum OrcEvent
{
    Eat,
    Wander
}
 

Events can trigger a change in state. It’s possible to use a table to map events to associated states. For example, the OrcEvent.Eat maps to the EatState and the OrcEvent.Wander maps to the WanderState. However, states don’t always have a 1-to-1 correspondence. For example, an OrcEvent.SeeEnemy could map to an AttackState. Here we see a transition table specific to Orcs:

class OrcTransitionTable : Ai.StateTransitionTable
{
    public OrcTransitionTable()
    {
        base.table.Add(OrcEvent.Eat, new EatState());
        base.table.Add(OrcEvent.Wander, new OrcWanderState());
    }
}
 

The base type StateTransitionTable handles housekeeping chores for the table:

abstract public class StateTransitionTable
{
    protected Dictionary<object, IState> table = new Dictionary<object, IState>();

    public void SetState(object evt, IState state)
    {
        table.Add(evt, state);
    }

    public IState GetState(object evt)
    {
        Ai.IState i = null;

        try
        {
            i = table[evt];

        }
        catch (KeyNotFoundException)
        {
            return null;
        }

        return i;
    }
}

What exactly is IState? It’s an interface with 3 methods for state processing:

public interface IState
{
    void Enter(Entity e);
    void Execute(Entity e);
    void Exit(Entity e);
}
 

Each method takes an entity type as a parameter. When switching states, the Exit method is called for the current state. The new state’s Enter method is then called. The current state is then assigned the new state. Execute is called once per frame to perform state processing.

abstract public class Entity
{
    protected Ai.StateTransitionTable transitionTable = null;
    protected IState currentState = null;

    public void UpdateState()
    {
        if (currentState != null)
            currentState.Execute(this);
        else
            System.Diagnostics.Trace.WriteLine("zero state");
    }

    public object Event
    {
        set
        {
            if (value == null)
            {
                currentState.Exit(this);
                currentState = null;
                return;
            }

            IState i = transitionTable.GetState(value);

            if (i != null)
            {
                if (currentState != null)
                    currentState.Exit(this);

                currentState = i;
                currentState.Enter(this);
            }
        }
    }
}
 

Implementing an Orc entity is trivial:

• Inherit from Ai.Entity
• Set the transition table in the constructor
• Start adding methods for the new character

class Orc : Ai.Entity
{
    static Orc()
    {
        transitionTable = new OrcTransitionTable();
    }

    public void Drool()
    {
        Console.WriteLine("drooling...");
    }
}
 

Of course, an entity will need a variety of states to transition to. To create a new state type implement the IState interface. For example, here are a few Orc-related states:

class EatState : Ai.IState
{
    public void Enter(Ai.Entity e)
    {
        Console.WriteLine("entering eat state");
    }

    public void Execute(Ai.Entity e)
    {
        Console.WriteLine("executing eat state");
    }

    public void Exit(Ai.Entity e)
    {
        Console.WriteLine("exiting eat state");
    }
}

class OrcWanderState : Ai.IState
{
    public void Enter(Ai.Entity e)
    {
        Console.WriteLine("entering wander state");
    }

    public virtual void Execute(Ai.Entity e)
    {
        Console.WriteLine("executing wander state");

        Orc o = e as Orc;

        if (o != null)
            o.Drool();
    }

    public void Exit(Ai.Entity e)
    {
        Console.WriteLine("exiting wander state");
    }
}

class CustomizedOrcWanderState : OrcWanderState
{
    public override void Execute(Ai.Entity e)
    {
        base.Execute(e);

        Console.WriteLine("unique orc personality here...");
    }
}
 

Those are the basics of implementing a finite state machine for character control. You can download the source code here.

One day I’ll have to learn how to record, edit, and post videos online. Until then, it’s nothing but a static screenshot for you:

You can download the source here.

The above image is from the demo called Elasticity. Drag the square and then let it go. The square will snap back to the origin as if it were attached to an elastic band.

The next image is from the demo called Swarm. It tries to mimic a swarm of fruit flies chasing your cursor.

I cleaned up the source just enough so that it would run. You can download the source for Elasticity and Swarm here.

Here’s a little tool I made for fun to control my Kondo KHR-1. It hasn’t been thoroughly tested, so don’t be surprised if any “features” pop up. You can download the source here.

The first thing to do is download the PhysX SDK. After it’s installed, you’ll need to set the directory paths in Visual Studio for the include files:

The demo has standard first-person camera controls. Also, be sure to check out WM_KEYDOWN in the WindowProc for a list of other controls.

Novo2.zip – Lesson 102 – Sphere and Torque:

Novo3.zip – Lesson 103 – Capsule, Local Pose, and Center of Mass:

Novo4.zip – Lesson 104 – Convex Shapes and Anisotropic Friction:

Novo5.zip – Lesson 105 – The User Contact Report and the Contact Stream Iterator:

Novo6.zip – Lesson 106 – Static and Kinematic Actors. The screenshot doesn”t look like much, however, the user can control the middle cube (as a kinematic actor) bouncing it off the other actors.

This file type is associated with Maya, it has the .mb extension and a custom icon. Double-clicking the file will open it in Maya. Today, we’re going to associate TestApp with the .testapp extension:

To associate a file type, you need to do three things:

1. Add the file extension and associated application to the registry.
2. When double-clicking a .testapp file, determine whether an instance of the associated process is already running.
3. If the application is already running, pass the file across process boundaries.

The first step is easy and makes use of the following Win32 functions to create and set entries:

• RegOpenKeyEx
• RegCreateKeyEx
• RegSetValueEx

The code to create key/value pairs in the registry is straightforward. Therefore, I’m not going to list it here so please reference the source code included in today’s download.

After executing the registration code, you should have new keys under HKEY_CLASSES_ROOT with the following structure:

And a new TestApp key where we assoicate the file with a default icon (which is indexed at 0 as an embedded resource in the executable):

The executable to launch is set under the Command section, with %1 being the command line param:

Use RegEdit to verify the above entries after executing today’s demo. To execute RegEdit use the Run prompt:

Once the file associations have been added to the registry, the next thing to do is determine if an instance of TestApp is running. The Process class in the System::Diagnostics namespace makes this step trivial.

So how does one application communicate with another across process boundaries? Under Win32 you use named pipes. A pipe connects two ends together – a client and server. Under .NET, named pipes have been wrapped up in the System::Runtime::Remoting::Channels::Ipc namespace. An IpcChannel is used when one application needs to communicate with another application in a different process on the same machine.

However, before we look at inter-process communication (IPC) let’s have a look at class SimpleFile which represents our .testapp file format.

public ref class SimpleFile : public MarshalByRefObject
{
    public: delegate void LoadDelegate(SimpleFile^ simpleFile);
    private: LoadDelegate^ loadDel;

    public: event LoadDelegate^ LoadEvent
    {
        void add(LoadDelegate^ value)
        {
            loadDel += value;
        }

        void remove(LoadDelegate^ value)
        {
           loadDel -= value;
        }
    }
 

Remoting is used for communication between app domains. An app domain is a logical container for a .NET applciation and is often refered to as a “lightweight process”.

The same remoting mechanism is used between two app domains whether those app domains are in the same process, in different processes on the same machine, or different processes on different machines. Any type that wants to expose its availability across app domains must inherit from MarshalByRefObject or be serializable.

To keep things as simple as possible, the SimpleFile “format” only contains a single value, which is parsed and stored:

private: int ultimateAnswer;
public: property int TheAnswerToTheUltimateQuestionOfLifeTheUniverseAndEverything
{
    int get() { return this->ultimateAnswer; }
}

public: void Load(String^ filePath)
{
    XmlTextReader^ xtr = gcnew XmlTextReader(filePath);

    while( xtr->Read() )
    {
        if( xtr->NodeType == XmlNodeType::Element )
        {
            if( xtr->Name == "UltimateAnswer" )
            {
                xtr->Read();
                this->ultimateAnswer = int::Parse(xtr->Value);
            }
       }
    }

    xtr->Close();
    delete xtr;

    if (loadDel != nullptr)
        loadDel(this);
}
 

Here we see the value stored in the sample file foobar.testapp:

The constructor in the Form class is overloaded to accept an array of arguments:

public: Form1(array<String^>^ args)
{
    InitializeComponent();

    // - in this example, we register the file type associations every time
    //   the application runs (overwriting keys)
    // - however, you would normally do this only once as part of your
    //   installation process
    RegisterFileAssociations();

    // - cache any arguments passed from Main
    this->args = args;
}
 

If there were no arguments passed, the application is starting up for the first time.

private: System::Void OnFormLoad(System::Object^ sender,
                                 System::EventArgs^ e)
{
    // - application is loading for the first time
    if( args->Length == 0 )
    {
        RegisterService();
    }
 

The host or server has to tell .NET which object’s it’s willing to expose. These objects or well-known types are registered using the static method RegisterWellKnownServiceType of the RemotingConfiguration class.

The host also has to register a channel with ChannelServices. A channel will monitor a port and accept incoming calls, servicing those calls with a thread from the thread pool. The IpcChannel is a welcome addition because prior versions of .NET provided only the TcpChannel and HttpChannel for communication. Both TcpChannel and HttpChannel have associated overhead for the network stack regardless if the communication taking place is on the same machine or across a network. IPC provides a direct line, reducing overhead and increasing performance.

private: void RegisterService()
{
    BinaryServerFormatterSinkProvider^ serverProv = 
        gcnew BinaryServerFormatterSinkProvider();
    serverProv->TypeFilterLevel = TypeFilterLevel::Full;

    Hashtable^ properties = gcnew Hashtable();
    properties["portName"] = "SimpleFileServer";

    IpcChannel^ ipc = gcnew IpcChannel(properties, nullptr, serverProv);
    ChannelServices::RegisterChannel(ipc, false);

    RemotingConfiguration::RegisterWellKnownServiceType(
                                      SimpleFile::typeid,
                                      "SimpleFile.rem",
                                      WellKnownObjectMode::Singleton);

    file = (SimpleFile^)Activator::GetObject(
                                      SimpleFile::typeid,
                                      "ipc://SimpleFileServer/SimpleFile.rem");

    file->LoadEvent += gcnew SimpleFile::LoadDelegate(this,
                                                      &Form1::OnProjectFileOpen);
}
 

During server registration, a SimpleFile is activated and its LoadEvent is hooked up to the following:

private: delegate void InvokeDelegate(SimpleFile^ simpleFile);
private: void OnProjectFileOpen(SimpleFile^ simpleFile)
{
    // cross-thread op
    array<Object^>^ arr = { simpleFile };
    this->Invoke(gcnew InvokeDelegate(this, &Form1::ProcessFile), arr);
}

public: void ProcessFile(SimpleFile^ simpleFile)
{
    this->label2->Text =
        simpleFile->TheAnswerToTheUltimateQuestionOfLifeTheUniverseAndEverything.ToString();
}
 

Invoke is used to update the Form’s user interface. Execution has to take place on the caller’s thread to avoid a cross-thread exception.

Back to OnFormLoad, where a list of processes is then assembled. It’s possible the process was launched with a double-click on a .testapp file. If so, services need to be registered and a SimpleFile loaded:

array<Process^>^ processArray =
    Process::GetProcessesByName(Process::GetCurrentProcess()->ProcessName);

// application loading for the first time from a double-click on file
if( processArray->Length == 1 )
{
    RegisterService();

    SimpleFile sf;
    sf.LoadEvent += gcnew SimpleFile::LoadDelegate(this,
                                                   &Form1::OnProjectFileOpen);
    sf.Load(filePath.ToString());
}
 

Otherwise, a process is already running and SimpleFile needs to get its information across process boundaries. Here we see the client registering an IpcChannel and activating the well-known file (SimpleFile):

else if( processArray->Length > 1 )
{
    MessageBox::Show("Instance already running, passing args along");

    for each( Process^ p in processArray )
    {
        if( p->Id != Process::GetCurrentProcess()->Id )
        {
            try
            {
                IpcChannel^ ipc = gcnew IpcChannel("SimpleClient");
                ChannelServices::RegisterChannel(ipc, false);

                SimpleFile^ file =
                    (SimpleFile^)Activator::GetObject(
                                        SimpleFile::typeid,
                                        "ipc://SimpleFileServer/SimpleFile.rem");

                if (file == nullptr)
                {
                    MessageBox::Show("Failure to connect with remote server");
                    this->Close();
                }

                file->Load(args[0]);
                this->Close();
            }
            catch(Exception^ e)
            {
                MessageBox::Show(e->Message);
            }

        } // end if

   } // end for each

} // end else if
 

In summary, the application is now assoicated with a file type. Double-clicking the file will launch the app. If the app is already running, IPC will be used to pass the file info across process boundaries, allowing the application already running to open the file as a new “project”.

Build and run the demo once to associate the file type in the registry. If you don’t see a blue icon for “foobar.testapp”, hit F5 in the explorer window to refresh it. Shut down the application and then try double-clicking various files with the .testapp extension.

You can download the source here.

Today’s Solution consists of a C++/CLI class library containing a Flash splash screen class. A C# Windows application is used to test splash screen functionality. Please note that simply copying an existing Form (ie. the FlashForm in today’s download) between projects is not recommended because you’ll run into a lot of errors. Ultimately, it”s faster if you create the Form in the target project and then copy ‘n paste portions of the code over (rebuilding along the way).

Instructions on how to setup a ShockwaveFlash control can be found here.
The code for using Flash as a splash screen (including the .fla) is available for download here

Today’s post covers how to host Flash in a C# application with two-way communcation between environments. Here’s a screenshot of the demo:

Clicking the green button in Flash pops up a message box in C#. Entering text in C# and clicking the Send button echos it in Flash.
The first step is to add the Shockwave Flash ActiveX control to the Toolbox (it doesn’t matter which group you add the control to):

After selecting the component from the COM tab, you should see a new icon in your Toolbox:

Now, drag ‘n drop this control onto Form1 and you should get the following:

Something broke with the release of VS2005. You should have no problem doing the above in VS2003. However, I don’t have VS2003 so what’s the solution? As it turns out, the answer is in the warning messages. There was a failure to create a wrapper assembly due to a COM exception. Well, I know of another .NET language that should have no problem interacting with COM…

Now create a new FlashPanel user control:

The FlashPanel is a derivative of UserControl. In the designer, repeat the above steps – drag ‘n drop the Flash object onto the panel and set its Dock property to ”Fill”. The C++/CLI control library will successfully create a wrapper assembly for the ActiveX control. Add the following property so C# can access the Flash object:

public: property AxShockwaveFlashObjects::AxShockwaveFlash^ Flash
{
    AxShockwaveFlashObjects::AxShockwaveFlash^ get()
    {
        return this->axShockwaveFlash1;
    }
}
 

Once you build the control library, you should see your new UserControl in the Toolbox:

Now create a C# Windows application. Under the References folder, add the following:

Next, we begin using our FlashPanel. The ActiveX Flash control has a LoadMovie function which takes an absolute directory path to the .swf file. It also has an FsCommand delegate:

public Form1()
{
    InitializeComponent();
    string moviePath = Application.StartupPath + "test.swf";
    this.flashPanel1.Flash.LoadMovie(0, moviePath);
    this.flashPanel1.Flash.FSCommand += new
        AxShockwaveFlashObjects._IShockwaveFlashEvents_FSCommandEventHandler(
                                                            OnFsCommand);
}
 

FsCommand is used by Flash to communicate with the host environment. In the test.swf file, the green arrow button has the following ActionScript attached to it:

on(release)
{
    fscommand("ButtonClick", "You clicked a button in Flash");
}
 

OnFsCommand will respond to messages from Flash. In this example, it only checks for the “ButtonClick” message:

void OnFsCommand(object sender,
                 AxShockwaveFlashObjects._IShockwaveFlashEvents_FSCommandEvent e)
{
    if( e.command == "ButtonClick")
        MessageBox.Show(e.args);
}
 

When sending a message to Flash, we use SetVariable passing both the message name and value:

private void OnSendButtonClick(object sender, EventArgs e)
{
    this.flashPanel1.Flash.SetVariable("DotNetMessage", this.textBox1.Text);
}
 

If you wanted to send more information in the value param you could use a delimiter. For example, “foo?bar” would need to be parsed and split based on ”?” characters to extract multiple values.
The last bit of ActionScript code is used to setup event listening. The root watches for a “DotNetMessage” and then passes it along to the listener object. The code in this example, simple echos any value to the textbox control inside Flash.

var listenerObj:Object = new Object();
listenerObj.onMessage = function (prop, oldVal, newVal)
{
    _root.textBox = newVal;
}
_root.watch("DotNetMessage", listenerObj.onMessage);
 

The .fla file is available in the Debug directory. You can download the source code here.

[Serializable]
public partial class Form1 : Form
 

And attempt to serialize the object, I will get an exception.

Adding a serializable attribute to the base Form is not possible and many people at this point move on looking for another solution. However, it is possible to make Form1 serializable through custom serialization. To do this, first add ISerializable to the inheritance chain:

[Serializable]
public partial class Form1 : Form, ISerializable
 

And then implement it:

void ISerializable.GetObjectData(SerializationInfo info, StreamingContext context)
{
    info.AddValue("Location", this.Location);
    info.AddValue("ClientSize", this.ClientSize);
}
 

An exception is no longer produced when running the code now. After execution, you should find a ”Form1.bin” file in the Debug directory. Despite this, a binary file is not very user-friendly. Let’s modify the code so we can actually open the file and read it. Rather than using a BinaryFormatter, why not a SoapFormatter? To use soap formatting you’ll need to add a reference to the assembly:

using System.Runtime.Serialization.Formatters.Soap;
//...

FileStream fileStream = File.Create("Form1.xml");
IFormatter iFormatter = new SoapFormatter();
iFormatter.Serialize(fileStream, form);
 

In the above code, I’ve changed the file name from Form1.bin to Form1.xml. However, the file extension doesn’t impact the content. Here’s a sample of the output:

So, serialization works but what about deserialization? To accomplish that, you need to implement a deserialization constructor:

private Form1(SerializationInfo info, StreamingContext context)
{
    DefaultInitialization();
    this.Location = (Point)info.GetValue("Location", this.Location.GetType());
    this.ClientSize = (Size)info.GetValue("ClientSize", this.ClientSize.GetType());
}
 

The DefaultInitialization function calls InitializeComponent and then assigns some default values. Calling InitializeComponent is important if you want the Form and any of its controls to be initialized appropriately.

private void DefaultInitialization()
{
    InitializeComponent();
    this.StartPosition = FormStartPosition.Manual;
    this.Location = new Point(0, 0);
    this.ClientSize = new Size(640, 480);
}
 

The DefaultInitialization function is also called from the default constructor:

public Form1()
{
    DefaultInitialization();
}
 

Deserialization can’t occur after Application.Run returns because the Form has already been destroyed. Here, we plug-in to the FormClosing event to handle deserialization:

private void OnFormClosing(object sender, FormClosingEventArgs e)
{
    FileStream fileStream = new FileStream("Form1.xml",
                                           FileMode.Create,
                                           FileAccess.Write);

    IFormatter iFormatter = new SoapFormatter();
    iFormatter.Serialize(fileStream, this);

    fileStream.Close();
}
 

Finally, we can bring it all together in Main:

[STAThread]
static void Main()
{
    Form1 form = null;

    if (File.Exists("Form1.xml"))
    {
        FileStream fileStream = File.Open("Form1.xml", FileMode.Open);
        IFormatter iFormatter = new SoapFormatter();
        form = iFormatter.Deserialize(fileStream) as Form1;

        fileStream.Close();
    }

    if (form == null)
        form = new Form1();

    Application.Run(form);
}
 

With this simple example, you can position and resize the Form; restart the application and it will remember your previous settings. Now I’m not saying this is a way to save Form settings. There are numerous methods including:

• app.config
• .resources
• .ini
• manual parsing of various file formats

The real demonstration here is how to make an object serializable when the base class isn’t.

PickingDemo.zip – A simple ray picking demo using DirectX and C++/CLI .Drag and click the arrow to slide it back and forth.

OrthoPickingDemo.zip – A simple demo of picking in an orthographic viewport using DirectX and C++/CLI:

LerpDemo.zip – C++ DirectX demo of linear interpolation between keyframes using an assembly shader.