🔒 Locked

FPS counter in a GameComponent

Started by Puyover Jan 18, 2011 at 11:02 AM 3 replies 6.7k views

Original Post

Jan 18, 2011 at 11:02 AM

Hi,

Seeing as how to calculate the fps of a game, it occurred to me the idea to put all that code in a GameComponent so it can be reused as many times as I like, but I'm not sure if this is one case in which one must use the GameComponent or not worth it.

This is my GameComponent:

using System;
 using System.Collections.Generic;
 using System.Linq;
 using Microsoft.Xna.Framework;
 using Microsoft.Xna.Framework.Audio;
 using Microsoft.Xna.Framework.Content;
 using Microsoft.Xna.Framework.GamerServices;
 using Microsoft.Xna.Framework.Graphics;
 using Microsoft.Xna.Framework.Input;
 using Microsoft.Xna.Framework.Media;
 
 
 namespace SpriteTest
 {
 /// 
 /// This is a game component that implements IUpdateable.
 /// 
 public class FPS : Microsoft.Xna.Framework.DrawableGameComponent
 {
 private float fps;
 private float updateInterval = 1.0f;
 private float timeSinceLastUpdate = 0.0f;
 private float framecount = 0;
 private GameWindow Window;
 
 public FPS(Game game, GameWindow Window) : base(game)
 {
 // TODO: Construct any child components here
 this.Window = Window;
 }
 
 /// 
 /// Allows the game component to perform any initialization it needs to before starting
 /// to run. This is where it can query for any required services and load content.
 /// 
 public override void Initialize()
 {
 // TODO: Add your initialization code here
 
 base.Initialize();
 }
 
 /// 
 /// Allows the game component to update itself.
 /// 
 /// Provides a snapshot of timing values.
 public override void Update(GameTime gameTime)
 {
 // TODO: Add your update code here
 
 base.Update(gameTime);
 }
 
 public override void Draw(GameTime gameTime)
 {
 float elapsed = (float)gameTime.ElapsedGameTime.TotalSeconds;
 framecount++;
 timeSinceLastUpdate += elapsed;
 if (timeSinceLastUpdate > updateInterval)
 {
 fps = framecount / timeSinceLastUpdate; //mean fps over updateIntrval
 #if XBOX360
 System.Diagnostics.Debug.WriteLine("FPS: " + fps.ToString() + " - RT: " + gameTime.ElapsedGameTime.TotalSeconds.ToString() + " - GT: " + gameTime.ElapsedGameTime.TotalSeconds.ToString());
 #else
 Window.Title = "FPS: " + fps.ToString();
 #endif
 framecount = 0;
 timeSinceLastUpdate -= updateInterval;
 }
 
 base.Draw(gameTime);
 }
 }
 }

And inside my main program, I call it so:

public Game1()
 {
 graphics = new GraphicsDeviceManager(this);
 //graphics.SynchronizeWithVerticalRetrace = false;
 graphics.PreferredBackBufferWidth = 1280;
 graphics.PreferredBackBufferHeight = 720;
 //IsFixedTimeStep = false;
 Content.RootDirectory = "Content";
 
 Components.Add(new FPS(this, Window));
 }

Steve25

Jan 18, 2011 at 12:40 PM

I believe this is done at some point in the book I think in Chapter 3 or 4?

Puyover

Jan 18, 2011 at 1:30 PM

I believe this is done at some point in the book I think in Chapter 3 or 4?

Oh it's true, in GameComponent's section of Chapter 4 is done differently than mine. Well, I guess if it is a good use of GameComponent in this case.

Thanks.

NEXUSKill

Jan 18, 2011 at 3:01 PM

Personally I don't use much GameComponent, every thing, every system and every manager, can be implemented without ever touching a game component and still be designed in such a way that the objects are reusable, for instance, I tend to separate systems into different DLL libraries, got one for render only, one for collision checking, one for audio management, etc. Then the games I develop simply link these libraries and stick it all together.

However the concept behind game components IS a very good idea, keeping specific functionalities such as time tracking separated from application (game) specific code, such as a tetris implementation, is something you should always aim for.

More so, if you find yourself writing the same feature or code twice for two different projects, you should consider making it independent of the apps and throw it in a DLL or a personal repository of reusable code.

Many of the design features of XNA, such as the GameComponent or the Services intrefaces, are more like a suggestion than a MUST, in many cases, there are good suggestions, but don't feel forced to use them if it doesn't fit your needs.

espp1234

Jan 24, 2011 at 9:22 PM

The GameComponent system in XNA sounded pretty neat at first, but in practice, I found it quite inconvenient. Besides the fact that it is hassle to maintain the order of which components go first and maintaining references to ones for which you need to change properties for, inheriting a class from another library (that is not yours), is bad for your health. All your FPS component needs is a private variable to keep track of the previous timing and draw the delta in the draw call... your Initialize, LoadContent, Update, UnloadContent methods are empty. Also GameComponent has a reference to the Game object and exposes the GraphicsDevice, ContentManager, etc through itself.... In short, it comes with a lot of baggage you don't need that affect performance.

Personally, I still like the modular architecture of the GameComponent pattern, but instead of inheriting from GameComponent and DrawableGameComponent, I declare the following interface...

public interface IGameComponent
 {
 void Update(GameTime gameTime);
 
 void Draw(GameTime gameTime);
 }

This allows me to still contain and enumerate all my components in one data structure while adhering to the update/draw contract.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.