Home Risen Risen2 Risen3 Forum English Russian
Username: Password: angemeldet

Not registered? Click here
Picture of the Moment
Shop Live Ticker
Von Deep Silver betriebener Ticker auf Twitter.com zu Risen.

Newest entry:
RisenTicker: Zum Start ins Wochenende haben wir für euch noch ein kleines Video zusammengeschnitten. http://t.co/K5cTJP5A
To the ticker
Zur Zeit sind 0 User online.
278 Visitors today
1.041 Clicks today
9.790.003 Total visitors
50.583.433 Total clicks

30.09.2009 00:06 [Test: Risen (english)] Risen Test: 6. Technical
Risen Test: 1. Gameplay | Risen Test: 2. Story | Risen Test: 3. Interface | Risen Test: 4. Combat | Risen Test: 5. Statements | Risen Test: 6. Technical |

RISEN Test: Technical details


What's this about? In this sub-article, we will present our technical analysis of RISEN. That includes benchmarks as well as and engine properties and settings.

We tried to compile a complete and comprehensive test. But our options were limited due the fact that the test version which Deep Silver provided us with was locked with DRM. Every one of us only got one single, non-revocable activation. That means that each tester could only test one single combination of hardware and operating system. Because of that, we had to cancel all tests with the different graphics cards and CPUs from our private fundus as well as checking if RISEN runs under Linux/Wine or Windows 7 without problems.

Test systems

We had four test version which allowed us to test RISEN on four different systems. Those were:

Component/Tester Don-Esteban foobar Jodob v000nix
CPU Intel Core Duo E6600 (2x2,4 GHz) AMD Phenom II X4 955 BE (4x3,2 GHz) Intel Core 2 Quad Q6600 (4x2,4 GHz) Intel Core 2 Duo T7250 (2x2,0 GHz)
Grafics ATI Radeon 1950 XTX NVidia GTX 260 NVidia GTX 285 NVidia 8400M GT (256MB, Shared Memory 1024MB)
RAM 2 GB DDR2-800 4 GB DDR2-1066 4 GB DDR2-800 2 GB DDR2
OS Windows XP 32bit (SP3) Windows XP 32bit (SP3, PAE) Windows Vista 32bit Windows Vista 32bit

Properties of the engine

Screen Space Ambient Occlusion (SSAO)


A procedure which is implemented as pixel shader and results in a better presentation of shadows. The method takes into account that objects in the scene obstruct the incidence of light. Unwanted side effects are a angle-dependency of the shadows and lights or shadows bleeding into or out from objects. If you notice a small halo around edges in the game, that is caused by SSAO, too.

High Dynamic Range Imaging (HDRI)

E With this technique, the game internally works with more than the usual 256 level of brightness per colour channel. That allows the rendering of scenes with a high dynamic range. A typical example would be a dark cave with an entrance through which bright daylight falls in. Normally, either the entrance would be just whitened out (bloom) or the dark areas of the cave would drown in black. HDRI allows both at the same time. Of course, the engine still has to do a tone-mapping to (optimally) break the image down to the reduced dynamic range of the monitor. HDRI can only be disabled in the INI file and that results in graphical errors, especially with transparent objects like window panes.

Volumetric Lighting


The light cone from a light source in a scene is treated as a transparent object with a real volume (hence the name). By that it can influence the properties of intersected objects, allowing effects like crepuscular rays (also known as godrays). A natural effect which is caused by minor particles (like dust) in the atmosphere and made visible when the sun is partly blocked (i.e. by vegetation or clouds).

Parallax Occlusion Mapping

This allows to add simulated height information to textures without having to create new geometry data. This is done with a so-called displacement map which encodes the height data.

The gamer who is not interested in technical stuff only needs to know that it makes flat structures look more three-dimensional.


Vegetation is rendered by Speedtree. We still noticed some flat surfaces in tree or bushes, turning to the viewing direction of the hero. But the fine tuning is done rather well and the plant look good even in strong wind.

Optional: Anisotropic Filtering / Antialiasing

The anisotropic filtering is changeable in the usual power of two steps and greatly sharpens textures with a diagonal viewing angle.

Antialiasing could not used. Neither by activating it in the driver (CCC for ATI, control panel for NVidia), by renaming the EXE file nor by using external tools like NHancer for NVidia cards. Downsampling was also not possible because the engine refused the oversized resolutions.

Grafics options

The game offers these settings to change its appearance:

Setting Possible Values Comments
Texture Quality Low, Medium, High Textures with lower resolution are less sharp but may help on graphic cards with little video memory.
Texture Filter Linear, 2xAF, 4xAF, 8xAF, 16xAF Linear Texture filtering uses less resources, anisotropic filtering looks better.
Shadow Details Off, Low, Medium, High Deactivating all shadows can greatly improve the performance on slower systems.
Vegetation Details Off, Low, Medium, High Influences the visibility range of the entire vegetation. There is no way to control trees and grass separately.
Effect Quality Low, Middle, High If you experience lags on "special effects" like dustclouds or magic spells, try to reduce this setting.
Viewing Range Low, Medium, High General viewing range; greatly influences the framerate.
Depth of Field Off, On Blurs objects that are farther away. Hides ugly LOD but makes you feel like having myopia.
Schader Quality Low, Medium, High May be interesting on graphic cards with low shader performance.

We made a few screen shots with different settings to illustrate how they influence what the game looks like. Depth of field was always disabled for that because we wanted to show the effects on the detail level in the world and artificial myopia would be counter productive. The system used was the AMD Phenom II X4 955 BE with a NVidia GTX260 graphics card.

Screenshot Settings Average Framerate
Lowest Everything to "Low", shadows and vegetation to "Off" 60 FPS*
Low Everything (incl. shadows and vegetation) to "Low" 60 FPS*
Medium Everything to "Medium", 2xAF 52 FPS
High Everything to "High", 4xAF 46 FPS
Highest Everything to "High", 16xAF 39 FPS
* Limited to 60 FPS by vertical synchronisation (refresh rate of the TFT display)


In order to have a proper comparison of the different systems and settings, we defined the following benchmark: In the harbour city, at noon and with sunny weather, you walk a certain path through the city: From Dick (engl. name: Marek) to Belschwur to Sonja. We chose that route because it proved to be a challenge for the system.

First of all, a general overview over the different systems. All tests were made with a resolution of 1280x1024. We begin with the framerate at maximum settings:

System Minimum Framerate Maximum Framerate Average Framerate
Phenom II X4 955, GTX260 18 FPS 61 FPS 36 FPS
Core2Quad Q6600, GTX285 31 FPS 61 FPS 46 FPS
Core2Duo E6600, Radeon 1950XTX 12 FPS 46 FPS 18 FPS
Core2Duo T7250, GeForce 8400M GT aborted due to no more than 3 FPS

And now as comparison, the values for minimal settings:

System Minimum Framerate Maximum Framerate Average Framerate
Phenom II X4 955, GTX260 46 FPS 61 FPS 58 FPS
Core2Quad Q6600, GTX285 38 FPS 62 FPS 52 FPS
Core2Duo E6600, Radeon 1950XTX 14 FPS 63 FPS 41 FPS
Core2Duo T7250, GeForce 8400M GT 8 FPS 24 FPS 15 FPS

Noteworthy are the very volatile framerate. Partly, our test scenario is to blame because in the outer regions of the city, it is still rather simple and then get more and more demanding as more and more NPCs are to calculate. Especially the CPU is very busy, as further tests showed.

The loading time were also very different on the test systems. In the magnitude of these times (several seconds), we could just manually take the times with a stopwatch. Of course, virus scanner and other background programs generating I/O were disabled.

System Time to start the program* The to load a saved game
Phenom II X4 955, GTX260 37 seconds 17 seconds
Core2Quad Q6600, GTX285 63 seconds 24 seconds
Core2Duo E6600, Radeon 1950XTX 83 seconds No measurement
Core2Duo T7250, GeForce 8400M GT 100 seconds 43 seconds
* taken from activating the EXE file until the main menu appears, logo videos disabled.

The best results were delivered by the Phenom system. But the hard disk of that system had almost ideal conidtions: 1 TB SATA in AHCI mode with NCQ, 7.400 rpm without acustics management, high data density of the individual disks and freshly defragmented. We suppose that significant improvements beyond that can only be achieved by using a RAID 0 (thus sacrificing data safety for throughput), a fast SAS disk or a RAM disk.

Detailed Load Analysis

An often asked question is whether RISEN puts the main load more on the CPU or the GPU and how it profits from CPUs with multiple cores. We made a detailed analysis using the system with the broadest range of results, the Phenom II X4 955.

I/O-Load (Streaming)

The streaming show the typical results of this technology, as can be seen on the left diagram. All data must be transferred from hard disk to memory which also causes significant drops in the framerate. On slower systems, these can easily be severe enough to count as lags/stutter. Remember, the system used had a defragmented SATA disk with 7,400 rpm in AHCI mode, so it was pretty fast.

As you can see on the right picture, this load is greatly reduced when you run the test route a second time. This means that lags are to be expected primarily when you enter a new area (especially by teleporting). As long as you remain in that area, everything comes from the cache and the feared lags are mostly gone.

Graphics Load

To determine the influence of the graphics card, we reduced the resolution on the test system step by step (always keeping maximum details in the settings) and measured the resulting framerates.

Resolution Minimum Framerate Maximum Framerate Average Framerate
1280x1024 19 FPS 61 FPS 38 FPS
1024x786 25 FPS 61 FPS 37 FPS
800x600 28 FPS 61 FPS 41 FPS

If the graphics card was the limiting factor, we would expect a significant raise in the framerate. But as we can see, the gain is very limited. With a resolution of 800x600, the graphics card must only compute 38% of the amount of pixels compared to the original 1280x1024. Yet, the average gain is only 3 fps. Only the lower bound has risen by 9 fps which - in some cases - can make the difference between "playable" and "not playable".

CPU Load

Let's take a closer look at the last remaining bottleneck - the CPU. In the left diagram, we can see clearly that the load RISEN puts on the CPU is not equally distributed across the cores. One single core carries the main load while the others are more or less bored with an utilization that most of the time remains below 50%. The main thread also is always very close to the maximum capability of the core it runs on. That core is almost overworked, as the peaks in the CPU waiting queue (white line) confirm. These are threads waiting to be executed. Even though the CPU of this system has 4 cores with 3.2 GHz each, the CPU is the limiting factor in the system and the explanation of the rather low framerate on maximum setting.

The Intel quad processor of the other test system, which can be roughly compared in computing power to the Phenom despite its lower frequency proved less problematic. But this may also be attributed to the more powerful graphics adapter.

Core Usage

To verify our theory that RISEN has no signification quad core optimisation, we made another test in which we gradually reduced the number of cores on which RISEN was allowed to run. As expected, we notice a measurable and sensible performance boost when going from single to dual core. But beyond that, there is no noticeable change in the framerate. The variations are below the accuracy of measurement.

We can conclude that RISEN is unfit for quad cores.

PhysX Problems

We got astonishing results when we tried to determine whether - and if yes how much - RISEN profits from the PhysX acceleration of NVidia GPUs. We expected either no noticeable performance gain in case RISEN did not utilize the GPU acceleration or a relief of load on the CPU in case it did - since that is the purpose of letting the graphics card do the physics.

But in fact we found out that activating the GPU acceleration for PhysX makes you loose a few frames per second. The mainboard of the test system had a NVidia chipset with an onboard graphics chip (GeForce 8200). Since that chip was not used otherwise, it was standing to reason to transfer all PhysX calculations to that chip, thus reducing the load on both CPU and GPU. But that idea was counter-productive. As you can see on the diagram, it lead to frame drops down to 19 FPS (also see general system performance comparison above).

The CPU load reflects that. After we disabled the PhysX acceleration completely in the NVidia control panel, the load on the main thread significantly dropped (though it was still rather high).

Paradoxically, using the "acceleration" of PhysX calculations which was supposed to reduce CPU load, in fact puts more work load on the already overburdened main thread. Hence, disabling PhysX should give you a few fps.

RAM Usage

Looking back to Gothic 3 and its great hunger for RAM at that time, another interesting question is the RAM usage of RISEN.

As to be expected (the world is much smaller now after all), the game is rather ordinary in that regard. The consumption of RAM never crossed the 1 GB limit.

If you cannot read the german diagram labels: The resolution and AF should be clear, the rest are the settings, always everything to "Niedrig (Low)", "Mittel (Medium)" and "Hoch (High)".

System Recommendations

So. At lot of info. But how does the optimal PC for RISEN look like? A specific system configuration is influenced by a great deal of parameters and some things are highly subjective. For example, Don-Esteban thought the game to run sufficiently smooth on his system. He was surprised when he found out that it was only running with average 17 fps. But based on our analysis, we can give a few general recommendations.

Graphics Card

Not much to consider here. If the card you have or want to buy can display the games of the last two years in a decent quality at your desired resolution, then it should have no trouble with RISEN, too.

Particularly, it is unimportant whether you choose ATI or NVidia. RISEN uses the PhysX API for physical calculation but the "acceleration" that NVidia cards offer can be safely disabled. ATI owners who want to simulate RISEN with GPU-accelerated PhysX can always run Prime95 in the background.


RISEN always remains below 1 GB. To that comes the system itself, so if you have today's usual amount of 2 GB, you should be just fine. More RAM does not hurt but will not help either.

Except of course if you want to copy RISEN to a ramdisk every time and run it from there to completely eliminate the streaming lags.


If your budget leaves you the choice between a dual core with a high frequency and an equally expensive quad core with a lower frequency, we would recommend you choose the dual core. RISEN proofs (in this case, we have to say "sadly") to be an old-fashioned game and profits more from GHz than from cores. Intel or AMD should make no big difference. In the combination of CPU and corresponding mainboard, both architectures can be roughly compared in the regard of performance per Euro. If you are not interested in RISEN alone, you might still go for a quad core however, since other applications and games may profit from it.

Off the hook should be those lucky guys who can afford a Core i5/i7 which can use its integrated turbo boost to raise the frequency of one core if the others are working below capacity.


RISEN creates two subdirectories in its installation directory: "bin" and "data". The first one contains the binaries (EXE and DLLs), the latter one the PAKs with the game data as well as some INIs and videos. In the INI files one can disable the logo videos, tweak the LOD and manipulate a few physics settings (collision groups).

Saves games are stored under %userprofile%\My Documents\Risen\SaveGames for Windows XP and %userprofile%\Saved Games\Risen\SaveGames for Windows Vista. The path can be changed in the registry under HKCU\Software\Deep Silver\Risen

Screenshots can be found in the directory %userprofile%\Local Settings\Application Data\Risen in which the configuration files (very modern as XML) as stored as well.

Streamingsystem / LOD

The only occasions in which you see a loading screen in RISEN are at game start, when loading a savegame and when teleporting to a new region. A streaming system makes the world seamless. You can explore everything and no matter if you enter a house or a dungeon, you are never interrupted by a loading screen. The meshes and textures that the game requires are loaded on demand. The game uses a LOD (level of detail) system that replaces textures from far away object with a copy of a lower resolution. In that regard, the distance view resembles Gothic 3. Objects at greater distance are replaced by 2D bitmaps. The transition between higher and lower detail is very good in most cases (no sharp cut-off as in Gothic 3). But the display of far-away vegetation is not as good. Many of the 2D billboards that replace the real trees have a very low resolution and lack sharpness (see screenshot). Maybe depth of field can hide this ugliness for you, if you can live with an artificial myopia. Inevitable with the chosen streaming method are drops in the framerate when the game loads new data from the disk. If you do not have a comfortable safety margin here, these can easily be regarded as lags. However, they are not as extreme as they were in Gothic 3. The engine has been given several optimisations which greatly increase its streaming performance.


The physics are mainly important during and right after combat, when you enemy dies. The dying animations are mostly realistic. The jelly-corpses from Gothic 3 belong to the past. But the flight properties of some opponents still require some tuning. Sometimes, a wolf can fly up to 20 metres through the air and slide over the floor for way to long.


The animations in RISEN are purely handmade. No motion capturing was used. Where this was an enhancement and where not shall be explained with the following examples:

A highligh are the combat animations. As the player progresses through the different skill levels, his combat moves become smoother, more mature and diverse. There are many small details that enhance the feeling for the world. Boars for example wallow in the dust and have an animatied snout. Gnomes are getting wind with waving nostrils and wiggle their toes when sitting in front of a camp fire.

Less pleasing are the animations of NPCs during dialogues. Details like animated fingers are present but all in all, the total repertoire of moves is very limited which makes you notice many repetitions. Individual animations are rare and practically no emotions are shown on the faces. The leap animations also look a bit stiff. The hero does not make a dive roll anymore when he learned acrobatics. But he rolls over skillfully when jumping from greater height or - if he is still inflexible - cushions the impact with his hand.

AI / Behaviour

When it comes to the NPCs, many methods from Gothic 1 and 2 were used for RISEN. Theft is only noticed if they see you doing it. You won't be automatically suspected after a certain number of thefts. That means thieves will have much work to do in RISEN and can try their luck on many hand-fill chests.

Drawing a weapon leads to the well known reaction and the NPCs react on the different guild membership. They also can do almost anything that the hero can and if you attack them from the supposed safety of a rooftop, they will just climb up there as well. However, if you get caught stealing and are beaten down by the home owner, you might notice the strange situation that he does not loot your body (not even the things you stole from him). Instead, a total stranger comes in from the street and takes your money.

Sleeping in other people's beds may be considered offensive by some NPCs. Others will just let take a nap. In the gutter of the harbour city, it is easy to find a resting place while in other areas, you will hear an angry: "Get out of my bed!". Another factor is your health state. A healthy hero will be denied a rest much more often than a heavily injured one.

The behaviour of the different character seems to depend on faction membership and solved quests. The effective combat strength of the hero is rather unimportant. A hero at the beginning of the game who has been given level 40 with 200 strength, sword combat level 10, captain's armour and demon blade by cheats will still be threatened by the poorest peasant with an old stick for a weapon if he draws his blade. Of course, that is a situation you will not encounter during normal play. But if you gain the afore mentioned skills and items on the normal course of the game, then even seasoned city guards and order warriors won't object to a drawn weapon.

Obvious AI problem, for example with pathfinding, were extremely rare. It happened a few time that an opponent did not react to ranged attacks with bow or magic from a hidden spot and just let himself get killed. But that were very rare exceptions.


As far as the mouse controls are converned, RISEN had no noteworthy problems. Combat controls via mouse inevitably lead to button smashing, however. You have to train yourself arduously not to do that since it does not help you (after the first few easy tutorial monsters). Still, during a hectic combat, you drop back into old behaviour and start smashing your mouse buttons. Except for that, the hero react mostly as commanded. Although there are some annoyingly late reactions. For example, when you want to put away your weapon after combat, it may happen that you think your command got lost and hit the key again. As a result, the hero will shortly after holster his weapon and immediately draw again.

A pure keyboard control is not possible. You can browse through the inventory with the cursor keys (which still make the hero move so be careful not to guide him down a cliff). But there seems to be no keybinding for using (equipping or consuming) a selected item. Only the left mouse button is accepted here. Furthermore, there are no keys to control the pitch of the camera (see screenshot with all possible key bindings). This also can also be done with the mouse. If you prefer a pure keyboard control, you can only try your luck with an external action mapping (i.e. with AutoHotkey).

Some keys could not be remapped and we had to use the default here. On the screenshot, those can be identified by the closed lock symbol. We saw no reason whatsoever why quickload and quicksave were mapped to keys directly side by side. It happened quite often that we hit the wrong key and loaded an old savegame instead of saving the arduously achieved game progress.

It is also not possible to use the assigned action keys (i.e. WASD) or the mouse wheel to select dialogue options. This only works with the cursor keys and ENTER. If you use WASD, you have to move your hand all over your keyboard which completely defeats the purpose.

Weather System

Special praise goes to the dynamic weather system. There are many different weather setting which in conjunction with the daytime influence the entire appearance of a scene. While the forest may be bright and full of sunlight at one time, it can turn into a pitchblack darkness during a nightly thunderstorm which will only be illuminated by the random lightning. Storms produce sheet lighting in the clouds and on a foggy day, everything is pale and grey. Since the sky is no texture but calculated procedurally, you probably will never see the exact same cloud formation twice.

We put together some screenshots to show a few weather settings. They were all taken at the same place.

Music System / Sound

The transitions from one music zone to another overlap now. This prevents that you hear constant changes in the music because you coincidentally walk on the invisible transition line. Let's take the bandit camp as an example. You enter the swamp by a footbridge. When you come from the island, the music you hear is "The Island". It will play to the end of that bridge. Then it will change to "Don Camp". When you turn around, this new theme will accompany you back all the way on the bridge until the other end. There it changes back to "The Island". Additionally, the music pieces blend into each other by defined transition samples which conceal the change rather well.

Note: On the screenshot, we only focussed on the bridge for easier explanation. Of course, it also works when you go through the mud.

The other environmental sounds are quite good. And yes, waterfalls do have a sound now. EAX is not supported but few games of the last two years do that. The speaker configuration is taken from the system control panel but whether or not real 5.1- or 7.1- surround sound systems are supported, we could not tell due to missing hardware.

  written by foobar