Ok, this might not seem like a big deal, but we’ve added a Reference link on the naviagtion bar near the top of the site. This is becoming a great place for FRB information mainly because I can post just a little here and there rather than having to write an entire article at once. Check it out.
–Vic–
I was actually a little unsure whether I’d get this update or not. I have been rather busy with work and now that the XNA translation has started, most of my work has been focused on the new engine rather than the old.
However, looking back at my Subversion log, it looks like I still have made quite a few improvements to the engine this month. Also, at least for the next few months, I expect the new engine to be able to work with .scn files created with the old SpriteEditor. If we have problems with the binary files, then I will add the option to save all files as .XML files.
The main changes are in the FRBDK. AnimationEditor has had some visual improvements and now .srg and .ach files can both be saved with textures relative to the files themselves. The SpriteEditor has had some stability work on it. .scn files can now be dragged onto the .exe itself and the the SpriteEditor will fire up and load the .scn. Rather convenient. Joel has been working on file association for the SpriteEditor. Ideally, the SpriteEditor will check to see if it is associated with the .scn file type. If not, it will ask if you’d like to make this association.
If you are wondering what the XNA translation means for the Managed DirectX version of FlatRedBall, don’t worry. Since the FRBDK will continue to use the MDX version, it will continue to live and be improved over time. I will also continue to provide service for this version of the engine, so if you experience any problems, you can expect to have the same level of service as before.
–Vic–
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–
One of the most common problems beginners experience with .scn files is portability. Textures referenced by a .scn use the SpriteEditor’s location as the relative folder. This requires that either the SpriteEditor is in the same directory as the project’s .exe or that the SpriteEditor has the same folder structure. Both of these options are problematic, and even moreso when a .scn is to be transferred from one project to the next.
The .scn filetype is pushed as a standard FRB file so that it can be used from one project to the next. One reason this is important is it allows new FRB users to work with existing .scn files both in code and in the SpriteEditor. Another benefit is that generic .scn files (such as UI screens) can be used in multiple projects. Finally, taking levels from one game and using them in a different game can also be enjoyable.
Therefore, for the November release of FRB, I’ve added the ability to specify the directory to which assets are relative to in code. A new class called the FileManager provides methods and properties both to simplify working with files as well as to specify the relative directory which will be used by the engine when loading files.
The second improvement coming in November is the ability to specify that all files referenced by a .scn file should be relative to the .scn itself. This removes the tie between the .scn and .exe, and allows users to create a zip file with a .scn and its referenced assets and send it to any other user. The .scn can be loaded in the SpriteEditor or code without having to create the same folder structure below the .exe.
I anticipate that as the .scn and Screens become more common in FRB projects, standard .scn files will be available on the site for use as generic .scns. Furthermore, objects like SpriteRigs, AnimationChains, and other FRB-specific files will become more modular, improving reusability.
–Vic–
The October 2006 version of FRB is here. Not too many changes this month. A few text fixes in the FRBDK, some work on the AttachablePoly class, and… oh yeah, fixed that little alt-tab bug which had been present in the engine for years. Also, the engine’s a little easier to set up in a custom control when not using the template. We will continue to improve on this, and eventually provide a template which creates a control-based project.
–Vic–
Today I was testing out network play on IGB3 with a friend of mine. As we were playing, he was commenting on very jittery movement. We were playing the Italian Kitchen level, and on his machine, the splatters on the screen never disappeared – they just stayed in place slowly covering his entire screen until the game was unplayable.
A little later, he commented that it looked almost as if at times, things moved backwards. The only way this could happen is if the TimeManager was inaccurately reporting time – and the only way that could happen is if the second difference for each frame was very small.
I asked him what kind of machine he had and it turns out he’s running an incredibly powerful desktop. Although it didn’t seem likely, perhaps his framerate was too high, I thought. So I put a limit on the framerate of 200 fps. I sent him the latest version, and the game ran perfectly. The shooter rotated fine, the splatters on Italian Kitchen worked great. We tried playing a network game again and it all worked perfectly.
So, what I suspected seemed to be the case – the game ran too fast. In fact, it’s possible that the game ran so fast that the rates and velocities being applied were too small – the values calculated when multiplying by TimeManager.secondDifference in the TimedActivity methods were so small that they actually rounded down to 0 due to floating point inaccuracies. I haven’t verified that this was actually the case, but since the game runs perfectly when limited to 200 fps, it seems likely.
So, if you’re concerned that your game will encounter the same situation, try placing the following at the end of your loop in OnApplicationIdle:
if (TimeManager.GetSystemSecondsSince(TimeManager.currentTick) < .005f)
{
int milliseconds =
(int)(1000 * (.005f – TimeManager.GetSystemSecondsSince(TimeManager.currentTick)));
System.Threading.Thread.Sleep(milliseconds);
}
–Vic–