Frame Rate Considerations

The frame rate is the number of frames rendered per second (fps), and determines the 'smoothness' of game play. It is dependent on five factors:

• The speed of the engine;
• The speed of the video drivers;
• The hardware performance;
• The complexity of the running scripts and the rendered scene;
• and an artificial delay for keeping the frame rate in sync with the monitor.

However, the frame rate is not just determined by the sum of the above factors - they can influence each other. The fps contribution of certain level elements can be seen in the [F11] panel in ms per frame. The additional delay added by the system for synchronizing the frame rate is reflected by the 'screen refresh' time. In some cases it can be larger than the real rendering time by the engine and hardware, especially in fullscreen mode in which the frame rate is limited by the monitor frequency (mostly 60 Hz on LCD screens and 70..80 Hz on CRT monitors).

Updates and fps

Engine updates normally render faster than their predecessors - and no update ever was slower. Nevertheless, whenever a new engine update comes out or a new video driver is released, some users complain about having 'less fps' than before. Why is that?

Every subtle change in the system can affect the frame rate in a different way, depending on hardware and software components. So it's normal that even when a newer engine renders faster on most systems, it can be slower on a few. Video drivers, especially by nVidia, often use optimizations for performing better with benchmarks. Those optimizations also change with every driver release and with every DirectX version the engine uses. In the last time nVidia tended to remove those optimizations from their drivers due to their side effects.

Even if you think that the new update runs 'slower' on your PC than it's predecessor, use it if you want to distribute your game. It's the end user's frame rate that matters.

Monitor frequency and fps

In fullscreen mode, DirectX keeps the frame rate always in sync with the monitor frequency between 60 and 80 Hz in order to avoid tearing artifacts. The screen refresh is artificially delayed for matching the time when the monitor has finished its video cycle. Thus you'll never get a higher frame rate than your monitor can display. Your frame rate will be an integer division of the monitor frequency (such as 60, 30, 20, or 15 Hz when the monitor frequency is 60 Hz). When the frame rate is close to the monitor frequency, a small change of the rendering time will cause the frame rate to suddenly jump from 60 to 30 fps or vice versa.

Some tips for increasing the frame rate in your games

• Avoid using a big model for a level. When the engine renders the whole level as a single model, it can't use it's scene management, and renders even the parts of the level that are not visible. That will result in a very bad frame rate.
• When editing the level in external editors such as MAX, MAYA, or Blender, use the WED FBX Level Import that automatically imports the level as separate meshes and models.
• Use Mesh Mode for compiling your level. If you want to create a BSP tree, use blocks only for the rough geometry of the level, and use detail blocks or models for details.
• A medium number of medium sized meshes renders faster than a huge number of small meshes, or a small number of huge meshes. In WED, activate the Single Mesh flag for all groups that contain about 100 polygons. Use Mesh Size in Map Properties for automatically combining several blocks to single meshes.
• Deactivate the mouse if you don't need it . Mouse detection in a 3D view can reduce the frame rate remarkably.
• Reduce the number of sounds audible at the same time. Some sound cards without hardware mixer reduce the frame rate remarkably when many sounds play simultaneously.
• 2D instructions, like draw_textmode, can reduce the frame rate remarkably. Avoid instructions marked with 'slow' in the manual.
• The smaller the clipping range (camera.clip_far), the faster the rendering especially in outdoor levels. Activate fog if you want to cover the clipping border.
• Cheap 3D cards work best with 256x256 texture sizes. The bigger the texture, the slower the rendering.
• Terrain renders faster than models - especially when it's chunked. Do not use models for terrain.
• With today's 3D hardware, the best model size is in the range of 500..1500 polygons. If possible, split bigger models in several parts. The best block size is somewhat smaller, about 100..500 polygons, because lightmapped blocks usually consist of several subsets and require more rendering passes than models.
• When constructing a model, have it's origin as close to it's center as possible. Models with bad placed origins consume more space in the scene management tree, and cause slower rendering.
• Nonanimated models render faster than animated models. For a forest, use several tree models rather than several frames of one single tree model. Vertex animation is faster than bones animation.
• Setting an object's x/y/z coordinates directly is faster than using c_move. c_move without glide is faster than c_move with gliding. The AABB collision detection is faster than the OBB detection.
• Use WED for setting up entity properties, rather than an entity action. If an action is required for setting up an entity, reset its dynamic flag at the end of the action.
• Bitmap fonts are faster than Truetype fonts. Truetype fonts are reported to render very slow in some PC configurations.
• Sky cubes render faster than sky models and sky domes.
• Use LOD models whenever possible, especially in outdoor levels.
• Mipmapping increases the frame rate. Always create mipmaps for model and terrain skins - it's just a mouse click in MED.
• Last but not least: The A7 engine is faster than the A6 engine, and newer engine versions are faster than older engine versions. Always uses the latest engine update.

Some tips for decreasing the frame rate in your games

Why would you want to decrease the frame rate? There are three reasons. Your movement functions might only work properly within a certain frame rate range, and fail at 1000 fps. You won't want your application to consume all the CPU cycles. And most important, you want to avoid stuttering. Stuttering means a camera and actor movement that appears unsteady. It won't be noticeable in a game with complex levels and medium frame rate, but mostly in games with almost empty levels, little content, and consequently very high frame rate that is then capped by fps_max.

The main reason for stuttering is a coarse PC scheduler resolution that leads to inaccurate task start times, especially when many tasks are running on a particular PC. This problem can be avoided by limiting the frame rate not only with fps_max that just gives task time back to the Windows task scheduler, but by really burning CPU cycles in some or the other way. Fortunately, this is easily done. If your game experiences stuttering, just place some more details in your levels for avoiding a too-high frame rate.