I had mixed feelings about the specific game, ever since I first lay my hands
on the demo. Donâ€™t misunderstand me the graphics are breathtaking and
the game is differentiating itself from other FPS games in terms of AI and
physics, yet the demands it puts on systems in general are quite high in my
opinion. Iâ€™ll come back to that one later on.
Cry Tek is close to releasing Patch 1.2, which enables Shader Model 3.0 for
accelerators that support SM3.0 (currently only the NV40 line of products).
There arenâ€™t any differences in terms of image quality between the SM2.0
and SM3.0 path from what Iâ€™ve read or from what I was able to see when
gaming with either/or. For the time being the SM3.0 path concentrates on performance
increases for SM3.0 GPUs via pass reduction wherever possible.
Before I started writing this review I still had an Athlon XP2200+ and only
512MB host ram; a perfect opportunity to see how things look like on even lower
end systems than this one. Please keep in mind that I had every in game setting
set to the absolute maximum, 4x AA and 4x full trilinear AF set through the
application (while the driver control panel was set to â€śapplication preferenceâ€ť and â€śhigh
qualityâ€ť). I used 1280*960*32 as my testing resolution, because albeit
with both the XP2200 and 3000 the system still remains CPU limited, there isnâ€™t
a single chance that the game will be playable in higher resolutions than that,
unless I tune down settings more than just a little.
Yes those are frames per second and I was looking at single digit frame rates
more than often during each of the demos. In Regulator performance actually
slightly decreased (~5%), Training and Volcano saw an interesting increase
(~17-18%), while Research took literally off reaching a quite impressive 55%
Interesting to note are the Triangle rates the log files deliver; letâ€™s
have a look how it looks like for Research specifically:
Min FPS: 10.89 at frame 434, Max FPS: 36.65 at frame 713
Average Tri/Sec: 966368, Tri/Frame: 45955
Min FPS: 23.16 at frame 89, Max FPS: 46.40 at frame 738
Average Tri/Sec: 855186, Tri/Frame: 26196
As a side note, Far Cry absolutely needs more than 512MB host ram; loading
times are extremely long and the HDD is swapping more than just a lot during
game play, causing way too many stutters, especially when the player is faced
with opponents. Of course is a low end CPU not good enough either; letâ€™s
see how it ranges with identical settings on what I consider to be a mid-range
CPU nowadays and 1024MB of host ram:
Gaming is a lot easier with that setup; most of the hard drive swapping is
gone and the desktop doesnâ€™t take ages to recover after you exit the
game. Differences between the SM2.0 and 3.0 path are more or less in the same
ballpark in Training/Volcano, Regulator sees now a 6+% performance increase
and the differences in Research shrunk to 45% this time.
As itâ€™s understandable performance in most occasions is quite normal
indoors; as soon as you get outside though and the Polygon rate exceeds the
120-150K rate, it can get really nasty especially if highest quality filtering
is being enabled.
The next thing I tried is to compare application full trilinear 4xAF, vs.
driver control panel 4x â€śqualityâ€ť AF, which utilizes the hybrid
bi-/trilinear mode (see â€śbrilinearâ€ť) and Anisotropic Optimisations
enabled (texturing stage â€ś0â€ť= trilinear, stages â€ś1-7â€ť =
bilinear). FarCry was configured to â€śtrilinearâ€ť and 1xAF (note
that I compared SM3.0 scores only this time):
The differences in according percentages are:
Would one now change to bilinear in the application and leave the CP options
as above, there would be another healthy increase added. Problem being here
that bilinear AF exposes in quite a few spots MIPmap banding, which I personally
The game is playable in 1280*960*32 if in game settings get tweaked in between
medium to high settings and optimized texture filtering. The going gets still
tough, because first person shooters need a bit more than 30-40fps averages
to be considered absolutely â€śsmoothâ€ť.
Last thing I tried was the Pier demo (from PCGH), also used by 3Dcenter in
their recent artikel.
Maximum in game settings
4xAA / 4xAF *
(*) trilinear/4xAF in game, driver CP= application specific, high quality
SM2.0 path = 26.34 fps
SM3.0 path = 27.79 fps
A 5.5% increase here between the two paths; nothing to write home about really.
Letâ€™s see how it looks like if I switch to â€śqualityâ€ť CP
All other settings identical as above except:
(*) Trilinear/1xAF in game, driver CP= 4xAF, quality
(Only SM3.0 path performance compared):
SM3.0 path = 36.17 fps
Compared to the former SM3.0 score, thatâ€™s a healthy 30% performance
Finally I compared point sprites vs. instancing with the SM3.0 path. To enable
instancing youâ€™ll have to set â€śe_vegetation_sprites_distance_ratio
Play Time: 103.01s, Average FPS: 36.17
Min FPS: 29.32 at frame 2994, Max FPS: 48.68 at frame 1970
Average Tri/Sec: 5464713, Tri/Frame: 151073
Play Time: 115.76s, Average FPS: 32.19
Min FPS: 22.97 at frame 823, Max FPS: 48.42 at frame 1949
Average Tri/Sec: 11141941, Tri/Frame: 346156
Performance decreases only very little compared to the increase in triangle
ratios between the two cases. While with sprites the Tri/Frame ratio peaked
at somewhere around 200+k Tris, with instancing it almost touched the 800k
rate in some spots. Instancing makes objects in the far clipping distance look
quite a bit better, yet the very high polygon rates also slightly increase
For the end I asked Demirug for his opinion about Far Cry in general:
â€śShow me the island
We probably all agree that Far Cry's Cry Engine can render some very complex
environments. We won't try to dispute that fact. However, unfortunately,
Cry Tek doesn't deserve much praise regarding efficiency in using gamers'
PC's scarce computing resources. You're in for some unpleasant surprises
if you capture and analyze Far Cry's communication and the graphics API,
using the proper tools.
The concerns start with the crosshair. It's composed of five small lines and
the engine renders these lines separately, one by one. In terms of CPU load
it doesn't make much difference how much geometry is rendered per API call
but it sure does matter how many API calls are made in total**. This is but
the first sign of CPU time being spent carelessly. More of the same - with
more significant performance implications - can be observed in the engine's
terrain rendering. Terrain is split in tiles, which isn't a bad idea actually.
However, each of those tiles is split again, into strips, which get rendered
individually. Thus the CPU has to do a lot of unnecessary work to render each
tile, even though one call per tile would have been perfectly sufficient.
This isn't a big deal as long as the CPU is much more
powerful than the GPU. But then GPU performance isn't used carefully either.
Naturally lighting calculations
are quite complex and itâ€™s crucial to minimize these calculations. Far
Cry has the tendency at this point to constantly conduct a large number of
lighting calculations, for objects that end up being overdrawn. The lighting
calculations themselves aren't optimal either. Each light source gets rendered
individually. Consequently the workload for reading out textures is repeated
for every light source. The maximum allowed instruction count for 2.0 class
shaders is an obvious problem here. But these shader length limitations aren't
as bad as to require rendering every light one by one. Far Cry does exactly
this, all the time, even though a (small) number of lights could be rendered
in a single pass in many instances with PS2.0. With chips that allow longer
shaders such as the GeForce FX line, or the new Radeon X800, all lights could
always be rendered in one single pass.
Each one of my concerns is only a minor offense against
optimisation rules when reviewed in isolation, but they pile up. With the
new patch some of these
problems get addressed, but unfortunately only for users with SM3.0 capable
cards. Everyone else is left only with the currently unoptimized SM2.0 path.â€ť
In the meantime Cry Tek released (and has withdrawn again) the 1.2 patch. Apparently
it does contain a SM2.0b path for R420 class accelerators.