Manually updated objects are objects which are removed from the FlatRedBall engine's automatic managed lists. In other words, manually updated objects will not have behavior such as velocity or attachments automatically applied. The following set of articles discuss what automatic vs. manual udpates are and why they are important for performance.
[subpages depth="1"]
Particles may require a large number of FlatRedBall Sprite instances. This guide shows how to create an incredibly efficient particle system using manual particle sprites.
Manual sprites are sprites which the engine does not automatically update every frame. Manual sprites are an efficient alternative to automatically-updates sprites (the default) if:
The sprite does not change often (such as a static background object)
The sprite changes frequently, but only uses a subset of variables that change every frame
The term "particle sprite" implies it is used for particle effects, but technically a particle sprite is pooled - supporting rapid addition and removal without any memory allocation.
The following code is written in a screen which has access to a Texture2D called Texture. Notice that it creates sprites very quickly (60 per second), and even at large numbers the game will run at a reasonable speed:
Automatic updates can take a significant amount of time every frame if your game includes a large number of automatically updated objects. The first step in improving the performance of your game is measure the number of objects your game contains. This article will discuss how to do this.
This article assumes that you already have a working project in FlatRedBall - preferably one with a variety of automatically updated objects (Sprites, Shapes, Entities, Text objects, etc).
The FlatRedBall Engine includes a class called Debugger which can help you debug and diagnose problems in your project. In this case we'll be using a function called WriteAutomaticallyUpdatedObjectInformation. This method will print the number of managed objects to the screen in real time. It's a very simple method to use which provides a lot of useful information. To use it:
Open your project in Visual Studio
Navigate to your Game class (which is by default called Game1 in Game1.cs)
Navigate to the Update method
Add the following code *after* FlatRedBallServices.Update:
Run your game
The information printed out gives you an idea of what the engine is spending its time updating. In the picture above you can see that the game has a total of 50 automatically updated objects. The lines show the breakdown - the majority of the objects are Sprites, then PositionedObjects (which are usually Entities if using Glue) make up the second largest category.
This question can be difficult to answer. The short answer is "it depends". Here are some considerations to keep in mind when working on a game:
Numbers greater than 1000 are usually bad.
Games with fewer than 100 are unlikely to have performance problems from managed objects.
Platforms without as much processing power (such as mobile platforms) can have performance problems with as few as 500 managed objects.
Fewer objects is always better on mobile platforms even if no performance problems are visible. Fewer objects means less processing needed per-frame, which means your game won't run down batteries as quickly.
For the most part the cost of each type of object is equal. In other words, managing one Text takes just as much time as managing one Sprite. Therefore, when looking to improve the performance of your game, you likely want to tackle the largest number first.
If you are using Glue then it's likely that a large number of your automatically updated PositionedObjects are Entities. For more information on making these manually updated, see the ConvertToManuallyUpdated page.
For information on how to improve the performance of your game if it has a large number of Sprites, see this page.
Even if you've used FlatRedBall for a while you may not be familiar with exactly what a "manually updated" object is. The reason for this is because the option to make things manually updated exists almost exclusively for performance reasons. Technically one might want to manually update objects to achieve custom behavior as well, but generally this is not encouraged because it can lead to bugs and often this type of implementation duplicates functionality already present in automatically updated objects. In short, you can designate objects as manually updated to make your game run faster, and that's usually the only reason this is done.
To answer the question of what a manually updated object is, let's look at a very common piece of code:
If you've used FlatRedBall you probably know that the code above will create a Sprite, then start the Sprite's movement to the right at 5 units per second. As mentioned in one of the introductory tutorials, the Velocity property changes the Position property based off of elapsed time. This is done "automatically". This "automatic" application of velocity is what it means to be "automatically updated". So, then you might be guessing that something which is manually updated does not have Velocity applied to it every frame - and if so you're right! If an object is manually updated, then it means that the FlatRedBall Engine is not performing every-frame automatic updates on it.
The following is a list of properties which are applied for automatically updated objects. Not all properties apply to every automatically updated object. For example, the ScaleXVelocity property doesn't apply to Scale on the PositionedObject class because the PositionedObject class doesn't have the ScaleX or ScaleXVelocity properties. However, looking below can give you an idea of what kind of things are done for you by the engine:
So, if you have a group of objects which do not have any of the above properties then that group of objects is a good candidate for being made manually updated. That is, an object can safely be made manually updated if it doesn't have:
Movement
Color rate changes
Attachments
Scale velocities
Animations
Instructions
The answer is "it depends". It depends on how much of your game time is actually spent on updates. Converting to manually updated helps the most when your game has a large number of objects (such as Sprites or PositionedModels) which are going to be static - such as part of a level. It's common to have games which have hundreds or even thousands of such objects - most of which aren't even on screen. In these situations the engine may be spending a considerable amount of time updating these objects unnecessarily. Grabbing a reference to these objects (perhaps through some naming convention if using Scenes) and converting them to be manually updated can greatly improve performance. The process is fairly straight-forward so if you suspect that you may be experiencing update-related performance issues, give it a try. For an example of how this works in a very simple scenario, see the SpriteManager's AddManualSprite wiki entry.
This section will walk you through identifying how many Sprites you have in your game, and how you can reduce this number to improve performance. If you haven't yet, you should first read the article about measuring all PositionedObjects. This article can be found here.
If you've used WriteAutomaticallyUpdatedObjectInformation and have identified that Sprites are causing performance issues, then the next step is to figure out where your Sprites are coming from. Of course, if your game is simple, or if your Sprites do not come from diverse sources, then you may already know where your Sprites are coming from. For example, if you have a level with a very large Scene (.scnx file) then it's likely that many of your Sprites are coming from this file. However, let's assume that you're not sure where your Sprites are coming from.
Just like in the general PositionedObject measuring tutorial, the FlatRedBall Debugger provides functions that can help us identify where our Sprites are coming from. To use this function:
Open your project in Visual Studio
Navigate to your Game class (which is by default called Game1 in Game1.cs)
Navigate to the Update method
Add the following code *after* FlatRedBallServices.Update:
Run your game
The image shown above was taken from Baron when it was late in its development. At this point a considerable amount of optimization had already been performed. The first line tells us the total number of Sprites which are automatically updated by the engine. In this case, the engine is managing 111 Sprites. Assuming you want to reduce this number, the next step is to identify where all of your Sprites are being used. What follows are lines indicating how many Sprites are being used by which entity, or marked as Unparented if the Sprites are not associated with any entities. For example, we can see that in this screen shot 51 of the Sprites are being used in the OverworldLevel entity. This represents almost half of our updated Sprites. If we were to try to reduce the number of Sprites here, then OverworldLevel would be a good place to start.
Now you should see information about the objects that are present in your game. The top-left of your screen may look similar to:
Here is an example of what output might look like:
Property that modifies
Modified property
Notes
Velocity
Position
Acceleration
Velocity/Position
Position
If KeepTrackOfReal is true.
Position/RealVelocity
If KeepTrackOfReal is true.
RotationXVelocity/RotationYVelocity/ RotationZVelocity
RotationX/RotationY/RotationZ RotationMatrix
Drag
Velocity
RelativeVelocity
RelativePosition
RelativeAcceleration
RelativeVelocity/RelativePosition
RelativeRotationXVelocity RelativeRotationYVelocity RelativeRotationZVelocity
RelativeRotationX/RelativeRotationY/ RelativeRotationZ/ RelativeRotationMatrix
Relative values
Matching absolute values
If Parent is not null.
AnimationSpeed/CurrentChain
CurrentChainIndex/Texture/Texture coordinates
ScaleXVelocity/ScaleYVelocity
ScaleX/ScaleY
Instructions
Potentially anything
The engine calls Instructions on any IInstructable that it manages.
RedRate/GreenRate/BlueRate/ AlphaRate
Red/Green/Blue/Alpha