Voyage Games

Cleaning Up a Singleton in C++

Your DisplayName here! — Wed, 30 Jul 2008 03:51:06 GMT

Yes, I'm aware it's been quite a while since my last post. I've been caught up with moving to a fun new city, working a fantastic new job, and buying a house.

I stumbled across a problem recently at work dealing with singletons and cleaning up resources in C++. There are two common methods of creating a singleton, the first being not thread-safe:



public class Singleton

{

public:

   static Singleton* getInstance()

   {

      // The following static will be created once per thread!

      static Singleton instance;

      return &instance;

   }



private:

   Singleton() {}

};

The second being (mostly) thread-safe:



public class Singleton

{

public:

   static Singleton* getInstance()

   {

      if (!m_instance)

      {

         m_instance = new Singleton();

      }



      return m_instance;

   }



private:

   static Singleton* m_instance = NULL;

   Singleton() {}

};

This second case provides a thread-friendly method of creating only a single instance of the class. (There is a small race condition in that the conditional may be entered by one thread, then having another thread get swapped in before the instance is actually created, but the time window for such a race condition is small enough to generally be safe for use.) However, sharper viewers may have noticed a small problem: The new'ed instance memory is never freed! The intertubes are ablaze with debate about this problem.

On the one hand, it seems to be common (and downright sloppy) practice to rely upon the OS to free the memory when the application shuts down. That's all fine and dandy when you only work on a "modern" OS, but what if you're working on an embedded system? Or if your singleton is consuming system (or third-party) resources that need to be released? My take on the issue is that you should always clean up after yourself; don't rely on the OS to pick up your mess.

So, what can we do about it? Some people suggest creating some sort of dispose method that the programmer is required to call before exiting the program. While it's a step in the right direction, this is still a bad idea. For any of you who work with more than a couple of programmers, you know how hard it is to maintain a large code base on such "assumptions" of what you are supposed to do (nevermind the problem of your Singleton class being part of a library that is referenced by third-party applications). But what can we do about it?

The solution is rather simple. Make a class to clean up your mess:



private class SingletonCleaner

{

   ~SingletonCleaner()

   {

      Singleton::getInstance()->dispose();

   }

}



public class Singleton

{

friend class SingletonCleaner;

public:

   static Singleton* getInstance()

   {

      if (!m_instance)

      {

         m_instance = new Singleton();

      }



      return m_instance;

   }



private:

   static Singleton* m_instance = NULL;



   Singleton()

   {

      static SingletonCleaner cleaner;

   }



   static void dispose()

   {

      if (m_instance)

      {

         // Clean up any other used resources
here as well

         delete m_instance;

         m_instance = NULL;

      }

   }



};

What's going on here? We're simply creating a static instance of a friendly class in our Singleton constructor. We don't have to worry about making the cleaner instance thread-safe, as our Singleton will only enter it's constructor once per process. By making it static, it will survive until the process exits, at which point its own destructor will be called. This, in turn, will call the private and static dispose() method of Singleton, cleaning up the Singleton instance and freeing any other system resources it may have acquired. Simple and easy!

Let me hear your thoughts, questions, concerns, and arguments. I think it's a pretty solid design, quick and easy, and self-maintaining.

(Bear with me if I've made any compiler errors. I'm writing this up on a system that does not currently have a C++ compiler.)

Cheers!

Devan

XNA and Mono (and Converting Lua to IL)

Your DisplayName here! — Sat, 26 Apr 2008 02:01:09 GMT

I discovered today that there's a port for XNA to run on Mono (powered by OpenGL). I'm not sure how up-to-date the port is (there doesn't seem to be much recent activity in the group discussions), but I may look into this once I pull my spare box out of storage (and load Linux on it). It's been a few years since I played with Mono and I'm guessing it's much more stable now than when I first toyed with it (back in the days of .Net 1.1). I'd like the idea of being able to port my games over to Linux and Mac OS X as well.

But it looks to be an encouraging idea of a port!

Also, I ran across this compiler for Lua to Microsoft IL. It may just solve those problems about using Lua on the XBOX 360. Again, something to look into and report back on.

Cheers!

Devan

XNA and Unit Testing

Your DisplayName here! — Sat, 26 Apr 2008 01:54:27 GMT

Unit testing can create some problems when working with GUI applications, like an XNA game. How do you verify that something looks right when you're running automated tests?

I've been working with building a simple game engine (so far I've got sprite rendering, collision testing, quadtree culling, and a Lua console) and I bumped up against the unit test problem. I'm afraid I attacked it from the wrong direction. I started with some automated tests, but I started to devolve into using a patchwork system of visual (non-automated) unit testing. It's my plan this weekend to go about and fix the issues I've encountered.

Lessons learned:

You should generally only visually test (as an independent test) the elements of your application that actually involve drawing. I failed this by creating a test that simply draws my sprite (a valid use of the test), then creating another that updates the sprite's properties. Updating properties and other non-visual changes should be tested in automated tests; you'll be much more productive. The only time you should create a new visual test when you're testing something new about the drawing process. Assuming your automated tests passed okay (and that you are testing for the right things), your visual tests shouldn't care about whether the same code was done properly, only that the rendering looks okay.

It's just been one of those weeks where you start thinking along one line, get distracted, and before you know it, you're lost in the urban wilderness. :-P

Cheers!

Devan

Lua Implementation in C#

Your DisplayName here! — Fri, 18 Apr 2008 02:28:59 GMT

I've been studying Lua more in depth lately and I've been turning over a more difficult question in my head: How can you combine XNA, with it's inherent constrictions due to the XBOX 360, and a scripting language such as Lua?

The problem is that, at runtime, Lua uses JIT compiling of unmanaged C code. Unmanaged code can not be run on the XBOX 360 alongside XNA. There is the possibility of using C# scripting; however, the necessary functionality for building the scripts on-the-fly are not included in the version of the .NET Framework running on the XBOX 360. As described here, it is possible to pre-compile your scripts and load them as an assembly.... But that is not particularly helpful for debugging/development. Is there a solution to this problem?

I've been tossing the idea around of writing a Lua-like implementation in C# that would not need to be compiled; it would simply be parsed at runtime by an assembly written for such a purpose. However, there are two main concerns that have leapt out to me so far:

The obvious, performance issues. It may be possible to work out a method for this. I haven't spent the time on this yet, however.
Functions. I could use delegates, but I'm not sure yet how to handle the variable number of arguments into a function.

Of course, it may be better just to go with the pre-compiled C# scripts to begin with. Thoughts?

Cheers!

Devan

State of a Particle

Your DisplayName here! — Wed, 09 Apr 2008 02:49:29 GMT

I've got the first attempt at a XNA state-machine driven particle system up and running, but it has some issues. Taking a second look at the way I integrated the particles into the more generic state machine, I'm not happy with my implementation.

I think I'll keep the foundation of my state machine, but re-design the interface with the particle system. Right now, I'm having some problems differentiating the different states of the independent particles because I built the "current" state into the state machine, rather than into the particles themselves. Thus, when one particle changes states, they all change states.

This is an easy enough fix, but the way the particle system is tied to the state machine bothers me. I think I'll use the core state machine as a foundation class (I think I designed it rather well as a generic state machine system), but I'll create an inherited class that implements the particle system specifically. That part of my design wasn't so clean the first time around - that's what I get for trying to rush and get it done in one sitting!

One problem I ran into with the generic state machine is how to modify settings within the StateObject class that is passed into the StateMachine. I ended up creating a Hashtable of attributes within the StateObject. In the State object, an attribute can be set to change and is looked up by its identifier string. It's a fairly expandable system (attributes can easily be created and modified at will), but I'm not 100% sure that I like it - there is some overhead with looking up into the Hashtable for existing attributes, as well as not providing very elegant ways to process that information. Time will tell. I may end up replacing it with a static system within the various inherited implementations of the StateMachine (the ParticleStateMachine, for instance, would know that the Particle objects have an "Age" attribute). On the other hand, I may decide that I'm adding so much to the Particles that the Hashtable turns out to be handy! We'll see.

Right now, the basic system looks like this:

StateMachine - Contains the different states, as well as system-wide settings (maximum particles to create, how often to create them, etc. - specific examples for the ParticleStateMachine).
State - Contains processing details about a specific state (changes attributes, performs if less than/greater than checks, tells the StateObject to switch to another state contained in the parent StateMachine, etc.).
StateObject - A generic interface into an object being passed through the StateMachine. Each inherited implementation of the StateMachine will expand upon this as needed (i.e., the ParticleStateObject will contain an "Age" attribute as mentioned previously).

Knowing that I'm going to be changing the implementation, I'll hold off on posting code till I clean up the system a bit. I wouldn't want just everyone to see my messy coding! ;-)

Cheers!

Devan

Anatomy of a State-Driven Particle System

Your DisplayName here! — Fri, 04 Apr 2008 04:13:21 GMT

Sitting bored in the Data Platform session of Microsoft's Heroes Happen Here conference, I began formulating how my state machine-driven particle system for XNA is going to be structured. Here is what I've come up with so far:

The ParticleSystem class: This class will be the top-level system, containing both the state machine that drives the system, as well as performance optimizations for rendering (under the initial assumption that the particles will be rendered as point sprites). During creation of the ParticleSystem, a maximum number of particles will be specified and a dynamic vertex buffer will be created to arrange for them. That's the basic rendering part. The real joy of the system will be in the state machine.....

Every elementary particle state machine will have three basic states: Creation, Processing, and Death. Every pass through an Update, the particle system will make each particle start at it's current state and run through all the states it possibly can until it is not directed to process another state. At this point, it stops being processed until the next pass, at which point it starts back at the top of the last state it had entered. To make this more clear, I'll demonstrate with some pseudocode how the different states work:

Creation:
- Create the particle.
- Go to the Process state (and continue processing during this pass).

Process:
- Check if the particle has reached it's age limit:
- If so, go to the Death state (and continue processing during this pass).
- If processing gets this far, the particle's still alive and may perform additional manipulation. Once it's out of actions to perform, it will stop being processed for this pass and the next pass will start at the top of this state.

Death:
- Remove the particle (and stops processing).

I'll start pounding out a system for this over the weekend. I may forgo the point sprites for now in favor of just a quick and dirty normal sprite rendering centered at the particle's location until I get the state machine working.

Cheers!

Devan

Microsoft's Hereos Happen Here Product Release Conference

Your DisplayName here! — Fri, 04 Apr 2008 04:00:38 GMT

I had the opportunity to escape from work today and attend Microsoft's Heroes Happen Here conference in Las Vegas. For those unaware, it is essentially a produce release conference that Microsoft is doing all over the country through the end of June. They are giving away free copies of Windows Server 2008, SQL Server 2008, and Visual Studio 2008, well worth the attendance even without the speaking sessions. However, I did attend both the Data Platform (database-oriented) and Developer sessions.

My thoughts:

Data Platform session: There was really nothing that wowed me here. Granted, I'm a coder, but I have enough background in database management that it's not all just noise to me. However, I thought the presentation was poorly arranged and delivered. There seemed to be a couple of neat things (Resource Management, for one), but I didn't see many demos. Our speaker's delivery was fairly awful; he was rather weak-voiced, wasn't very exciting to listen to, and would basically stop talking when something didn't go right, which happened often. He appeared to be trying to run too much on his machine at once, which meant that all his demo time was sucked up trying to get the various application windows to switch back and forth. The first two hours had a lot of dead air time that was making me think I should like to go eat a real breakfast rather than listen to him saying things like "it worked last night". Skip this one if you have a chance.

Developer session: Blew me away. The speaker, Rob Bagby, was an incredible speaker, keeping the audience riveted, cracking jokes, and flying through code samples so fast it was almost difficult to follow him (almost). He pretty much skipped over the boring marketing-type presentation slides and would go straight to the meat. Plus, he demonstrated many different cool elements of .NET 3.5, including WPF, LINQ, extending Office applications, and web service-driven solutions. He actually tied all of his demos into one continuous demonstration, building upon the system throughout the entire four-hour talk. It was amazing and I learned a lot of new things, plus good reference material for replicating his process (he mentioned a screencast of the talk would be on his blog). Despite his fast talk and fast coding, he did run out of time, provoking a mystery organizer to grab a mic and announce "This is not God, but it is 4:30". Rob wrapped up nicely and left me excited to get home and play with my new software.

I highly encourage everyone to attend the Heroes event nearest to them, for the software, and for the Developer talk if possible.

Cheers!

Devan

XNA and 3ds MAX's Particle Flow

Your DisplayName here! — Thu, 03 Apr 2008 02:20:30 GMT

(I need to get in the habit of posting when I don't have code to share.)

Something I've wanted to do for a while is develop a really flexible and highly configurable particle system for XNA. I've seen some solutions (samples, really) that are rather hacked or not very extensible. Microsoft XNA Unleashed had a solution that I thought was decently constructed and easy to use with small projects, but was still fairly constrictive for what I'd like to see. Maybe I've just been pampered....

Several years ago, I ran across the Particle Flow system in 3ds MAX. It is an incredibly powerful system. Using a state machine driven system, it provides a drag-and-drop view for designing systems. Modifiers such as rotation and scale can be added at different states, if/else conditionals can be added for branching, new spawning/death events can be added at will, and even collision checks against objects in the 3ds scene.

So, I'm going to start designing a particle system similar to Particle Flow that can be used with XNA and I'll be detailing my progress right here in my blog. I think to start with, I'll break the system down into these parts:

The system:

States

Rules
Particles

The state machine system will be broken into states (duh). Each state will hold a list of rules, which will consist of different attributes (rotation, scale, position), actions (spawn, die), and hooks (attachments to [update: point] sprites) to begin with. Tentatively, conditionals will be added eventually, as will such things as AI behaviors, attaching 3D objects, and bounding volume collision checks. The particles will be the physical objects in the system. Each time a particle is created, it will start at the top of the state machine specified during its creation. Some particles may spawned by other particles and may traverse the same state machine or a different one.

That's what I'll start with and we'll see where this takes me! Leave me a comment if you have a suggestion or questions.

[Update:] I think I'll have a top-level particle system that will hold all of the particles, as well as handle their updating and rendering through the use of dynamic vertex buffers, as done in the Creators Club sample.

Cheers!

Devan

Extended XNA Console Component with Lua Virtual Machine

Your DisplayName here! — Mon, 10 Mar 2008 00:52:01 GMT

I’ve made an extension to the Console component sample posted on Ziggyware. It provides access to a Lua virtual machine through the console. I believe many of you budding (or experienced) XNA developers out there may find of use.

I’d like to thank Kevin Jurkowski for his Console sample, it gave me a fine starting point from which to expand upon. Also, I’d like to note that I have updated his sample to run on XNA 2.0. Second, I’d like to thank Martin Echenique’s great example of adding Lua functions to a .NET program using reflection, as detailed here. I wrote about this project in a previous post and expanded upon it somewhat; this is the base Lua project that I utilize for this sample. In this post, I will simply explain how I integrated it into the Console component.

Download my sample project here:

ConsoleWithLua.zip (801.74 KB)

First, I added a Lua function, GetFPS, to the Game1 class. This returns the FPS component added to our Game class. Make sure to include the LuaNetInterface assembly.

using LuaNetInterface;



///
<summary>


///
Gets the FPS component of the game.


///
</summary>


[LuaFunctionAttribute("GetFPS", "Gets
the FPS component.")]

public DrawableGameComponent
GetFPSComponent()

{

return FPS;

}

Then, I added a Lua virtual machine to the Game1 class. After initializing it, I registered the functions in this class (the only function that gets registered is our GetFPS() method). When we create the ConsoleComponent object, we pass our Lua virtual machine as an argument.

///
<summary> ///
The Lua virtual machine for our game. ///
</summary> private LuaVirtualMachine
lua; public Game1()
{ ... //
Create our Lua virtual machine lua = new LuaVirtualMachine();
lua.RegisterLuaFunctions(this);
Components.Add(new ConsoleComponent(this,
lua)); ... }

These are all of our changes to the main Game1 class. I also added a basic InputManager class, but it’s nothing out of the usual for usage of keyboard input. Just take a quick look at the class if you need to; it’s fairly basic and self-explanatory.

On to the modified ConsoleComponent class. I added the LuaInterface and LuaNetInterface assemblies to the class to access the needed Lua objects.

using LuaInterface; using LuaNetInterface;

We added a LuaVirtualMachine (Lua VM) object to the console class. It stores the Lua VM object sent in through the object’s constructor. In the Initialize() method, the Lua VM registers the functions in our class (note: we’ll add these later). I also created an instance of our input manager class in the console class.

private LuaVirtualMachine
_lua; private InputManager
_inputManager; public ConsoleComponent(Game
game, LuaVirtualMachine lua) : base(game)
{ //
If no Lua scripting virtual machine was passed in, create one if (lua
== null)
lua = new LuaVirtualMachine();
_lua = lua;
} public override void Initialize()
{ ... _inputManager = new InputManager(Game);
.... }

I added a ValidCharacter struct to the console class. It specifies valid characters that can be entered (both normal characters and alternate characters that are displayed when a Shift key is pressed). I defined the list of valid characters in the RegisterValidKeys() function, called from within Initialize(). These are held within a hash table for quick access.

internal struct ValidCharacter
{ ///
<summary> ///
The standard character to display. ///
</summary> public char Character; ///
<summary> ///
The character to display when the Shift key is pressed. ///
</summary> public char ShiftedCharacter; ///
<summary> ///
Creates a valid text characters structure. ///
</summary> ///
<param name="ch">The standard character to display.</param> ///
<param name="shiftCh">The character to display when the Shift key is pressed.</param> public ValidCharacter(char ch, char shiftCh)
{ Character = ch;
ShiftedCharacter = shiftCh;
} }

I radically re-vamped the Update() method. First, I go through all of the pressed keys from the input manager and update our command string based upon the valid keys pressed that we have registered.

bool shiftDown = _inputManager.CurrentKeyboardState.IsKeyDown(Keys.LeftShift)
|| _inputManager.PreviousKeyboardState.IsKeyDown(Keys.RightShift); Keys[] keysPressed = _inputManager.CurrentKeyboardState.GetPressedKeys(); //
No need to do further processing if no keys were pressed if (keysPressed.Length
> 0) { //
Process valid keys just pressed foreach (Keys
key in keysPressed)
{ if (_validChars.ContainsKey(key)
&& _inputManager.PreviousKeyboardState.IsKeyUp(key)) { ValidCharacter ch = (ValidCharacter)_validChars[key]; if (shiftDown)
_command += ch.ShiftedCharacter; else _command
+= ch.Character; } } }

I also added some functionality for scrolling up and down through our console log. This is not critical to our changes, so I won’t discuss it in-depth, but you may find it useful to look over. These update changes modify our Draw() function a bit, but nothing serious. The meat of the final changes to Update() are where we enter a valid command and process it using the Lua VM. From there on, Lua handles the rest!

if (_inputManager.JustPressed(Keys.Enter)
&& _command != "")
{ _logOffset = 0;
_log.Add("");
_log.Add(_prefix + _command); try { if (_lua
!= null)
{ if (_lua.IsRunning)
_lua.Lua.DoString(_command); else _log.Add("ERROR:
Lua Virtual Machine is no longer running."); } else _log.Add("ERROR:
Lua Virtual Machine has not been set."); } catch (LuaException
e) { _log.Add("Lua
Error: " + e.Message);
} _command = "";
}

I also updated the Draw() method a bit. I’ll reproduce it here, but there should be nothing to surprise you there, outside of the inconsequential display changes I mentioned earlier.

public override void Draw(GameTime
gameTime) { if (_active
== true)
{ float prefixHeight = _font.MeasureString(_prefix).Y; float drawHeight; //
Saves a copy of the current screen into the texture. This allows the menus to be transparent Game.GraphicsDevice.ResolveBackBuffer(_texture); //
Without restoring the states properly, the alpha blending will cause some problems _spriteBatch.Begin(SpriteBlendMode.AlphaBlend,
SpriteSortMode.Immediate, SaveStateMode.SaveState); //
Draw the full background texture _spriteBatch.Draw(_texture, new Rectangle(0,
0, Game.GraphicsDevice.Viewport.Width, Game.GraphicsDevice.Viewport.Height), Color.White); //
Draw transparent menu _spriteBatch.Draw(_texture, new Rectangle(0,
0, _width, _height), new Rectangle(0,
0, _width, _height), Color.Gray); //
Draw command string _spriteBatch.DrawString(_font, _line + _prefix + _command, new Vector2(10f,
_height - (prefixHeight * 2f) - 4f),
Color.White); //
Draw log for (int i = 0;
i < _log.Count; i++) { drawHeight = _height - 34 + (prefixHeight * i) - (prefixHeight * _log.Count) + (_logOffset * prefixHeight); if (drawHeight + prefixHeight
> 0 && drawHeight < _validDisplayHeight * prefixHeight)
{ _spriteBatch.DrawString(_font, _log[i], new Vector2(10f,
drawHeight), Color.Silver); } } _spriteBatch.End(); } base.Draw(gameTime);
}

Lastly, we add our Lua methods to the console class. Most of these are basic helper functions (help() displays a list of available functions, helpcmd() gets you an in-depth description of an individual function, and print() simply reprints the line you entered). The most notable function here is the ToggleComponent() method. This enables or disables whatever component you pass to the function. Within the Lua commands, this is accessed as “Toggle”.

[LuaFunctionAttribute("Toggle", "Turns
a component on or off.", "The
component to toggle on or off.")] public void ToggleComponent(DrawableGameComponent
component) { component.Enabled = !component.Enabled;
component.Visible = !component.Visible;
}

This constitutes all of the major changes to the sample. Now on to the fun part! Let’s use our magic!

Run the program. You should see the FPS component displayed in the bottom left hand corner. Press the tilde (~) key to open up the console. Type “help()” to get a list of available commands if you wish. Enter the following commands into the console:

fps = GetFPS()
Toggle(fps)

At this point, you should see the FPS component disappear. If you want to re-enable it, re-enter the “Toggle(fps)” command.

I hope this gives you a start in easily adding Lua into your XNA programs and gives you an easy interface into accessing the Lua VM!

Cheers!

Devan Stormont

Lua .NET Interface

Your DisplayName here! — Sun, 09 Mar 2008 02:37:17 GMT

A few years ago, I came across this excellent article, written by Martin Echenique and hosted on GameDev.net. It discusses integrating Lua scripting into .NET projects by assigning custom attributes. Using reflection, these custom attributes can be examined at run-time, allowing Lua functions to be loaded into the virtual machine dynamically.

I have taken Matin's project and modified it somewhat. First, I added the capability to sub-class Lua packages, allowing packages to contain other packages.

Second, I have made the Lua virtual machine (VM) non-static. This was done for two reasons.

First, I was having issues with exceptions being thrown due to reloading objects multiple times into the VM. This is caused by trying to register any functions/packages with a name that has already been registered. This is still an outstanding issue to be corrected in a future version, but is avoidable if you only load the functions/packages when you create the VM, then destroy the VM when you are finished with it, so it gets re-built the next time you run it. Not the most elegant solution, but it has served my needs so far and I haven't gotten around to fixing this yet.

The second reason is that by creating separate virtual machines, you can restrict different security access in your Lua functions. For instance, you can have a public Lua VM that is available to end users of your game/application to modify interfaces or generate batch scripts. In addition, you could have a separate administrator VM that allows an admin to make network-wide changes to everyone's application, or to provide game masters with the ability to change change events, spawn new creatures, and fix bugged characters at run-time in your MMORPG.

These libraries are required to build the revised LuaNetInterface (LNI) project and must be locally available to any projects that use LNI. They do not need to be referenced by any libraries other than LNI itself, but they do need to be copied into your executable's local directory.

LuaLibraries_1.0.0.zip (652.09 KB)

These libraries come from the official Lua and LuaNet releases at http://luabinaries.luaforge.net/ and http://luaforge.net/projects/luainterface, respectively.

Here is the code for the revised LuaNetInterface project. Reference luaXX.dll and LuaInterface.dll from the previous .zip into your build.

LuaNetInterface_0.1.0.zip (11.64 KB)

Cheers!

Devan Stormont

--

[UPDATE] The files for this project have been added to Codeplex. They can be accessed here: http://www.codeplex.com/luanetinterface/. Future revisions to the project can be found there.

Blog Launch, Take Three

Your DisplayName here! — Sat, 08 Mar 2008 22:20:44 GMT

Well, here we go again.

I suppose I ought to introduce myself. My name is Devan Stormont and I am a firmware engineer and a game developer/hobbyist. This blog is intended to be primarily a source for me to discuss new developments in Microsoft's XNA game development framework for Windows and the XBOX 360, as well as to post tutorials as time permits.

Hopefully, I won't forget my pasword again!

Cheers!

Devan Stormont