Kyle Schouviller

It’s been a while since my last post – October was ridiculously full of midterms, assignments, etc. I haven’t just been sitting around though, I’ve pretty much made it to version 0.2 of the engine! Here’s what I’ve done:

The entire input namespace has been updated to version 0.2 (minus a mouse component), and I’ve almost finished removing the 0.1 artifacts. The new input manager supports WasPressed along with IsPressed, and brings the ability to set up named key mappings. For example, you can now just check if IsPressed(“Attack”), without having to worry about what button attack is mapped to.

I’ve also been working on cleaning up some of our vector problems. Namely, when changing the velocity of a movement component, you couldn’t just say Movement.Velocity.X = 5; – that would produce a compile error, since you are using the get accessor for the Velocity vector instead of accessing it directly. I solved this by creating a Vector2 handle which allows you to access and change X and Y as if it were a variable. Unfortunately, since C# doesn’t have operator=, you can’t directly set the handle equal to a vector. Oh well…

I’ve also added text! We a text component in version 0.1, but the engine didn’t really have the kind of support we needed for text at that time, so it was very slow at changing text. Now the engine is very capable of displaying text. It loads a font from an xml file creating using BMFontGen.  Then, changing the Text string on the component will update the shape coordinates list in a visual component, mapping letters to shape coordinates.  These can be manipulated in exactly the same way as other visual components, allowing scaling, rotation, etc.

The engine is coming along nicely.  It’s time to update it for the XNA Framework Beta 2, along with adding sound, and then it’ll be ready for a 0.3 release.

I made a ton of progress in the last week. Along with the Visual Engine mentioned in my last post, I finished the Movement Engine. Considering those were my major goals this week, along with cleaning up the last bits of the engine (which I’m doing tonight/tomorrow), I’d say I’ve made great progress.

I made a major push in the last few days and completely recoded the movement engine. I implemented (then reimplemented, then optimized) a QuadTree and implemented the Separating Axis Theorem for arbitrary convex polygons (defined by a list of vertices). It was a beast to get all of the vectors pointing in the right directions at the right times. It was even worse trying to hunt down errors. I ended up recoding a lot just to fix some problems (and made things more efficient in the process).

For example, at one point everything was bouncing as if I were using simple axis-aligned bounding boxes. I wasn’t, so it was kind of confusing. After hunting around the collision detection code for a while (tons of breakpoints >.<) I still couldn’t find it. I took a bit of a break and came back to it later, where I found out that some of the optimizations I had performed ended up biting me.

When I check for collisions, I only check objects that have moved. I take that list of objects and query the Quadtree. I’ve slightly optimized the Quadtree query so it’ll only return objects where the object’s bounding box intersects (or is contained within) the query rectangle. To make a long story short, my collision detection was always returning true, but the Quadtree query was working fine – so it looked like bounding box collisions. To make a long story short, I fixed it and it works great! Off to entity management!

I’m part of a University team working with XNA and building a 2D engine around it to support projects in a course. It’s been a lot of work, but it’s also been pretty interesting. XNA is pretty much Managed DirectX redesigned for C#. This includes garbage collection, automatic references and all of the rest of the features of C#. Along with the language move, XNA removes a ton of the annoyances of working with Manged DirectX. Having worked a little bit with MDX in the last couple of years, I definitely am liking XNA.

Over the last week I’ve been considering moving to 3D-based rendering (along with many other engine cleanup tasks). The easy method of 2D rendering in XNA is to use a SpriteBatch. Once you’ve loaded your texture (which is a single line of code), the code to render it looks like this:

spriteBatch.Begin(SpriteBlendMode.AlphaBlend);
spriteBatch.Draw(myTexture, new Rectangle(spriteX, spriteY, 50, 50), Color.White);
spriteBatch.End();

You basically tell it what texture to render and where (even specifying tint), and it draws it. This is great, and you could probably make tons of 2D games using it. However, having dipped my feet in the world of 3D a couple semesters ago (CptS 442), I’ve seen the power of transformations, and wished to harness it for my engine. As it turns out, linear algebra was actually one of the most useful math courses here. It took a lot of work, but I’m now convinced that moving to 3D was a great idea.

Behind the interface of a visual component (how our visual information is stored) is a set of vertices with corresponding texture coordinates, a scale transformation and a translation. When the visual manager goes to draw everything for the frame, it sorts visual components by texture, then loads the first texture into memory. It places each object by multiplying the matrices together:

DrawTransformation = Scale * Translation * View * Projection;

Best of all, since every visual component using the same texture is drawn in a batch, there are only as many draw calls to the gpu as there are textures! Depth is even handled by the depth-buffer (I’ve specified a depth value for visual components that roughly cooresponds to a Z-value).

Now, if I want to add a rotation to an object, or perhaps even add a world translation (similar to camera position – useful for side-scrollers), all I have to do is add another tranformation matrix to the positioning call. Sure, I could have just used the SpriteBatch and done most of this that way, but using 3D allows me to use lighting and other 3D-effects if I want to in the future.

Finally, the way I’ve set up my View and Project matrices, world coordinates translate almost directly to screen coordinates (i.e. pixels). By default, placing an object at (20,20) will place it 20 pixels from the left and top of the drawing window. This makes it extremely easy when programming a game to make sure things are placed correctly.

I’m not sure if the other engines do this or allow it, but I think it’s much better than just blitting to the screen, and you should at least consider looking into transformations on your points if you plan to make anything other than a static-screen game.