Very hot

[Dr.Disaster]

Did you clean your air vents, Dr. Disaster?

Huh? Did i say i got a problem with the game? Can't recall i did since release.
Once during beta, yes, but that issue got fixed, so no complains left here.

We are doing a method of elimination.

"We"? I haven't seen anything from you in that regard. Actually i haven't seen anything in that regard since the beta ended.

If it isn't all the other problems, and there is still a framerate drop, then that implies that its the engine.

Since you cited method of elimination: it's user should deliver more than just stating "the engine is the problem" if he wants to be taken seriously. A dedicated researcher would build a map with the editor similar to one of the more demanding maps of the main campaign and then check when framerate drops occure by adding/removing stuff to/from it. This way AH would get detailed input to look into things which is far more valueable and helpful than "the engine is the problem".

[Palandus]

You mentioned earlier that you had a 20 FPS drop in at least one outdoor zone, while everywhere else you get 60+ FPS. If you can't get consistent 60 FPS with FAR exceeding recommended specs, then that implies there is a problem. I'm asking if you cleaned your vents and thus get 60 FPS in that one bad zone.

Oh I also get lowered framerates from outdoor zones but I didn't bother mentioning its because my gaming rig is quite old (over 3 years now) and is suffering from heating problems. But even I get FAR better framerates in dungeons and retched FPS in outdoor sections.

So are you saying that you consistently get 60 or more FPS EVERYWHERE in the GAME at ALL times? If you don't, and you far exceed recommended specs, then what do you think is the problem that is affecting your rig? Dust? Drivers? Engine issues?

Recreating a map wouldn't necessarily help. If its a matter of objects on screen, reduce the number of objects. That's like giving a bandaid to a gut wound; or in this case removing objects to make up for problems with the engine.

Here is the thing. If people can get consistently high 60+ FPS in games like Tomb Raider, Crysis 3, or other extremely demanding graphical titles at max settings, but can't do the same here, then that means its an engine problem. If a person had consistently bad framerates for both cases, then it might not be the engine's fault, and it may be the user's fault. But when the user can get maximum performance with stable 60+ framerate in games that require powerhouse style computers but can't get it here, it is the engine's fault.

Why are you so against it being the engine's fault? Its like you are trying to shove an important issue under the rug, because it is "inconvenient" or that AH can do no wrong? Wouldn't it be in AH's best interest to know of a major problem with their engine so that they could do something about it, rather than have their most important fans bury critical issues so that they never know about them?

[Dr.Disaster]

Wouldn't it be in AH's best interest to know of a major problem with their engine so that they could do something about it, rather than have their most important fans bury critical issues so that they never know about them?

Ah, do i see a glimpse of understanding here? THIS is the whole point the entire "poor performance/engine" discussion is about and what i try to iron out since i joined beta. IF you really want to help AH solve an issue you need to provide more than this ongoing generalized "bad engine" "poor optimization" talk. Sure you can go on with it, call the engine badly optimized but that won't provide the tiniest bit of information to track and solve a problem.

Let's take a look at badhabit's conclusion that the engine is not multithreading / not a multicore engine. By simply looking at windows task manager when running LoG2 the claim "not multithreading" seems outright false. Would the game in fact be "not multithreading" it would never ever run on more then 1 core respectively never be "split" by the OS over multiple cores. Yet the observation that there is no further performace increase when 3+ cores are in use might indeed indicate that the engine does not really support multiple cores.

I agree that the engine prolly can do better und very likely will in the near future. AH already said that they will look into performace in general before they tackle any port towards other OSes but how much increase can be gained nobody can tell yet.

[Palandus]

Multithreading is about threads, not cores. You are thinking of Multicore support, where it runs on multiple cores. Multithreading and Multicore are two VERY different issues. Most computer cores can have more than one thread per core. Most computers these days have at least two cores. A program can support multi-core without supporting multi-thread. At the same time a program can support multi-thread without supporting multi-core. Most games support dual core or multi-core support, but very few games offer multi-threading support, mostly because threading a game can be a nightmare code-wise. Also, for reference, when people talk about multi-core support they are generally implying 3+ cores, because people think of cores in three ways: Single Core, Dual Core, Multi-Core. CPU Cores are hardware, whereas CPU Threads are software.

Link explaining threads = http://en.wikipedia.org/wiki/Thread_(computing) [They are controlled and created by the Operating System, which is software]

For example: I have a Quad Core computer with 2 threads per core. I have 4 cores and 8 threads.

Now, as to the engine optimizations, it is clear outdoor sections are the culprit. What is plausible is that AH is using the same rendering Engine that GR1 used, and therefore any flaws in that engine would have been copied over to GR2. Now, in Dungeon Sections, there is no noticeable problems, however in outdoor sections there is problems. So a "critical flaw" in the old rendering engine might not have been detected because the game in GR1 was all dungeon based with no outdoor sections. So, it is likely that they would find the problem by looking at any code they borrowed from GR1 from the Rendering Engine.

If its a matter of objects, the question is why are the objects consuming so many resources? If its not the objects, but it is the water, why is the water consuming so many resources? If its not the water, then what about the fog effects (my worst framerates was in the Graveyard), why is the fog effects consuming so many resources? Or is it a combination of these? Or is it the skybox?

The best way for AH to determine the problem is to input "debug" code into specific parts of the renderer and have that information outputted to a file. Alternatively, AH did mention in a blog that they were using a program to note down the resources being used in a section; they could use that to pinpoint specific issues. Alternatively, perhaps some exception handling may be appropriate. Or perhaps the problem is in the Main Event Loop, and thus they should implement debug code for loops to try and find bottlenecks. There are ways for them to figure out answers far more easily than for us to do experiments and far more quickly at that.

[petri]

As to why outdoor scenes are heavier than indoor scenes, the simple answer is that outdoors scenes are far more complex to render: view distances are much bigger, outdoor scenes have more decorative objects, shadow caster need to be rendered to shadow maps for directional lights (sun/moon), objects need to be rendered to reflection maps for water reflections, fog particles in the swamp...

The nature of outdoor scenes is that they need more processing power and if the hardware is low end it can cause decrease in frame rates. I already spent considerable amount of time optimizing the engine during beta, and unfortunately there are no easy low hanging fruits anymore. Of course with a lot of work I'm sure more perf could be gained, but as always it's a matter of prioritizing the work. With recommended spec systems the game already runs pretty sweet, and for low end systems there's even the Low Quality rendering mode which will make the game run even on quite old hardware.

[Palandus]

What about including an option to remove dynamic shadowing? This would be the shadows cast by light sources whether that it the moon, sun, or torches. Fixed shadows, such as those on character models would likely be unaffected. If dynamic shadows were disabled, those with less than stellar machines could get a massive framerate boost in outdoors.

In Skyrim, with particular tweaking in the SkyrimPrefs.ini file you could disable most dynamic shadows completely, which a lot of people did if they couldn't get shadows at high (as shadows lower than high looked terrible). Would setting shadows to 0, in the ini file do this, petri?

[petri]

What about including an option to remove dynamic shadowing? This would be the shadows cast by light sources whether that it the moon, sun, or torches. Fixed shadows, such as those on character models would likely be unaffected. If dynamic shadows were disabled, those with less than stellar machines could get a massive framerate boost in outdoors.

Low Quality rendering mode turns off dynamic shadows.

[badhabit]

As to why outdoor scenes are heavier than indoor scenes, the simple answer is that outdoors scenes are far more complex to render: view distances are much bigger, outdoor scenes have more decorative objects, shadow caster need to be rendered to shadow maps for directional lights (sun/moon), objects need to be rendered to reflection maps for water reflections, fog particles in the swamp...

The nature of outdoor scenes is that they need more processing power and if the hardware is low end it can cause decrease in frame rates. I already spent considerable amount of time optimizing the engine during beta, and unfortunately there are no easy low hanging fruits anymore. Of course with a lot of work I'm sure more perf could be gained, but as always it's a matter of prioritizing the work. With recommended spec systems the game already runs pretty sweet, and for low end systems there's even the Low Quality rendering mode which will make the game run even on quite old hardware.

Hi Petri, thanks for finally responding.
But "With recommended spec systems the game already runs pretty sweet," is not true as even Dr. Disasters rig which is way beyond the recommendation drops in outside spots below 60fps. Also, what is about the CPU boundedness in spots while only utilizing 1.68 cores? I noticed the same for my system... which is in conflict with your recommendation for a multi core system as optimum. It seems the engine makes not use of multi-core ressources while being CPU bound... which I find very problematic (even misleading or a performance bug) as you recommend 4x multicore systems for a optimal experience with LOG2. It seems you should have recommend max. dual core + 6GHz CPUs. :/

Also, I support Palandus request for more options, currently the GFX options are not offering enough dynamic in FPS to make the game playable everywhere, even for medium rigs.

And as last remark, consider releasing your profiler to the community that we can better analyze the performance behaviour and track down hopefully the reason and which part of the engine is currently over-demanding.

[Dr.Disaster]

As to why outdoor scenes are heavier than indoor scenes, the simple answer is that outdoors scenes are far more complex to render: view distances are much bigger, outdoor scenes have more decorative objects, shadow caster need to be rendered to shadow maps for directional lights (sun/moon), objects need to be rendered to reflection maps for water reflections, fog particles in the swamp...

Aye it's the combination of things that increase the rendering load: outside+shadows+reflection+distance results in lots of rendering to do.

With a quick and dirty thread counter tool provided by vlzl (too bad it's not online anymore) we found that the more complex a scene is the more threads are spawned by the engine. For example in the starting cage the tool counted a total of 11 threads while somewhere in the Forgotten River it counted 15. Yet the number of cores in use (4 on my i7) stayed the same although there were more available. Perhaps when those additional spawned threads could be spread out more over the available cores things would ease a lot.

[petri]

Outdoor scenes in Grimrock 2 are almost always rendering bound. Using DirectX and OpenGL drawing commands have to be submitted in a single thread -- so regardless of the number of cores there's a limit how many draw calls can be submitted per frame. Grimrock 2 engine uses DirectX9 on the PC, so that the game runs on older hardware. Unfortunately DirectX9 has a pretty high shader constant setup and draw call cost. We can push about 4000 calls per frame before the frame rate drops below 60. I suppose rewriting the renderer for DirectX11+ would help (it has lower draw call cost from what I heard) but it would be a very large amount of work. So what's left is to try to minimize the number of draw calls. Rendering less would help, but it's hard to do without losing visual quality, e.g. reducing view distances, shadows. The way levels are designed also has a pretty big impact on performance, for example forest scenes usually have horrible occluders (trees with lots of holes in the foliage) are problematic. We wanted to make the forests appear open rather than making the player feel surrounded by "opaque leafy walls", even when it could mean a small frame rate drop here and there. It's about finding the right balance between perf and visual quality.

Hope this clears things up!