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.
► latest
version online