Quick and Dirty Torque X 2D Optimization Tips: Content Clean-up

Recently, I’ve been working on a small update for Legend of the Rune Lords. This has been a chance to clean up some of the dirty bits of code that I let slide during the original rush to release. In particular, I’ve had a chance to profile a lot of the game and find performance bottlenecks resulting from both my usage of Torque X 2D as well as the engine itself. In this and the next few articles, I plan to share a few tips for improving the performance of your game running on TX2D.

Note that Legend of the Rune Lords was built using the 3.1.0 release of Torque X and I haven’t had a chance to fully evaluate the 3.1.5 release of Torque X yet. Judging from the release notes, the 3.1.5 release is focused on fixing stability issues and joining the 2D and 3D sides of Torque X into one product, so it’s likely that the following tips will still be relevant to the 3.1.5 release.

For our first round of optimizations, I’ll focus on techniques you can use without having to dive into the engine itself. Namely, I’ll share a couple tips on optimizing your content to improve your framerate.

First of all, consider this screenshot from Legend of the Rune Lords:
LotRL Battle Scene

This is a typical battle taking place in the game. While most of the game runs at 60 frames-per-second, the battles only seem to barely be able to squeak out 30 FPS. While there’s a bit more going on here than in other areas of the game, it’s hard to justify such a large performance drop. So, how can we make things better?

#1: Reduce the Number of Textures Used at Once
This is a fix I implemented before the first release of LotRL when I noticed the battle scene framerate stumbling around at about 24-26 FPS.

While they may not look like much, each of those meters under each character is made up of three distinct parts: the meter background, the main colored fill, and a secondary fill that trails after the main fill. The original implementation used a different texture for each part of each meter type (the green HP meter and the blue MP meter.)

This meant that I was using 6 textures to implement 2 different types of meters. Unless TX2D was being clever in sorting its rendering by-material, I was facing a potential 48 (3 textures * 2 meters * 8 creatures) texture switches per frame. Not good.

Since the meter parts were all the same size, it was trivial to pack all the meter graphics into one texture and re-import them into TX2D as a cell-divided material. After pointing the meter templates to the new joint texture, I rebuilt the data and ran it on my Xbox and… Presto! The framerate went from 24-26 FPS to floating around 30 FPS (unless I went and spawned a bunch of particles by casting a spell.) Good enough for an initial release, but still a long cry from the 60 FPS of my dreams.

#2: Get Rid of Unused Physics and Collision Components
To get more detail on where my performance was going, I started using Torque X’s integrated Profiler. It’s a simple bit of code reminiscent of the in-code profiler featured in one of the early Game Programming Gems books. It isn’t enabled in 360 builds by default, but this is quickly remedied by adding the TORQUE_PROFILE symbol to the 360 build projects and fixing a few minor compilation errors. You may also need to change the commands for triggering the profiler since it defaults to F1 and F2 which aren’t present on a 360 thumb keyboard.

Upon using the profiler, I noticed that I was spending almost 1 ms each frame on updating physics objects. This wasn’t the biggest performance drain (drawing the tiled background and animated characters ate up a lot more time, but I’ll get to what I did about those later), but it did seem like a waste considering that LotRL uses a turn-based combat system which has no need for traditional physics or collision checking.

The source of the problem was easy to figure out and the remedy just as easy to implement: I just went to my most commonly used templates in data and removed the T2DPhysicsComponents and T2DCollisionComponents from them. The result was a physics update taking less than a eighth of its pre-optimization time.

This one was so obvious that I was almost embarrassed that I hadn’t noticed it earlier. Had I been more careful when first creating many of my assets, I could have made sure to get rid of the T2DPhysicsComponents and T2DCollisionComponents that I was never going to use. Of course, considering that these components are added by default when you create new objects in the editor, it is pretty easy to miss them.

That wraps up my content-only quick-and-dirty optimizations. Next time, I’ll start hitting the code with some minor changes that can have potentially large impacts on performance in Torque X 2D.

Check here for more articles in this series: Game Development
  • Language

  • Sponsored Links

  • Rob's Portfolio

    Games Writing Contributions

No comments yet.

Leave a comment