Rendering information - anti-aliasing, overheating, etc...

For discussion about Trine 2, released in December 2011 on Windows, Mac, Xbox, PlayStation Network and later on Linux and Wii U.
User avatar
Posts: 98
Joined: Mon Mar 17, 2014 11:55 am

Rendering information - anti-aliasing, overheating, etc...

Postby RiikkaFB » Tue May 27, 2014 11:55 am

This post was originally posted by Juha on the old Steam's forums on 2011, but I decided to copy it here as it still has a lot of useful information.

This post will give some information on how our rendering works, how to tweak settings and how to troubleshoot some potential problems. There are references to manually editing a configuration file. This can be found from %APPDATA%/Trine2/options.txt. You can edit it by just copy-pasting that path to explorer.

GPU Overheating

Trine 2 is very GPU heavy game. In practice we are never CPU limited, so we are giving the GPU a run for it's money. For some systems, it seems that graphics card will heat up more than in most other games. This is not a problem in our code. We are trying to render our graphics as efficiently as possible, and how each GPU reacts to this load is system specific and we have no control over it. It is hardware and it's drivers responsibility to deal with heat and noise issues. As a first step it's advisable to disable all overclocking features if such are turned on.

There are a few things you can try to reduce the generated heat. It all comes down to artificially limiting the frame rate and thus giving GPU some time to cool down between frames.

Easiest option is to enable vertical sync from the launcher, and make sure game would be running faster than your monitors refresh rate (60 in most cases). Easiest way to gain more performance is to reduce anti-aliasing level (please see section Anti-aliasing).

Alternatively you can enable input lag reduction (please see section Input Lag). Name of the option doesn't sound very intuitive, but as it will reduce your frame rate it will help with cooling problems. This setting used to default on in Trine 1 and early Trine 2 beta.

In the future we are likely to add manual frame rate cap feature.


If you have performance problems, please check the Anti-aliasing section below. Most performance problems are result of too high SSAA mode being used.


There are two approaches to anti-aliasing in Trine 2, FXAA and supersampling (SSAA). In higher anti-aliasing modes, we use both of these techniques together. Due to how our rendering works, we cannot use traditional MSAA.

FXAA is a post processing filter that 'intelligently' blurs the image trying to get rid of jaggies (and high contrast pixel differencies). It gives really good results for the amount of computing power it uses. However, as it doesn't provide any extra information it cannot address sub-pixel errors.

Supersampling, as the name suggests, improves image quality by rendering more than one pixel worth of data for each pixel that is displayed on monitor. How much extra data there are depends on SSAA mode. As this is a brute-force approach, it is very expensive from performance point of view. If you have performance problems, the first thing to try is to reduce SSAA level from the launcher.

For example for 1920x1080 (1080p) resolution

2xSSAA will render 2550 x 1430 image, apply FXAA and scale it back to 1920x1080.
3xSSAA will render 3180 x 1790 image, apply FXAA and scale it back to 1920x1080.
4xSSAA will render 3840 x 2160 image, apply FXAA and scale it back to 1920x1080.

It is possible to use even higher SSAA modes, but that requires editing %APPDATA%/Trine2/options.txt and changing AntiAliasSamples to higher value (up to 16). Please note that this requires a huge amount of GPU power (1080p with 16x SSAA means rendering 7680x4320 image) and a lot of memory, and for this reason it is not exposed in the launcher.

It is also possible to use SSAA without FXAA by changing
setOption(renderingModule, "PostProcessAntiAliasing", true)
setOption(renderingModule, "PostProcessAntiAliasing", false)
from %APPDATA%/Trine2/options.txt.

Input Lag

Input lag is caused by buffering several frames worth of rendering commands. By default, Direct3D will allow buffering of 3 frames worth of data. This causes a very noticeable delay, especially on the lagging mouse cursor. Default behavior in Trine 2 is to limit this buffering to 2 frames, which allows full speed GPU rendering without introducing too much lag. If you want to reduce this lag even more, you can change line
setOption(renderingModule, "ReduceInputLag", false)
setOption(renderingModule, "ReduceInputLag", true)
from %APPDATA%/Trine2/options.txt.

This will reduce frame rate somewhat, but it can be useful on lower end systems where it will improve the responsiveness. It will also help to keep your GPU cooler and quieter. This option is not recommended with multi gpu's or with vertical sync. Our vertical sync option will enable triple buffering and this option goes against the benefits gained from that.

Stereoscopic rendering

Currently we support NVIDIA 3D Vision natively. It is likely that we are going to add some other output options later with patches, but we cannot commit to any time frames yet.

3D Vision rendering should get enabled automatically if the game detects valid drivers. If you have 3D Vision on, just launch the game and it should run in 3d. Note that you may have to modify the refresh rate settings from the launcher on some setups to get it working properly (use 120Hz on 120Hz monitors, for example). Currently only 3D Vision hot key that is recognised by the game is stereo on/off toggle (CTRL-T).

In visual settings there are sliders which allow you to tweak separation, convergence and UI depth to suit your preferences.

We render separate views for both eyes, so stereo rendering will double the graphics processing requirements. If you have performance problems, the first step is to reduce anti-aliasing level (please see section Anti-aliasing).

Your friendly graphics programmer

Posts: 81
Joined: Fri Jul 06, 2012 2:16 am

Re: Rendering information - anti-aliasing, overheating, etc.

Postby spectatorx » Wed May 28, 2014 12:11 pm

I didn't know trine 2 has so many levels of ssaa. It is sick level and it kills performance totally xD "Just" 4 samples kill performance even on 780ti and other performance beasts.

When i've read this post i just had to taste this insanity xD And this is total overkill, with 16 samples i have astonishing average 2fps :D Overall i'm against using aa in most games as it makes no difference or really slighty one but downgrades performance a lot, especially such demanding methods as ssaa, msaa, fsaa, csaa, etc.

I took two screenshots, one without aa and one with forced 16 samples ( setOption(renderingModule, "AntiAliasSamples", 16) ) and i barely can see the difference. I toggled to fullscreen and then after long looking for differences i found the most noticeable difference on ropes xD

Here are the screenshots if anyone want to compare:
x16 samples: ... 7FA154082/
No AA: ... 8EA2E9EB9/
Both taken in 1080p resolution.
An interesting blog that i've found out some time ago:

Posts: 65
Joined: Mon Dec 19, 2011 8:28 pm

Re: Rendering information - anti-aliasing, overheating, etc.

Postby Borc » Fri May 30, 2014 1:36 am

The difference is huge in your samples and even more in motion. A 780 Ti is easily capable of 4xSSAA at 1920x1080 and is able to hold 60+ fps in Trine 2. To be honest saying AA makes no difference is nonsense.

Posts: 7
Joined: Tue Jul 01, 2014 11:01 am

Re: Rendering information - anti-aliasing, overheating, etc.

Postby wellspokenman » Mon Jul 07, 2014 12:05 pm

some more details on the SSAA from Juha in an interview about the Trine 2 engine,8662 ... ting/News/

Posts: 81
Joined: Fri Jul 06, 2012 2:16 am

Re: Rendering information - anti-aliasing, overheating, etc.

Postby spectatorx » Wed Jul 09, 2014 12:43 am

wellspokenman wrote:some more details on the SSAA from Juha in an interview about the Trine 2 engine,8662 ... ting/News/

Thx for the link, nice article.
Journalist imo asked a bit too much about versions numbers but also asked about some interesting details. It was pleasure to read it and i was a bit sad it is too short :-)

Part about dx version is pretty important. DX11.2 brings some nice features for stereoscopic 3d, dx10 brought a lot of nice options in rendering, dx11 has also few things which could improve trine performance in some ways, but..... all these are:
1. limited to windows only
2. and even more, limited only to specific versions of windows os. Complete abandoning elder versions of windows is never good idea.
It is always better to choose the most popular api which will give opportunity to release the game to as many players as possible. To be honest i wonder why they didn't go with opengl.

Personally i'm CONSIDERING to create a game and as "api" use webgl to make the game multiplatform and to make it protected from piracy as forcing player to play the game via webbrowser is sort of always-connected-to-internet drm.
An interesting blog that i've found out some time ago:

Return to “Trine 2”

Who is online

Users browsing this forum: No registered users and 5 guests