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 culling algorithm of the engine;
• The speed of the video drivers and graphics card;
• The number of polygons and pixels rendered on the screen;
• The complexity of the scene and scripts;
• and an artificial delay for keeping the frame rate in sync with the monitor.

The major framerate "bottleneck" is the speed of your graphics card and the number of pixels drawn per frame. You can test the performance of your hardware with the infinite terrain example that renders 9 views with about 6600 entities each. On normal PCs, the total of 60,000 entities are rendered with about 20..30 fps. You can see how the frame rate drops when you only increase the scale of the tree models and thus render more pixels. This should give you an idea how many entities you can put in your game for a given graphics hardware.

The fps contribution of certain elements can be seen in the [F11] panel in ms per frame. 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).

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. This delay is visible in the 'screen refresh' time in the [F11] panel. 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

• Don't use a single 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.
• Always 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 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.
• Old 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 mesh size is somewhat smaller, about 100 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 require more space in the scene management tree, and cause slower rendering. A model with a single big texture renders faster than a model with several small textures.
• Nonanimated models render faster than animated models. For a forest, use several tree models rather than several frames of one single tree model. The opposite is true for sprites: many frames of the same sprite render faster than many separate sprites.
• Vertex animation is faster than bones animation.
• Nontransparent or overlay textures are faster than transparent or alpha channel textures, especially when you have many entities in the level.
• 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. IGNORE_ flags can greatly speed up c_move and c_trace. Moving UNLIT objects is faster than moving lit objects.
• Use WED for setting up entity properties, rather than an entity action. If an action is required only for setting up an entity, reset its DYNAMIC emask 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.
• Vertex shaders render faster than pixel shaders. Shift as many calculations as possible from the pixel shader to the vertex shader.
• The bigger a model or sprite is scaled, and the closer it is to the camera, the slower it is rendered. The rendering time depends on the number of pixels that the object covers on the monitor.
• The more polygons a model consists of, the slower it is rendered. Use LOD steps for huge models, 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.