FlatRedBall

There have been some concerns brought up in the XNA community about whether XNA hurts performance of games. Although I haven’t heard any questions directed specifically at the FlatRedBall Engine, since I’ve been working on the rendering portion of the engine, I thought I’d bring this topic up.

So, first, is XNA slower than Managed DirectX. Yes. But let me explain. Figures vary, but I’ve heard that XNA calls are 3 – 10% slower than similar MDX calls. Ok, so it’s not that bad, and further evaluation reveals more. First, consider that just the XNA calls are slower, not your entire game. Therefore all game logic will run the exact same. That means all sorting, movement, custom functions, attachments, and all the other wonderful stuff that FRB provides will run the exact same.

Next, consider that the hardware does a lot of work during the rendering which doesn’t really depend on the call. That is, sure it might take longer to feed a vertex buffer to the GFX card, but once it has it and its doing the transformations and writing to video memory, that’s all dependent on the card.

This means that even if you isolate the rendering itself, it WON’T go 3-10% slower when compared to MDX.

Finally, the XNA translation has given me the opportunity to do a lot of the things that I’ve wanted to do to the engine, but couldn’t because of fear of breaking existing code. I’ve been working on the C#/MDX version of FRB for nearly 3 years and during that time I’ve learned quite a bit.

One of the major changes that is going to happen to FRB is that there will no longer be DynamicSprites. All Sprites (including unordered Sprites) will give the user control over vertices. Furthermore, the ability to limit automatic every-frame updating is no longer limited to Unordered Sprites. Sprites can be easily moved between being automatically and manually updated at any time.

Since all Sprites will be just as DynamicSprites are in the MDX version of FRB, that means that alpha (fade) and color (tint) information will be stored on the vertices rather than in a separate value. This enables the engine to perform rendering with fewer breaks in the rendering. That is, the engine will be able to batch Sprites more effectively, greatly reducing the number of XNA calls being made.

With the use of sprite sheets, the number of calls can be reduced even further. I anticipate that in regular usage (without using sprite sheets to reduce texture switches), the new Sprites will more than compensate for the slower XNA calls. That means that even though FRB is moving to a “slower” framework, the engine will actually be more efficient than before.

Effectively placing Sprites in the manual update group (which is simply one call) can improve performance even more.

And of course, let’s not forget one thing – the ability to run on the incredibly powerful Xbox 360. With all of these combined, the new FRB will be easier to use and much faster. The translation continues…

–Vic–

I downloaded XNA Game Studio Express Beta 2 yesterday. It’s my first experience with XNA and I must say I’m completely blown away. It is so incredibly easy to get a project running.

One thing that I noticed initially is that the documentation is awesome. A lot of entries also linked to articles explaining their use and sample code. Within minutes I was able to get a 2D scene. In under 30 min, I got a 3D model loaded which moved around with input. Sure, it was all code from tutorials, but it was so easy to do that I understood exactly everything that was happening.

In fact, it’s so easy to use that initially I wondered if there was even a place for FRB. The purpose of the engine is to allow users to utilize the power of DirectX without having to learn it in depth and to simplify initialization. XNA does an amazing job on both as well as provides a great content pipeline.

However, there is still room for FlatRedBall as there are many higher-level objects like SpriteGrids, SpriteFrames, Screens, and tools like the FRBDK which can greatly help make 2D games.

So, the project continues to live on, just in a slightly modified state. I actually started the real code translation last night after realizing how easy it is to use XNA.

One major change that users will notice is that FRB will work hand-in-hand with XNA rather than serve as a wrapper. DirectX can be scary, and it’s possible to work with the older version of FRB without touching any DirectX types (except perhaps Vector3). XNA is easy enough to use that I’m comfortable using their Game class as a replacement for the template, and simply making FRB plug into the system. More on this topic as the translation continues to progress.

–Vic–

Although some things have been stirring, the XNA translation officially started yesterday with the plan for reorganizing namespaces. I have been discussing planned changes with a few FRB members and with their help and feedback, I’m very excited and pleased with the progress so far. FRB is supported by its community, and if you are interested in participating in the translation, either by providing feedback, testing, or code, contact me through a PM on the forums (Roof Top Pew Wee). I’ll be keeping everyone up to date on the progress here on the blog.

–Vic–

Joel reported a serious problem with the SpriteEditor, so I *think* I fixed it and uploaded a new version of everything. If you got the files yesterday, might as well grab the newest version today.

–Vic–

Wow, it’s been quite a while since I’ve blogged – uncharacteristic of me. Well, as the title says, the November release is up.

So, what kind of things can you expect? First, there have been some syntactic changes which may cause you problems. As always, I recommend reading the Version History here:

http://www.flatredball.com/frb/docs/index.php?title=Version_History

But, if you haven’t, or don’t care to, you will need to add a 4th argument to the SpriteManager constructor which indicates the folder where the default text can be found. If not, you won’t be able to draw text in the AfterFrameActivity method. Also, the SpriteManagerSettings field “fixedFunction” has been changed to “FixedFunction”. Capitalized it to fit with .NET naming better.

There are a few improvements which I’m excited about for this release. First, .scn files can be saved with textures relative to the .scn itself rather than the SpriteEditor. This makes SpriteEditor scenes even more portable – as long as a .scn is saved with scn-relative textures, and the textures are all located in the same directory as the .scn itself, then the containing directory can be zipped and sent. Then the .scn can be loaded from any location – no more requirements of duplicating folder paths to run .scn files.

The FileManager (namespace FRB.File) can control relative directories which are used by the TextureManager when loading assets. This also helps improve protability and reduce restrictions on directory structures.

The Emitter class has been completely redone and to accompany the new class, I have written a new entry on the Wiki. Check it out here:

http://www.flatredball.com/frb/docs/index.php?title=Emitter

In response to a suggestion on the board, the Music class is better documented, and I’ve added a Balance property which can be used to pan the music to the left or right channel.

The engine keeps improving! Let us know if you have any problems with this release, and keep the suggestions coming.

–Vic–