Taking the new model out for a spin
Yerli said that Crytek dedicated a pair of programmers to implementing the Shader Model 3.0 code path in Far Cry, and he said the entire retrofit took three to four weeks to complete. Obviously, implementing Shader Model 3.0 was more complicated than just ticking a checkbox for a new render target in a compiler, but it didn't require a rewrite of the game engine. Some of the changes Crytek made took only a few hours, while other elements of the retrofit took a week or two to complete. In fact, after the first two weeks of effort, Crytek had the initial version of the Shader Model 3.0 code path up and running.
Far Cry, of course, started out with a fairly sophisticated game engine that took advantage of Shader Model 2.0 to deliver per-pixel lighting. Yerli said Shader Model 3.0 doesn't bring any change in visual fidelity, just better performance. In fact, he emphasized the point repeatedly during our conversation. In the case of pixel shaders, lighting some objects covered with shader-based materials using Shader Model 2.0 required multiple passesone pass per light. If the object were affected by three lights, the pixel would have to take three passes through the rendering pipeline. With Shader Model 3.0, Crytek was able to consolidate its per-pixel lighting work so that up to four lights can be rendered in a single pass.
Crytek's revamped pixel shaders use branching and looping in order to calculate the effects of multiple lights in a single pass, but the instruction lengths of those shaders don't approach the 96-instruction limits of SM 2.0 pixel shaders. Instead, Yerli stated that the primary benefits of SM3.0 pixel shaders are more constants, tables, and the like, which lead to better performance. The effects you'll see in current games running on today's hardware, in his estimation, can be implemented within the 96-instruction limits of SM2.0; the longer instruction lengths in Shader Model 3.0 won't be practical until the next generation of graphics hardware arrives. For now, he said, SM2.0 will allow the creation of any effect developers want.
Beyond pixel shaders, Far Cry 1.2 uses another Shader Model 3.0 feature, geometry instancing, to accelerate game performance. With geometry instancing, the Far Cry engine can place multiple copies of the same 3D model onscreen at once, each with different attributes, using only one draw call. The game engine automatically uses geometry instancing whenever copies of the same static mesh appear at once. Although this capability primarily provides benefits in areas with lots of grass and foliage, the feature isn't linked to a single model type. In fact, like the pixel shader enhancements, geometry instancing is a game-wide enhancement that requires no change to the game content.
I asked Yerli about the image quality problems on GeForce 6800 cards in version 1.1 of Far Cry. He dismissed those as "just rendering issues" and said that the Shader Model 3.0 path cleaned up those problems. The SM3.0 path does include a mix of FP16 and FP32 datatypes on GeForce 6800 cards for the sake of performance, but Yerli said Crytek never sacrificed image quality for performance, a move that's "not an option" for them. Out of curiosity, I also asked whether he knew of any instances where the use of FP24 precision on ATI cards caused visual artifacts, and he said no.
The skinny on quick-save
As we wrapped things up, I veered off the path a bit to ask another question on everyone's mind: Will Far Cry 1.2 include a revamped save-game system? Yerli said there will be two versions of the 1.2 patch released. Crytek hopes to release the first version within the next week or so. That initial version of the 1.2 patch will not include a quick-save function. Some time later, Crytek plans to release a version 1.2 patch with quick-save enabled. Yerli said building quick-save into Far Cry has been a painful process, because the game wasn't designed with this feature in mind. However, Crytek is fixing bugs daily, and the quick-save patch will be released once all the bugs are squashed.
15 comments — Last by hmmm at 9:31 PM on 07/05/04
|Are retail Radeon R9 290X cards slower than press samples?We take a look||154|
|Delving deeper into AMD's Mantle APIDispatches from APU13||191|
|AMD's Radeon R9 270 graphics card reviewedPitcairn again||77|
|Nvidia's GeForce GTX 780 Ti graphics card reviewedNow witness the firepower of this fully armed and operational battle station||284|
|AMD's Radeon R9 290 graphics card reviewedHope you didn't buy the X yet||308|
|AMD's Radeon R9 290X graphics card reviewedHawaii erupts||653|
|Not-quite-live blog: panel discussion with John Carmack, Tim Sweeney, Johan AnderssonThree game engine gurus talk about PC gaming tech||37|
|Live blog from day two of Nvidia's Montreal 2013 eventThis one should be interesting||32|
|Are retail Radeon R9 290X cards slower than press samples?||154|
|Valve joins the Linux Foundation||12|
|USB group designing slim, orientation-independent connector||47|
|Cherry intros MX RGB key switch; first keyboard due from Corsair||49|
|MSI's latest Z87 motherboard, GeForce GTX 760 graphics card have Mini-ITX dimensions||29|
|Tuesday Night Shortbread||20|
|HP unveils two Tegra 4-powered tablets||50|
|Unofficial AMD roadmap details desktop plans through 2015||130|
|It's official: Toshiba will snatch up OCZ's SSD business||37|