Cleaning up singleton resources is something larger ignored by most discussions of the singleton method. Here's a quick, easy, and maintainable solution to preventing those nasty memory/resource leaks in C++.
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
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
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
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
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
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
(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 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
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.
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.
|