Enigmatic Fish

Getting True Keyboard Input into your XNA Games

2011-08-29T14:59:00.000-07:00

One of the things that PC games often need is a form of in-game keyboard text input. In my case, I needed a login screen that allows the user to type in their username and password before the game continues on. The process turns out to be more complicated than I would have wished it to be in XNA, so I post my solution here in hopes that it may help others with a similar need.

The first solution that comes to mind is to use the KeyboardState.GetPressedKeys() method to get all the keys currently pressed on the keyboard. Running this each frame will, in theory, enable us to get all the keys the player pressed, right? While this seems simple enough, this method will not work for several reasons. Firstly, GetPressedKeys() is not buffered, meaning if you type keys faster than the update rate of your game you will get missing keys. In simple terms, a user typing faster than 60wpm (if your game runs at 60fps) will have issues. Another issue it that the return array does not give any indication of the order in which the keys were pressed, so that gives you no idea on how to construct the final string if two or more keys were pressed simultaneously. The biggest problem is that you have to do all the key to char translation yourself. GetPressedKeys does not return a nice char or string array that contains the actual value you typed. No, it returns an array of the Keys enumeration. This forces the programmer to either build a huge Dictionary that maps each Key to a character value, or build a huge switch(Keys) statement that checks through some 50+ odd cases and handles each one. But even with all this work this method will not function, because Keys does not differentiate between case, meaning you have to handle additional translation if you want the character to be lowercase. Add that to the fact that the Shift key combinations (e.g. Shift+1 = !) and localization are not supported leaves you in some seriously rough waters.

That method being wrought with issues, we have to look for another method to resolve the problem. The next logical solution is to hook into the KeyDown, KeyPress, and KeyUp events on the XNA form. Alas, this too is filled with issues. For one, the XNA form will never get the KeyDown or KeyPress events. It appears that the form eats them up before you can use them. The other issue is that the KeyUp event passes a Keys enum...which gives us the same translation and localization problems as using the KeyboardState.GetPressedKeys() method.

So...where can we go from here? After doing some research I heard mention of the IMessageFilter interface. This interface allows messages to be intercepted before they are dispatched to the form, meaning we can grab the KeyDown and KeyPressed messages before the form devours them. Better yet, the messages are not transformed into the Keys enum, thus we can get the true translated key (WM_CHAR) that the user pressed as a character.

There is another alternative that involves creating a low level keyboard hook using SetWindowsHookEx and grabbing the key events from there, but that involves more pInvoked native calls and more complexity in general then the solution I came up with.

The solution I ended up using involves a bit of unsafe code and a pInvoked call to the user32.dll function TranslateMessage. I would have preferred to avoid native or unsafe calls, but I couldn't get anything to work without them. The basic rundown is this: there is a classes called KeyFilter that inherits from the IMessageFilter interface. This class watches for two Window Message Code's. The first, 0x0100, is a key event. If the message has this ID we use the Marshal class to grab us some unmanaged memory, store the message in a pointer, and pass the message to the unmanaged TranslateMessage function. This function will translate the message into the true character that was pressed and post the 0x0102 (WM_CHAR) message to the form's message queue. The WM_CHAR message happens to be the second message that KeyFilter looks for. Stored in this message's WParam is the transformed char we have been wanting all along! All that needs done is to convert the thing from a unsigned to a char with a simple cast and we can use it!

So that is basically the process necessary to get true Keyboard input into your XNA game. All that needs done now is to set up some events in a class that will fire when a new character is inbound. I wrote a sample that goes along with this post. You can find it here.

Getting Direct Access to the Depth Buffer in DirectX 10

2011-05-20T12:53:00.000-07:00

There was a comment on The Sphere blog recently that requested a sample be made on how to get direct access to the depth buffer in DirectX 10. So I figured I would slap together a sample that attempts to show how the basic setup is done. For anyone who has used DirectX before, you know that the 'basic setup' isn't really all that basic or trivial. So to attempt to keep the sample a bit more clean, I leveraged SDL to do all the window work and event looping stuff. It wasn't quite as easy as using SDL with OpenGL, but it was still tons more easier than using Win32 directly. The sample is filled with bunches of comments, so I'm not going to reiterate then here. Instead you can just go download the sample and check it out.

Note that the solution was built this using Visual Studio 2010 and the June 2010 DirectX SDK. If you don't have the June 2010 SDK this sample won't be able to link in all the necessary libraries.

A new dev blog

2011-03-19T13:42:00.000-07:00

A friend of mine and I are working on our first 3D game using DirectX. It's a simple platformer/puzzler where you play a sphere and try to beat the levels as quickly as possible, kinda like Marble Blast Ultra. We have a dev blog over at http://bitwisegames.wordpress.com/. Check it out sometime!

Understanding the XNA LoadContent/UnloadContent Paradigm

2011-03-16T11:23:00.000-07:00

An alternative title to this could be "Prefer separating the loading of graphical content (Textures, Vertex Buffers, Render Targets) from the loading of non graphical content." The reason for this is not immediately obvious to beginners (or even those intermediate with XNA) but the purpose becomes clear when the possibility of a reset graphics device comes into the picture (when developing for the PC for example.) If you don't do proper cleanup when a reset is triggered, the data will remain inside the graphics device and will build up with each reset. If this happens enough times the graphics card will run out of memory and your application will throw an OutOfVideoMemory exception.

It doesn't take all that much to trigger a reset either. On PC games it is typical to provide the user with an option to set the resolution of the game. Guess what? If you change the resolution you effectively trigger a graphics device reset! This explains why some games take a long time to apply the resolution change; they have to unload everything from the graphics device, and then load it all back in! This is also why some games force you to restart the game in order for the option to be applied, as it is easier to force the user to take some action than to retrofit their engine design to get all the loading and unloading internals correct.

But what if you don't want the user to have to exit and then restart the game? Perhaps you are one of them fancy-pants people and you want the resolution change to be applied in-game. This is easily possible IF you design your game from the get-go to expect this sort of behavior. Basically, follow the rule above. If you need to load some sort of graphical content, don't do it in the constructor. Instead, place it in the LoadContent() method if you are using the GameComponent structure. Make sure to also override the UnloadContent() method. This is where you will call Dispose() on all the content you loaded in LoadContent. Now here is what will happen. If a graphics device reset occurs, XNA will call all your UnloadContent methods (which frees all the data from the graphics device.) It will then call all the LoadContent methods to load all the graphics material back into the graphics device. Since everything has been unloaded, the stray data won't be hanging around on the device and you won't have to worry about that nasty OutOfVideoMemory exception! Effectively handling device resets also brings your game closer to the PC realm of things, as that is one of the mainstay worries you need to keep in mind when developing for the PC.

Happy coding!

Didgery is Live on XBOX LIVE!

2010-09-22T07:58:00.000-07:00

YES!
After a year of work, I am proud to announce that Didgery has been released onto XBOX LIVE Indie.
Download Didgery onto your XBox now!
What is Didgery?

Watch our release trailer below:

Didgery has a dev-blog folks

2010-07-21T11:30:00.000-07:00

That's right, you can now stalk my progress over at www.didgerycardgame.com/DevBlog

Sniping's a good job mate

2010-07-14T19:04:00.000-07:00

YES! I just uncovered a severe bug that has been haunting me ever since I took a vacation about a month ago! It appears the code that detects row/col chains was broken when applied under a certain scenario. Now all I have to do is fix the thing! Thank the Lord for random-chanced bug discovering.

Didgery

2010-07-13T17:40:00.000-07:00

Ahhh yes…

Didgery is a game I have been working on for quite some time now. It’s the game I started right after I put Nut Harvest 360 on hold. I’ve put a lot of effort and design into the thing, and, personally, I think it shows. It’s a card/puzzler game slated to be released sometime in August for the Xbox 360. It was coded using C# and Microsoft’s excellent XNA framework.

I think this is going to be the last puzzle game I make in a while… I used to think that puzzle games would be the easiest things to make... You know, how hard could they be? You don’t necessarily need parallaxing layers, or physics, or tile maps, or editors or any of that fun. I now humbly completely disagree with my former self. Puzzlers have their own nightmarish little nuances. They are tied so heavily to logic and rules that programming it can become a nightmare if you aren’t careful. And bugs…ohhh, the bugs… That’s the worst part. I’ve had bugs in platforming games I’ve made and such, but they are relatively easy to spot, and generally not too hard to fix. The same thing can’t necessarily be said about puzzle games. The logic is tied so closely together that pulling one string to fix a bug may inadvertently cause the whole system to trip over itself in ways you couldn’t possibly comprehend.

I know why Bejeweled Twist took four years to make now…and that was made by PopCap, the king of all things puzzle.

Oh well, it’s almost over now. I’m on the downward slope of adding in bits and pieces and hunting down bugs.

Here is Didgery’s website. Have fun!

Ragnarok Tutorial 3 - Creating Custom Components

2010-06-20T12:35:00.000-07:00

Ragnarok is an engine that attempts to be as flexible as possible. It tries to allow creation of any type of 2D game, weather it be top-down, tile-based, or any other type of 2D format.

In this tutorial we will examine how to create custom components and add them to the world. Custom components can be used to interface more directly with the engine and are used as the basic building blocks in the creation of our game.

This tutorial is more in-depth and involved than previous tutorials, thus I will not be duplicating the source here. To read the tutorial, please download the .zip or .tar

Feel free to post any questions in the comments section.

What!? A new video game?!?

2010-06-09T23:56:00.000-07:00

Ok, I've been hiding secrets :)

A friend and I have been working away on an intense (-ly difficult?) 2D platformer that centers around the Ragnarok Engine. It all started when my buddy played an assignment I made for class. He enjoyed the simple level so much that he was willing to learn the tilemap structure that generated the levels. He started messing around with the text files, and before we knew it we were pumping out new levels. He also did some sweet redesigns to the sprites!

Anyway, I am proud to announce the Demo Version of Platforming Block, powered by the Ragnarok Engine. Why just a demo? Well, let's just say that Platforming Block may have a place with XNA and the Xbox 360 in the near future *wink.

Go ahead, download the game HERE. It also acts as a mighty nice tutorial into the realms of Ragnarok.

Oh yeah, we also have a FaceBook page specifically made to keep you updated.

Ragnarok Engine: Tutorial 2 - Adding objects to the Engine

2010-06-09T23:25:00.000-07:00

It is extremely simple to add objects to the world in Ragnarok. All you have to do is create the object and call add_obj from the Ragnarok engine instance. Below follows a more in-depth example:

A Sprite is essentially a container object for an image that allows us to manipulate properties of it extremely easily. Let's start by creating the object.
sprite = R.Sprite()

Since we are adding only one object to the world, the update and draw orders don't carry much significance as of yet. But if we were to add more than one object, these values would be responsible for controlling the order in which the object updates and draws in relation to other objects.
sprite.update_order = 0
sprite.draw_order = 0

Now we assign an image to the sprite by going to the Ragnarok Engine folder and pulling out its logo image.
sprite.load_texture("Ragnarok//Ragnarok.jpg")

Now, remember in the previous tutorial how we said that the World is the entity responsible for
managing our objects for us? Well, the last step to get this object onscreen is to
add it to the world so it can be drawn and updated.
world.add_obj(sprite)

Boom! That's all it takes to get an sprite on the screen. You can play around with the sprite's coords, scale, and rotation properties to change the orientation of the sprite accordingly.
engine.run()

Download the source for this tutorial here.
Linux user? Download the gzipped tar here.

Ragnarok Engine: Tutorial 1 - Initing the Engine

2010-06-09T14:15:00.000-07:00

What is an engine without a few tutorials to get user's jumpstarted?

This tutorial will cover the basics necessary to get the Ragnarok Engine up and running.

The first step is to import our Ragnarok engine for use.
The 'as R' clause here acts as a alias for Ragnarok, meaning we can access its
members by typing R instead of Ragnarok.
import Ragnarok as R

This single line of code is all it takes to actually initalize the engine.
We are telling Ragnarok that we want to create a window of size 640 by 480,
and that it should bear the title "RAGNAROK TUTORIAL 1".
Notice how we are making use of the Vector2 class to pass in the window size.
engine = R.Ragnarok(R.Vector2(640, 480), "RAGNAROK TUTORIAL 1")

One of Ragnarok's goals is to reduce micro management in your code. It does this by automatically
updating and drawing your objects for you. You can control the draw and update order by changing an
object's update_order and draw_order properties. A low number will draw/update first, while a higher number will draw/update overtop the lower numbers. The world is the entity within the engine that does all this work for us. We grab an instance of it here for easier access.
world = engine.get_world()

The world's clear_color property defines what color the backbuffer should be
erased to after each draw operation.
world.clear_color = (0, 0, 0)

That's it! All we have to do now is tell Ragnarok to begin spinning its game loop.
engine.run()

At this point you should be presented with a blank screen. Don't worry though, Ragnarok can do much more than this!

Check back in for Tutorial 2 to see how to add sprites and other entities to the world.

You can download the source for this tutorial here.
Linux user? Download the gzipped tar here.

Ragnarok Engine

2010-06-09T11:50:00.000-07:00

Today I would like to announce the first release of the Ragnarok Engine for Python/Pygame.

Ragnarok is a 2D engine built on top of Pygame to make game creation easier. While Pygame is a library, Ragnarok attempts to assume the role of an engine, featuring many capabilities that would take a lot of work to create from the ground up in Pygame.

The engine is built in such a way that it attempts to be used under any scenario and game environment (i.e. it is generic). It is easy to set up, maintain, and extend for your particular needs.

A few of the features Ragnarok has to offer:

+2D and 3D Math Library

+Sprites for easy rotation, scaling, texture loading, etc.

+SpriteSheet and Animation classes

+Text objects that can be rotated, scaled, and translated

+A customizable 2D Camera

+A managed World system that updates, draws, and automatically offsets objects by the camera's

translation.

+Collision System

+Input Handling Systems

+Particle Systems

+Pool class for efficiently reusing objects

+TileMaps

Ragnarok is still a work in progress, thus there will be bugs present. Feel free to respond to this post with any bugs you find.

Ragnarok is licensed under the GNU LESSER GENERAL PUBLIC LICENSE v3.0

Download the engine here.
Running on Linux? Download the tar here.

Sharing methods across HLSL files

2010-06-05T12:47:00.000-07:00

I have been working on a lot of HLSL shaders recently, and the more I work on them the more I come to the realization of how often I am copying and pasting methods from one shader to another. This is really an inefficient way to be doing things, so I decided today to begin using the #include directive.

Here is how I do.

Create a plain text file to hold all our shared methods. (Don't use a .fx file because it will expect you to declare a technique for it, which will cause issues if you have a technique with the same name in the shader you are including the file into.)
At the top of the shader that needs to use the method, use the #include “filename.txt” preprocessor directive to load in our methods.
Call the method just like you normally would.
Yay, you are done!

Here is an example of the extensions file:

Filename: Extensions.txt

//Billboard vertices so that they always face the camera.

float3 Billboard(float3 pos, float3 billboardCenter, float3 CameraPos, float3 CamUp)

{

//Find the vector from the camera to the center of the billboard.

float3 eyeVector = billboardCenter - CameraPos;

//Calculate the side vector of the billboard.

float3 sideVector = cross(eyeVector, CamUp);

sideVector = normalize(sideVector);

//Calculate the up vector of the billboard.

float3 upVector = cross(sideVector, eyeVector);

upVector = normalize(upVector);

//Apply the side and up vectors to the location of the vertex

//to make it always face the camera.

float3 finalPos = billboardCenter;

finalPos += (billboardCenter.x - pos.x) * sideVector;

finalPos += (pos.y - billboardCenter.y) * upVector;

return finalPos;

}

Here is the example of our calling code:

Lotus Games

6/5/2010

Causes quads to always face the camera.

*/

#include "Extensions.txt"

sampler Tex;

float4x4 WorldViewProj : WorldViewProjectionMatrix;

float3 CameraPos;

float3 CamUp;

struct VertexData

{

float3 coords : POSITION0;

float3 centerCoords: POSITION1;

float4 uvCoords : TEXCOORD0;

};

struct PixelData

{

float4 coords: POSITION0;

float4 uvCoords : TEXCOORD0;

};

PixelData VS(VertexData vIn)

{
vIn.coords = Billboard(vIn.coords, vIn.centerCoords, CameraPos, CamUp);

PixelData psOut = (PixelData)0;

psOut.coords = float4(vIn.coords, 1);

psOut.uvCoords = vIn.uvCoords;

return psOut;

}

float4 PS(PixelData pIn) : COLOR0

{

return tex2D(Tex, pIn.uvCoords);

}

technique Billboard

{

pass p0

{

VertexShader = compile vs_3_0 VS();

PixelShader = compile ps_3_0 PS();

}

Everything works wonderfully, and allows you to write duplicate code no more :)

XNA4.0, The changes that will get ya...

2010-03-27T10:17:00.000-07:00

I’ve been messing around with XNA4.0 a little bit as of late, and man, there are a lot of changes! Just to insinuate how many changes there actually are, I tried porting a game over to 4.0 the other day and had well over 1000 errors! Below is a list of some of the changes I have readily noticed, and some code you can use in its place when porting a 3.1 game to 4:

XACT will not work with the Win7 phones. You’ll have to use the SoundEffect instance class instead.

No more Color.TransparentWhite or Color.TransparentBlack. Only Color.Transparent, which is the same as transparent black.

You can no longer create a Color by specifying a color and alpha value: i.e. new Color(Color.Red, 155) will fail. You must use, new Color(255, 0, 0, 155) instead, or Color.Red * 155. The syntax for Color most likely changed because of the move to premultiplied alpha as the standard alpha blending equation. This essentially means that if you want to set the alpha component of a color, you must multiply the desired alpha by the components rather than setting its color.A component, else your colors will end up looking much washed out.

Parameter reordering in SpriteBatch.Begin().

SpriteBlendMode enumeration replaced with BlendState.

Changes in the VertexElement parameter list. It appears to be much simpler now. Stream specification was removed, as was the VertexElementMethod enumeration.

Removed the texture index value from GraphicsDevice.SetRenderTarget. So instead of GraphicsDevice.SetRenderTarget(0, target), it is now GraphicsDevice.SetRenderTarget(target)

DynamicVertexBuffer’s parameters changed. It now accepts a VertexDeclaration and number of vertices to create (instead of bytes).

Reordering of IndexBuffer parameters. IndexElementSize was moved from the end of the parameter list to right after the graphics device.

Begin() and End() on Effect passes have been replaced with Apply()
Game.GraphicsDevice.Vertices[0].SetSource(vertexBuffer, offset, vertexSize); has been replaced with Game.GraphicsDevice.SetVertexBuffer(vertexBuffer);

Simplified basic constructor in RenderTarget2D. A target can now be created with (GraphicsDevice, Width, Height) instead of (GraphicsDevice, Width, Height, MipLevels, SurfaceFormat), though the latter option is still there for use.

The parameters of the VertexDeclaration class simplified from (GraphicsDevice, VertexElements) to (VertexElements)

GraphicsDevice.RenderState is removed. The states are now occupied in various locations under GraphicsDevice. Stencil settings, for example, can be found under GraphicsDevice.DepthStencilState.

RenderTargets now act just like a Texture. You can call spriteBatch.Draw(renderTarget…) rather than spriteBatch.Draw(renderTarget.GetTexture()…)

Those are most of the changes that really got me in terms of error count, but I think the changes are all well considered. The API, you will notice, has been compressed and feels more intuitive and streamlined. It would be however, much easier to develop a game from the ground-up on 4.0 than try to transfer it over from 3.1. So if you are currently working on a 3.1 game, I suggest you attempt to get it completed before XNA4 becomes the standard, else you may have to traverse rough waters to port it over.

I'm a twitface!

2010-03-08T22:28:00.000-08:00

The title says it all folks. Follow me at:
http://twitter.com/LotusGames

Nut Harvest 360

2010-02-11T14:15:00.000-08:00

I thought I might as well show some of the stuff I've been working on. Below is a very short video of my work-in progress game, Nut Harvest 360. Enjoy!

Cryptic Error Messages on Stencil Buffer Clear

2010-02-06T11:23:00.000-08:00

It has been a looong time since I lasted posted… Working on my game, school, and a newly acquired job have been eating away at my time. Anyway, I thought I would post something short and simple, but hopefully helpful.

The C# compiler is usually good about giving you detailed information on compiler/runtime errors, but there are those occasional times in which it gives you some really cryptic response that doesn’t help you in the least. I ran into one of those today when attempting to clear my stencil buffer. It crashed on this line:

Game.GraphicsDevice.Clear(ClearOptions.Stencil, Color.Black, 0, 0);

With the ever-so helpful error message: “An unexpected error has occurred.”

Well great, that tells me everything I need to know to fix the problem! (Extreme sarcasm intended)

After messing around for a bit I found that my problem lay in the fact that I hadn’t created my stencil buffer at startup! So if you are running into this problem, add this code to your Game1 constructor:

graphics.PreferredDepthStencilFormat = DepthFormat.Depth24Stencil8Single;

That will make sure you have a stencil buffer ready to use, and thus the cryptic error message should go away.

Detecting if a Graphics Card supports IndexElementSize.ThirtyTwoBits

2009-10-19T01:59:00.000-07:00

I ran into a little problem with my Particle system when trying to make it function elequently on different PC’s, I didn’t know how to get some necessary Graphics Device information! What I needed was critical to making sure the engine didn’t crash on lower-spec PCs (pretty much anything with an Intel integrated graphics chip.) The IndexElementSize determines the maximum number of indices you can send to the graphics card in one batch. If the graphics card supports 32 bits (ints) (like the Xbox 360 or most modern graphics chips), than you can use 2^32 indices (a very huge number), which means you can draw your gigantic landscape or thousands of particles with no worry. If the system only supports 16bits (shorts), however, you only get about 32,000 indices, a sad fact that will throw a critical error if you don’t handle it right.

The soultion?

bool doesSupport32Bit = false;

if (Game.GraphicsDevice.GraphicsDeviceCapabilities.MaxVertexIndex > ushort.MaxValue)

doesSupport32Bit = true;

If the return value of MaxVertexIndex is greater than the maximum value describable by a unsigned short (an unsigned number is a value that can have no negative representation), than it must support 32 bit indices. If it doesn’t, than you should accomidate the user by using an index buffer that takes the IndexElementSize.SixteenBits flag instead of the ThirtyTwoBits flag. This will ensure (or at least help) your game run on a larger variety of hardware, thus increasing your potential audience.

Yet Another XACT Bug

2009-10-08T23:00:00.000-07:00

I strongly dislike it when I encounter a bug, assume its mine own, and then go on a wild goose chase after it, only to eventually realize the bug is in the software I'm using sometime later.

Here's the bug:
When playing extremely short duration sounds through XACT on the Xbox 360, XACT will fail to set the IsPlaying property to false when the sound has completed, meaning the system continues to execute the sound even after it has completed. If many small sounds are played in succession (such as my newest still-in-progress-game does) the game will begin to hitch, exhibit audio glitches, and eventually freeze. This problem affects only the 360; the PC can handle small sounds without a problem. The duration in question are sounds that are .007 seconds or less long. I can confirm that sounds with a duration of at least .01 are handled properly by XACT.

On a side note, I got my 360 back today! MS gave me a replacement console, a letter of apology, and a free month of live! Plus the repair was free, despite their web site saying my warranty had expired! I am extremely satisfied with their support. In fact, I probably haven't ever been this satisfied with any kind of service center support in my life. Most of the time it is a pain. This was actually very smooth and well executed, exactly the way things should be. I wish Ford would be like this and replace my faulty transmission in my '03 Taurus (they have a track record for breaking, much like the 360 has a record for the Red Rings.)

Red Rings of Death

2009-09-17T20:26:00.000-07:00

I just fired up my 360 to test my game, got some artifacts while playing, freaked out, and turned the 360 off. Turned it back on moments later to see the dreaded red rings blinking dumbly in my face. This is a huge stumbling block...I was counting on this game to bring me in some much needed revenue...and now it looks like that is impossible.

Oh boy, another mountain to climb. Let's hope I can rake up enough cash to get the 360 repaired.

Bizarre XACT Freezing Problem – And how to work around it.

2009-09-17T19:34:00.000-07:00

I’ve been having a problem recently when trying to build my newest game for the 360 (details on the game in a week or so.) The build would get to the XACT 3.0 portion, at which point the build would promptly freeze – for those who don’t know, XACT is the utility used to author sounds for a game. Visual Studio became unresponsive, and the only way to exit the hopeless build was to either kill the XactBld3.exe process, which would cause the build to finish with the side effect of having no sounds, or to kill Visual Studio, which, obviously, kills everything. I found it strange that the problem was only occurring when the 360 build was enabled, so I opened up the XACT Authoring tool and attempted to find out what was wrong. I did. Answer: xWMA. When this format is enabled for BOTH the PC and Xbox, the build will NOT finish, at least in a reasonable time. I left it running for about 30mins with no luck. I don’t know about any other developers out there, but a 30min waiting time is not reasonable (note that I only had about five short sounds and one 30 second music clip building, so it wasn’t a huge amass of sounds that was halting the build.) I found, however, that if I changed xWMA on either the PC or Xbox to some other format (XMA or ADPCM respectively) that the build would work fine. Note that I only had to change the format for one of the systems, not both, to get everything working.

This definitely seems like a bug to me...

In short, if your XNA Game build is freezing, and you are using XACT, change the format settings from xWMA to XMA and everything should work fine.

Game Development & Writing: The Similarities

2009-09-07T13:50:00.000-07:00

I realized today that Video game development holds some similarities with the writing process. When you start to make a game you are presented with this screen:

When you start to write a story you are presented with something like this:

The common similarity between both of these is that they are, well, blank. There is something frightening and somewhat overbearing about this utterly clean slate. The knowledge that it is your duty to turn this utter nothingness into something engaging and worthwhile can easily be overwhelming. Even when we have finally made something it is easy to digress about how absolutely terrible it still is. Whenever you do that, keep this in mind: The first draft of anything sucks, period. The game (or story) is not necessarily going to read or play well your first time though it. So take a break, get yourself a soda, and take a moment to calm yourself down. Once you have the basics in place (i.e. the ‘rough draft’ version of the game) you can comfort yourself with the knowledge that it is going to be an easier process to make it actually look good (but it’s still going to take effort!) Spend some time replacing all those placeholder graphics with something that looks decent (this would be like cleaning up the sentences and making them sound more elegant in terms of writing.) Add in some good sound effects and music (similar to perfecting the atmosphere of a story by word choice and sentence structure) (SoundSnap and Kevin MacLeod are excellent resources for sounds and music respectively.) Remember that this is your first ‘pass’ through the game, so it still isn’t going to be perfect by any means, but it should look much better than the first draft. I find that the sooner the game actually looks good, the sooner I gain confidence in myself, so I tend to try and up the graphics as soon as I have some basic gameplay in place.

I suppose I could go ahead and give an example by using my Nut Harvest 360 game.

Here is what the game looked like while I was putting together the basic gameplay:

Inspiring, huh?

After spending some time on the graphics department it now looks like this:

Which one makes you feel more confident?

Now there’s still much more revising I need to do, but it’s easier now that I know I have at least something decent already in place. Note that it didn’t look like this in one ‘pass’ by any means. There were a lot of revisions and trial and error before it got to this point, but they were well worth it.

The same goes with writing. The first time I write something it is just about as beautiful as a monkey smearing poop on a tree. After the first revision I gain a stronger understanding of what the story is and how it should feel (I also tend to add a lot more material during this time.) The second revision cleans up all the new stuff I added in the first revision. The third draft results in some pretty cool sounding sentences and a stronger atmosphere. From there I can continue to go on and try to perfect all the little nuances of the story. Notice that each draft results in less and less work, meaning you can focus harder on more specific areas. This, again, applies directly to game development. You start out with NOTHING. So you make some crappy graphics and get the core programming of the game relatively completed. After the game functions you can replace those graphics with something good and tweak the code a bit more. Next you may start adding the HLSL effects and improving the graphics and sound, etc.

So, in conclusion, try to realize that, even though the game sucks now, it may not necessarily later. Spend some time in the iterative cycle. Scrutinize your game like a sentence. Improve the big things (graphics and gameplay) first, and then work your way down into the little details. You’ll quickly gain confidence in yourself and have a kick-butt game to boot.

Undocumented Guide.BeginShowMessageBox Limitations

2009-09-02T16:58:00.001-07:00

I came across a problem today while trying to display a message to the end user. For some reason the Guide wasn’t displaying my message! After a bit of messing around I decided to shorten the text I was passing to the Guide. It appears the Guide only supports 256 characters, no more. Normally this should throw you an exception so you could fix it, but I had my code wrapped in a try catch{} block, so I didn’t get the error. This limitation currently isn’t documented (outside of the Exception) so if you’re having trouble getting the Guide to display a message, try trimming the string down to 256 characters or less.

The Mountains of Difficulty

2009-08-28T23:47:00.000-07:00

I’ve realized a development cycle that I tend to go through when working on a game for a period of time. I’ll realize half-way through, “Oh crap, my engine is wholly inadequate for this game!” or “I don’t have the necessary tools to do what I need to do!” or, more commonly, “I don’t have enough experience, it’s taking me way too long!” I think the last statement applies the most heavily. HLSL (High Level Shader Language), for example, was a huge barrier for a long period of time. In fact, I haven’t got somewhat acquainted with it until a few months ago (soon after QuadTrix was released), and I haven’t got decently knowledgeable about it until recently. Once I realize how much time is being reworked in the engine, rather than the game, and learning new material, rather than design, I begin to wonder if I should simply stop work on the current game and deviate totally, bent on creating a simple game in a short span of time. That’s how QuadTrix came about. Before that I was working on an epic puzzler that was beginning to take extraordinarily long. I was working on my engine, trying to piece together an editor (which went very badly), and running low on my bank account (which is now officially empty thanks to DeVry and insufficient Financial Aid,) when one day an overwhelming self-challenge came about me. Why not just start anew on a simple game? Scrap all the time-hoarding stuff and get work on something that can be completed quickly. Well, I did. The results weren’t anything amazing, but for a week and a half of work I was satisfied.

I’ve had much time since then to develop my engine and learn HLSL, but I find the same problems arising. I’m realizing that several parts of my engine either aren’t developed yet or need massive rework. Futhermore, I don’t have the necessary tools to do everything that I need to do (and I don’t have time right now to create them as I am completely broke and in bad need of money.) Sometimes there are situations which just get you in a rut and you can’t get out. The whole story of how I got in such a bad predicament is a post in itself. I may right about it in the nigh-future.

Anyway, I believe it is happening again. I’m beginning to feel that after I implement a couple more systems into my engine that I will break from Nut Harvest 360 to make a much simpler (and hopefully fun) game. Perhaps this will get me some necessary dough to continue living and making more games.

Unpacking a Color from the Color.Packed Property

2009-08-26T12:09:00.000-07:00

The Color.PackedValue property can be a great shorthand way to represent a color. Unfortunately, there is no Color.Unpack() method, so how do we go about getting our original Color?

Bitwise operators of course! I had to mess around for a while before I could finally get the structure down correctly (it appears the color is packed different than the well-know RGBA format, in fact, it seems to be packed as BGRA).

Here is how to go about it:
//First lets pack the color

Color color = new Color(155, 72, 98, 255);

uint packedColor = color.PackedValue;

//Now unpack it to get the original value.

Color unpackedColor = new Color();

unpackedColor.B = (byte)(packedColor);

unpackedColor.G = (byte)(packedColor >> 8);

unpackedColor.R = (byte)(packedColor >> 16);

unpackedColor.A = (byte)(packedColor >> 24);

We use the bit shift operator (>>) to shift the bit representation over by the specified number of bits. Converting it to a byte removes all but the last 8 bits. This allows us to filter out a specific R,G,B, or A component.

Those Sly Little Garbage Collection Issues

2009-08-17T09:54:00.000-07:00

Do you hate garbage? I do, I hate it a lot. There’s nothing more dissatisfying than playing your game and then HITCH, the garbage collector kicks in and takes a big-juicy bite from your framerate. I recently got through doing a major refactoring to my game engine (now it’s actually suited for some platformer action) and became interested in how much garbage was being generated. To find some of the basic stuff causing garbage I created a test scenario that told my game engine to render a lot of stuff at once. After some scrutiny with the XNA Framework Remote Performance Monitor I was able to find (and document) a majority of the garbage-generating sections of my engine. The results were terrifying. 7 Garbage Collections lasting roughly 80 milliseconds were occurring every frame. In other words, a majority of my CPU time was spent simply cleaning up after my engine! Not good. So I got on my classic programmer mind set and began commenting things out until I could hone down into the source of garbage. After I got most of the core code cleaned up I ran my work-in-progress game (Nut Harvest 360) to what else I could find out. A lot of things I discovered surprised me.

Iterating though a Current Technique Passes using foreach generates garbage:

This was a tough one. I had nearly all my code commented out that I thought would cause garbage, but yet the Perf. Monitor told me that boxing was happening somewhere.

So I continued searching (ludicrously commenting out additional statements), until I was left with my Primitive Rendering Class. All it was doing was iterating over an EffectPass collection like so:

foreach (EffectPass pass in PBBasicShader.CurrentTechnique.Passes)

{

Pass.Begin();

Game.GraphicsDevice.VertexDeclaration = this.vertices;

Game.GraphicsDevice.DrawUserPrimitives(type, this.elements, 0, this.NumOfPrimitivesToRender);

Pass.End()

}

Pretty normal eh? So after scratching my head for a second I disabled the body of the code. But there was still boxing! I was getting discouraged at this point. Surely it couldn’t be the foreach could it? A moment of doubt passed. I commented out the foreach and… the boxing problem went away! I never thought that iterating over an EffectPass collection would generate garbage, (I mean, several XNA books I have use this technique) but tests confirmed that it does. After rewriting the above as:

for (int i = 0; i < technique.Passes.Count; ++i)

{

PBBasicShader.CurrentTechnique.Passes[i].Begin();

Game.GraphicsDevice.VertexDeclaration = this.vertices;

Game.GraphicsDevice.DrawUserPrimitives(type, this.elements, 0, this.NumOfPrimitivesToRender);

PBBasicShader.CurrentTechnique.Passes[i].End();

}

The boxing/garbage problem when away! I found the same problem in my ParticleSystem. After I swithced to a regular for instead of a foreach I no longer received boxed value types.

Be very careful when it comes to boxing. (If you don’t know what boxing is take a look here.) Some of the most simple methods that you think don’t box actually do. I dug into my Camera class and found that the statements Vector2.Equals(val, val2) was generating garbage. How could a comparision between two Vector2’s result in garbage?, I thought. Well, I looked at the Equals definition and found that it actually takes a reference of two Objects. The Vector2’s were being boxed into an Object, and then compared, when resulted in garbage, and thus garbage collections. I changed this to the val.Equals(val2) method and removed the boxing problems.

Anytime you use the new keyword you are generating garbage (unless it’s a value type such as an int, struct, etc.) This was my largest problem next to boxing. I had too many methods that were dynmanically creating arrays every time they were called (often every frame.) This was remidied by removing the array from the method and instead have the method accept an array by ref. This puts a bit more work into the calling code (as you specifically have to set up an array in every class that uses the method) but it’s worth it in terms of how much garbage you are saving yourself.

In my InputManager I found that having a list of enumeration types causes boxing each time a value is added.

The problem code was these two lines:

List connectedControllers = new List(MAX_CONTROLLERS);

connectedControllers.Add(PlayerIndex.One);

I don’t really understand why…perhaps the list does some internal operations? I read on Shawn’s blog that using an enum as a key in a Dictionary causes boxing due to internal operations, so perhaps this is something similar. This was remidied by making the List accept ints and casting the PlayerIndex value to an int before storing it into the array.

Solution:

List connectedControllers = new List(MAX_CONTROLLERS);

connectedControllers.Add((int)PlayerIndex.One);

Be very wary of using Linq extensions, as a majority of them box values in a heartbeat. If its possible to make your own method, than it may be best to do so. I was making some heavy use of the Linq function Except (returns an array of all the data in the first set not present in the second set.) I was able to reduce garbage and boxing by creating my own function.

Problem:

IEnumerable set3 = set1.Except(set2);

Solution:

private void SetDifference(List < T > set1 , List < T > set2, ref List setDifference)

{

if (setDifference == null)

return;

setDifference.Clear();

foreach (T obj in set1)

if (!set2.Contains(obj))

setDifference.Add(obj);

}

SetDifference(set1, set2, ref set3);

Here is one that broke my heart: Using the List sort functionality produces garbage! This was (and still is) a baddie for me, as I sort all of my objects each frame multiple times before drawing them (once for their Update Order and once for their Draw Order.) The only way to get around this is to either use an array or to create your own sort method. (Please note that casting your List to an Array to Sort is a very very bad idea, as calling ToArray() or ToList() creates a new array and then returns it, resulting in garbage.

Well there ya go, a few general performance tidbits to keep in mind. I hope they prove useful.

Nut Harvest 360

2009-07-29T13:27:00.000-07:00

A total remake of Nut Harvest is in the works for the Xbox 360! Let me just say that it's going to be awesome (much more awesome than the shoddily controlled PC alternative)! Keep an eye out for screen shots and general performance tid-bits.

Array Copy Performance

2009-07-14T11:33:00.000-07:00

I was recently working on a program ( a cloud Component in XNA to be exact) that was doing a fair amount of copying from one array to another. I became interested half-way through the project as to which was faster, the Array.Copy method, or a simple for loop that iterates through the array and copies each element from one array over to another array. I wanted to squeeze out as much performance as possible, so I created a simple test application that examines the speed of three copying methods. I used Array.Copy(), the for loop method, and the CopyTo() member of an array object. I compiled the results into the table below. All time is in milliseconds, with the lower number being the best. Stopwatch was used to measure time intervals.

For some reason I anticipated that the simpler for loop would have an advantage, but I was very wrong. As you can see, Array.Copy or arrayObj.CopyTo() is the clear choice when you are wanting to copy an array over to another array.

This introduces some further interesting performance considerations. Let’s say you have two arrays (ary1 and ary2) and you want to synchronize ary1 to equal ary2. You have several options. You could use the Clone() method of ary2 (which creates a new Object that then must be unboxed to the type of array you are using), you could use ary2.ToArray()* (which generates a new array and returns it), or you could use ary2.CopyTo(ary1, 0) (which generates no new array and thus should generate no garbage.) Now, keep in mind that the Xbox 360 is extremely fragile when it comes to garbage. Anything that generates a new object will eventually generate garbage. Anything that is boxed and unboxed generates garbage. With this knowledge, it is likely that the Clone method will be slower than the ToArray() method, and the ToArray() method will be much slower than the Array.Copy method. And if you use the Clone() or ToArray() methods in a tight loop, well, let’s just say your performance will die - completely. We need something that doesn’t generate garbage, and that something is the Array.Copy method. The graph below compares performance. (Each operation executed 25 times and times averaged. All times in milliseconds.)

Note that this was all done on the PC, though it’s highly probable these figures carry over to the 360. It’s interesting to note the linear speed improvement as we head toward the Array.Copy() side of things. Array.Copy is twice as fast as ToArray(), and three times faster than the Clone method.

So that pretty much settles it. If you are programming an application that requires the utmost performance (such as a video game) than Array.Copy() is the immediate choice. It’s wise to take a few moments and look though your code for any tight loops where copying operations are occurring. I switched from using ToArray() in my Radix Sort implementation to Array.Copy() and got a grand performance boost.

Thanks for reading.

*Note that System.Linq will have to be included in order for this function to be used.

Design Decisions: The wiles of the Game Component.

2009-06-08T16:41:00.000-07:00

If you’ve used XNA at all you’ve probably already heard of the Game Component. In case you haven’t I’ll provide a brief description: A Game Component is an object that is automatically updated and drawn by the Game class for you. All you have to do is derive an object from the GameComponent or DrawableGameComponet class such as:

Sprite : DrawableGameComponent

{

…code here

}

And make a call to Game.Components.Add (derivedObjectHere) and your good! None of those nasty draw or update calls littering your code. It seems like a good idea at first, but there are a lot of hidden implications to creating a game, or game engine, that is based around the Component paradigm (as I have personally discovered.)

This post is going to examine three major hidden implications of using GameComponents and hopefully give you a better idea of what you’re getting into if you decide to go this route.

The first implication is a shift in control. Let’s say you create a few non game component Sprite objects inside your Game class. In order to draw or update them, you must manually call their draw and update methods. Ok, so what does that have to do with anything? The point is that you have control over the order in which the sprites should Draw or Update. Things are a bit different with Components, as the Draw and Update methods are called automatically by Game. You can achieve a similar effect by adding them to the component list in the same order that you called draw or update on the non component objects. This is OK if you are going to create all your objects in Game, but frequently Level objects are created (which may be a component in and of itself) that store other components. When a structure like this is in place, it becomes much more difficult to get everything to draw in the correct order. To circumvent this problem, Components have a property called DrawOrder and UpdateOrder. A value of 0 means it draws first (which means it draws behind everything else) while a greater value makes it draw later. If I assign 0, 1, and 2 to three different components, the one with a DrawOrder of 0 will draw, followed by 1 and then finally 2.

The second implication is the tendency of GameComponents to affect the design of all objects in your engine or game. What do I mean by that? Imagine this scenario. You have a non-component object that you want to spawn game component sprites at a given interval. You quickly realize, however, that your Sprites require a reference to Game, as do all GameComponents. You do not have direct access to game from a non-component object, leaving you with two options: go against OOP standards and make a static property from which you can access game to create your sprites, or refactor the non-component object into a component object so you have direct access to everything you need. This redesign will be required for every non-component object that you want to create a component object with, and can amount to a very large amount of time refactoring your code.

The third implication is that you are tied to the Game class. This is a biggie, a real biggie. What makes this so huge is that your components will not function if Game isn’t present. When it really bites (and I’m finding out now) is when you try to integrate your components into a WinForms project (such as for a level editor.) This imposes a major hurdle: using the WinForms method (as detailed on the XNA site here) strips out the functionality of the Game class, replacing it with a custom implementation. Ok, so what’s so bad about this? The problem, my friend, lies in the fact that GameComponents must be passed a reference to Game in order to function. So guess what? All that work you just did refactoring all your code into a component amounts to a big pile of nothing. Now you have to do even more refactoring in order to get your engine or game up and running. I’m still working out an elegant solution to this problem, but it was suggested to me via the intellectuals over at the XNA forums to create a custom implementation of a Component by means of inheriting from IGameComponent and IUpdateable. This wouldn’t require a reference to Game (as I would be creating my own object) but it would require me to pass in a ServicesContainer of some sort for every object I create in order to access the data commonly accessed from a regular GameComponent (such as GraphicsDevice, Content Manager, etc.)

Now for my personal thoughts on the matter:

Game Components aren’t all bad. They can really automize and streamline the game development process, but using them requires the framework of your engine to be set up to expect them. Strangely enough, I’ve found that as my engine evolved, the benefits of Game Components became less prevalent, and I’m finding it that I could actually do without them. I now no longer add the components to the Game Class. Instead I have separate layers that each has their own collection of components. Each layer then manually iterates though the collection and calls Draw and Update on each component. The layer also automatically sorts its collection every time a new component is added in order to get the Draw and Update functions to do everything in the correct order. With this said, it is very much a possibility to get a game or engine up and running that doesn’t use components. Doing so frees you up from the Game Class and allows you to easily migrate to WinForms or other custom rendering solutions. It also doesn’t require refactoring existing code into components. If you’re in the middle of developing a large game or comprehensive game engine and are thinking about switching to GameComponents, I implore you to take a moment and think of an alternative method. You’ll save a lot of time and headache this way. If you’re just starting, however, and you really want to take the GameComponent approach, please, please, follow my above request and take a moment to ensure that what you are trying to do can’t be easily accomplished without using GameComponents. If you have a good enough of excuse of why you need it (or you simply wish to ignore me) than take some time in the planning stage to make everything a component from the get go, and most of all, good luck!

Until next time…

2009-05-28T01:20:00.000-07:00

How to make Platformer Grass in GIMP

In this tutorial I’m going to guide you through the steps necessary to create some basic, yet good-looking grass that could fit very well in a platformer game.

The end result of this tutorial should look something like this:

The first thing you need to do is load up GIMP (duh!) GIMP can be found here, though if you don’t want to download it you can follow along in any advanced image editing software of your choice. Note, however, that these steps will not match up perfectly with whatever software you are using.

I’m using GIMP 2.6.6 for this tutorial.

First we need a new layer to work with. Click File->New and then extend the + button beside Advanced Options. Find the Fill With dialog box, and choose Transparency. Leave the image size as the default for now.

This layer will act as our background layer. It will act as the base color for the rest of the image. Let’s go ahead and fill this will a dark green color.

We should now have something that looks like this:

Boring huh? But stay with me, things will get interesting in a minute.

Let’s now begin to add a bit of variance to our base image.

Create a new layer and call it Light Green.

We are now going to make use of the airbrush. This guy is extremely useful for adding subtle details that makes things look a lot better. Remember this if your image looks too flat or uninteresting. A little use of the airbrush with modest opacity settings can do wonders.

Select the airbrush tool and select a brighter green (not too bright.)

Select a fuzzy brush and set the scale of the airbrush to 10. Lower the opacity to around 60 and draw some randomized strokes on the Light Green layer. Hopefully we have something that somewhat resembles this:

It’s starting to get there, but it’s definitely not there yet. What we need now is some extra variance added in.

A little bit of variance is what makes things appear realistic and less deterministic and computer-derived looking. A great way to get this variance is to use a pseudo-random algorithm to generate a texture, and then merge this texture with our base image. This can be used to really liven up an image. It sounds complicated, but trust me, it’s really not.

Let’s go ahead and create a new layer. Call it Cloud. Now to create the computer-generated image we will merge with the one we made. Click Filters->Render->Clouds->Plasma. Change the Turbulence to what you desire and click OK. I used the default settings.

Our image will now look like this:

Now we need to remove all the color from the Cloud image so that it doesn’t affect the color values of our base images when we merge it. Click Colors->Desaturate->Average. Our cloud image should now be in grayscale. It is ready to merge. Change the Cloud Mode to overlay, and set the layers opacity to about 60.

Looking a bit better now. At least we have some variance going on. Let’s add one more element, a linear gradient. Create a new Layer and Name it Linear Gradient. Choose the gradient tool and set the foreground color to black and the background color to white. Place the cursor at the bottom center of the image and hold Control as you move the mouse near the top of the image (This makes it stay in a perfectly straight line.) Release the mouse button.

Change the mode to multiply.

The grass should now look like this:

In my case it’s still a bit too dark, so let’s go lighten it up a bit.

Let’s go to the Background layer and use the airbrush to paint on some brighter greens. Experiment with the brushes to see what looks the best. Here’s what it looks like after lighting things up:

Almost there. Let’s merge the layers into one. Go to Image->Merge Visible Layers and click OK when the dialog appears. We know have a single image. Let’s erase some of the top portion to see if we can get something that looks like grass going on. I used a combination of the Pencil Sketch#2 and Galaxy brushes to achieve this effect:

Not too bad. I can see this being used in a platformer game. Can you?

2009-05-27T23:21:00.000-07:00

FIRSTIES!

Ok, sorry, please forgive me for uttering that overused and deeply irritating phrase. I’m kinda new to this blog business and I’m having a difficult time starting out this introduction (ever had that trouble?)

So yeah, let’s get this thing a rolling. My name is Clinton. I’m a fledging independent game developer with an aim toward the Xbox 360 Community Games Marketplace, though I’ve been throwing the idea around of developing for the iPhone. We’ll see how that goes.

I have released one game so far for the 360 Community Marketplace. It’s a simple puzzler titled QuadTrix. Give it a try if you get the chance. There are probably more than one gameplay flaw mixed into its chemistry, and it lacks that certain element that makes it enjoyable to anyone who plays it, but I’m proud of it nevertheless. I’m just beginning on the long journey of the indie game developer, the one with the forlorn path that twists sinuously through hours of lost sleep and mounds of anxious books stacked in a never ending queue, waiting for their knowledge to be devoured with weary eyes and an unkempt heart, so I’m not too hard on myself – yet. I’m taking it slow, learning what I need to and messing around a bit. The better games are coming baby, they’re coming.

Some additional info:

I made my first game in ninth grade high school (at the age of fourteen) using the RPG Toolkit game engine and its associated scripting language. In 2006 I decided to take my love of programming to a new level when I began my venture with DeVry University, starting out on the path of a Computer Information Systems developer. Midway through that program I decided it best to follow my true aspirations, and thus switched paths to the Game Programming Degree. Since my time at DeVry I have made three games as of the time of this writing. Nut Harvest (created on the Game Maker engine), which can be found here, and Tic-Tac-Toe and QuadTrix, which were both developed on XNA.

I plan to use this blog as a means of posting hopefully helpful tutorials on various subjects relating to programming, video game development, and graphical subjects. I may also occasionally post game reviews.

Thanks for the read.