FarCry4.exe_2015-05-23-13-43-08-184

In a previous post I found some of the possible reasons for serious intermittent frame rate drops (“stuttering”) on systems meeting the minimum requirements for Far Cry 4.

System Requirements

    Minimum:
        OS: Windows® 7 (SP1) / Windows® 8 / Windows® 8.1 / (64-bit only)
        Processor: 2.6 GHz Intel® Core™ i5-750 or 3.2 GHz AMD Phenom™ II X4 955
        Memory: 4 GB RAM
        Graphics: NVIDIA GeForce GTX 460 or AMD Radeon HD5850 (1 GB VRAM)
        DirectX: Version 11
        Network: Broadband Internet connection
        Hard Drive: 30 GB available space
        Sound Card: DirectX-compatible (5.1 surround sound recommended)
        Additional Notes: Windows-compatible keyboard, mouse, optional controller (Xbox 360 Controller for Windows recommended)

    Recommended:
        OS: Windows® 7 (SP1) / Windows® 8 / Windows® 8.1 / (64-bit only)
        Processor: 2.5 GHz Intel® Core™ i5-2400S or 4.0 GHz AMD FX-8350 or better
        Memory: 8 GB RAM
        Graphics: NVIDIA GeForce GTX 680 or AMD Radeon R9 290X or better (2 GB VRAM)
        DirectX: Version 11
        Network: Broadband Internet connection
        Hard Drive: 30 GB available space
        Sound Card: DirectX-compatible (5.1 surround sound recommended)
        Additional Notes: Supported video cards at the time of release: NVIDIA GeForce GTX 460 or better, GeForce GTX 700 series; AMD Radeon HD5850 or better, Radeon R9 series. Note: Laptop versions of these cards may work but are NOT officially supported.

( Steam Far Cry 4 page )

My system is some way above the minimum with a 3 GHz CPU and an AMD R7 260x graphics card. I had tweaked  FC4 to the point where I had a stable frame rate ( 30 – 60 fps, usually ~40 ) but that was with most things set to low. Later I found I could turn up some of the settings, possibly due to various FC4 patches and new AMD graphics drivers. As always its difficult to be sure without doing extensive benchmarking which I rarely have time for so a lot of this is based on common sense and educated guesses. I’ve been tempted to ditch PC gaming and buy a console to get away from frustrating tweaking, but I find the technology of video game engines fascinating and would miss the ability to experiment.

Anyway, I still had to have the FC4 textures set firmly on low and I was beginning to wonder why. I had already failed to get RadeonPro to work with FC4 and realised that I really needed it, especially with this game.

BTW, I suspect a lot of the confusion surrounding the tweaking of FC4 is due to it being a 64bit only video game engine. It just does not behave the way most people are used to 32bit game engines behaving. I recently reinstalled Brother in Arms: Road to Hill 30 and the contrast between that and FC4 is almost shocking. Where RtH30 has a totally stripped down appearance, the FC4 world is almost filled to bursting point with events and graphics. That is the difference between 32bit and 64. Up to these fairly recent 64 only games, designers were constrained by the 32bit limit. That’s why these older games look so stripped down, in an almost Zen like appearance. Not just for performance but simply to be able to fit everything into memory. I think 64bit also provides better (not just more) memory addressing so everything can be swapped in and out of memory a lot faster as our hero moves around the FC4 world. However all this new 64bit technology does not come without some teething troubles as we’ll see below.

So onto RadeonPro. I tried making a FC4 profile again. At startup FC4 crashed in Windows 7 with an audio notification and the little dialog box that Win7 throws up. I soon realised that my copy of Fraps was preventing FC4 from loading (I often run Fraps alongside RadeonPro because RP’s screenshot engine sometimes fails to detect its hotkey, whereas Fraps seems to work with anything). I started FC4 with RadeonPro again. Crash ! Or was it ? Windows 7 played its crash notification but FC4 continued loading. What was happening ? I soon realised that the FC4 “.exe” must be starting and terminating multiple times as it went through both Steam and then UPlay before FC4 actually starts. In fact it “crashes” no less than three times before loading up the FC4 menu ! But then I actually had RadeonPro working with FC4. At last.

BTW RadeonPro must, of course, be in 64bit mode for FC4.

fc4_rp_visual fc4_rp_advanced fc4_rp_tweaks fc4_rp_launcher fc4_rp_triggers

So now I had all the aggressive performance optimisations that RP provides.

Remember …

  • No Fraps or other conflicting background processes.
  • RadoenPro must be in 64bit mode (bottom right of its GUI).
  • With RP running FC4 starts up strangely. Windows will indicate multiple crashes but FC4 should start and remain stable.
  • I suspected closing or minimising the Uplay window was interfering with the FC4 startup process as well, so I left it alone, but that could have just been a fluke

Now I started a bit of testing using RP. With textures turned up to the point of bringing on the intermittent frame rate drops, the RP OSD showed my video card speed dropping well below its maximum speed at exactly the point where the fps dropped. If the Dunia engine is doing more work at that point the video card frequency should be going up not down ! Is this evidence of a bug in the 64bit Dunia engine ? Possibly. It could also be a bottleneck on my system somewhere. Remember this 64bit gaming is pushing everything to the max.

Anyhow with RP in the mix I was able to get my textures up to medium with, thankfully, a stable frame rate. This is certainly due to the optimisations provided by RP, but it could also be to do with later FC4 patches and AMD driver releases providing a further influence.

Now this is where things got interesting. I distinctly remembered have a totally smooth, stable and high framerate the first time I installed and played FC4. That was with High to Ultra textures ! Yet I could never replicate that initial experience. Then I had a brain wave. Could the bottleneck be caused by screen resolution ? Did I start FC4 for the first time with a low resolution ? I’d been running consistently at 1440×900. So I cranked that down to just above minimum – 1280×800 and presto ! Smooth frame rates right up to High textures. When I went up to Ultra the stuttering returned. But had a cracked it ? (Remember what I said about 64 bit game engines … I’m used to screen resolution making little difference to fps which is why I usually leave it at 1440×900 … on 32 bit engines).

I had to go out of FC4 for some reason. When I loaded it up again with the same setting as before the stuttering had returned  ! It was definitely working fine before. Ha ha ! My theory had been correct; bottlenecking to do with resolution, however here I had hit an intermittent problem. The Dunia engine was not being consistent in its behaviour. This points to differences in resource allocation each time Dunia starts up. Restarting Windows did not solve the problem, although this could be a problem anywhere in the graphics pipeline from Windows, to Windows 64 bit libraries right along to the Dunia engine itself. Anyway, to restate, this points to inconsistent behaviour by the Dunia engine … on one load you might get great performance, on another it will be different. However I would not call the above a bug just yet, as this appears to happen on lower spec machines (like mine) which are probably guaranteed by Ubisoft to provide a stable gaming experience on the lower FC4 settings. Maybe Dunia is simply having trouble allocating resources ?

So here is where I got the FC4 settings to with the help of RP.

fc4_quality_settings

Altogether quite a frustrating experience. But FC4 is a very innovative game in its game play creativity and with the 64bit Dunia engine creating such an impressive, almost overwhelming video game environment. But I’m glad I managed to get on top of some troubleshooting as it revealed some of what is possibly going on in the background with the Dunia engine.

Moral of story ? Don’t ignore 64bit. It’s different to what we’re used to.

5,407 views
Spread the love

Leave a Reply

Your email address will not be published. Required fields are marked *