TES V: Skyrim

Well, damnit, hit a show stopper of a bug. Was doing the Dark Brotherhood quests last night, got to the point where i have to chase after Cicero and Arnbjorn up to Dawnstar, and I'm stuck now because Arnbjorn is sitting in a pool of blood and won't interact with me, and despite reading Cicero's journal the door to the sanctuary won't offer me the correct option to enter. Anyone know of a fix to this?


I'm in a similar state with the Galdur amulet quest, quest tells me I've got to read so and so's notes, I have them, read them and I have the amulet piece from the dungeon, nothing lets me move the quest forwards.

Last night I tried to use the console to advance the quest to the appropriate point, but although the reported quest state changed, my quest target is still underground in the middle of nowhere and my log didn't change.

You can give the console a shot to see if you can get things back in a decent state, but I couldn't get it working for me.
 
I have found you almost always can get the quest working again.

Sometimes you have to go back to the beginning, sometimes a bit to the future. Combining the needed unlock commands and setstage commands usually will do the trick.
 
Well, interestingly enough I continued playing my assassin, going a bit further in the main questline last night. Swung by the Dawnstar sanctuary again and suddenly I could talk to Arnbjorn and finished that quest. Weird.
 
How can Skyrim be so unoptimized? Modders do better job than Bethesda
A new mod just came out, giving up to 40% performance increase on CPU-dependent situations, like in big cities like infamous Markath and Whiterun.
People who previously had around 20-25 FPS now get closer to 30-37 FPS. In villages like Riverwood, the FPS is a lot higher as well.

This mod does this by "rewriting some x87 FPU code and inlining a whole ton of useless getter functions along the critical paths because the developers at Bethesda, for some reason, compiled the game without using any of the optimization flags for release build."
"Part of the acceleration is changing un-optimized FPU code from basic x87 instructions (mid 1990s) to SSE (1999), which was introduced with the Pentium III, and which modern compilers generally optimize for you unless you specifically tell them not to."
 
Just tried this, looking down from Dragonsreach I get a 20% frame rate increase.

EDIT: DON"T USE THIS....

Reading further, this seams to cause scripting problems....
 
Last edited by a moderator:
Just tried this, looking down from Dragonsreach I get a 20% frame rate increase.

EDIT: DON"T USE THIS....

Reading further, this seams to cause scripting problems....

That's what I gather also. It's a VERY nice performance boost but at the cost of game progression.

maybe they'll work out the bugs soon but unless you don't care about quest progression, you might want to hold off.

In other news, new nvidia drivers that provide better indoor performance are out.
 
That's what I gather also. It's a VERY nice performance boost but at the cost of game progression.

maybe they'll work out the bugs soon but unless you don't care about quest progression, you might want to hold off.

In other news, new nvidia drivers that provide better indoor performance are out.

It seems to me that this performance mod has actually been put out in order to prompt Bethseda into action. It should be embarrassing to them that a simple compiler option could increase performance so massively.

This mod was done by a guy hacking a library to intercept and replace a few common program calls. With access to the source code and the ability to recompile the whole executable, he's estimating an easy one hundred percent speed up for the most minimal of work. Bethseda should put this out as soon as possible.
 
Yes, the mod itself only scratches the surface of the problem -- much more can be achieved by full recompiling and some manual code tweaks.
 
It seems game progression is a non-issue with the latest version:

Link 1
Link 2
Link 3


I guess an official patch that eliminates X87 code, creates a recompiled 64bit executable and actually implements multi-threading would greatly boost the performance of the game (and maybe remove the CPU bottleneck in any quad-core @ >2.5GHz entirely?).
Nice :)
 
I guess an official patch that eliminates X87 code, creates a recompiled 64bit executable and actually implements multi-threading would greatly boost the performance of the game (and maybe remove the CPU bottleneck in any quad-core @ >2.5GHz entirely?).
Nice :)

I can't see Bethseda re-architecting the engine for multithreading, but recompiling with optimisations enabled in the compiler is a very small amount of work. Sure, they might say they would have to re-run all their QA testing, but (a) most customers would take the optimised binary at their own risk for the vastly increased performance, and (b) it doesn't look like Bethseda did much testing in the first place.
 
I can't see Bethseda re-architecting the engine for multithreading, but recompiling with optimisations enabled in the compiler is a very small amount of work.
I think you're right regarding the differences in time spent between the multi-core support and the recompiling.
However, I'm pretty sure the console versions aren't using only one thread, so I'll at least question how much re-architecting would be necessary.
Besides, there have been several games with post-launch patches that added mutli-core support. Here's some I found in a quick google search:
- CoD: Black Ops
- Everquest 2
- Team Fortress 2
- Minecraft



(b) it doesn't look like Bethseda did much testing in the first place.
You've got to be kidding, right?
An open-world game with this amount of scripted and generated content must have had an atrocious number of hours dedicated to quality control for anyone to be even able to play through the main storyline.
 
I remember enabling multithreaded AI for Fallout and that resulted in npcs killing each other in places I hadn't been. For instance there was this cave with bandits and rad scorpions. What was supposed to happen was that when I entered that cave, there would be fighting between the scorps and the bandits and I could take advantage of the situation. What really happened with MT AI was everyone had died inside, and one rad scorp was left.

The engine isn't really made for full scale MT, my guess is that it would need major re-architecting.
 
I think you're right regarding the differences in time spent between the multi-core support and the recompiling.
However, I'm pretty sure the console versions aren't using only one thread, so I'll at least question how much re-architecting would be necessary.
Besides, there have been several games with post-launch patches that added mutli-core support. Here's some I found in a quick google search:
- CoD: Black Ops
- Everquest 2
- Team Fortress 2
- Minecraft
I don't think Everquest 2 and Minecraft count. Minecraft was very much still in development, only having been officially released very recently. Everquest 2 is an MMORPG that has been in active, continuous development since its release in late 2004. The PC world has changed quite a bit since 2004, so it only makes sense that they will have updated their game to match.

Single-player games like Skyrim are different, and you largely can't expect much in the way of added multithreading support and the like.

You've got to be kidding, right?
An open-world game with this amount of scripted and generated content must have had an atrocious number of hours dedicated to quality control for anyone to be even able to play through the main storyline.
While there is certainly a lot of room for this sort of thing, it really needs to be built for it from the start. The problem is that while you have a lot of potential threads, you also have a lot of potential dependencies. and your data structures need to be set up to handle those dependencies if you're going to engage in multithreading.
 
I remember enabling multithreaded AI for Fallout and that resulted in npcs killing each other in places I hadn't been. For instance there was this cave with bandits and rad scorpions. What was supposed to happen was that when I entered that cave, there would be fighting between the scorps and the bandits and I could take advantage of the situation. What really happened with MT AI was everyone had died inside, and one rad scorp was left.

The engine isn't really made for full scale MT, my guess is that it would need major re-architecting.


So you think the engine is running single-threaded on the X360?
 
Oblivion and Skyrim seem to work similarly and hit about 2 core max utilization for me.

How did modder dude recompile their code? Dissassembly or something? That there are problems with the results say that Bethesda probably knew what they were doing by avoiding these compiler tweaks.
 
How did modder dude recompile their code? Dissassembly or something? That there are problems with the results say that Bethesda probably knew what they were doing by avoiding these compiler tweaks.

It replaces many calls to functions that would have been inlined if the compiler optimizer settings were set to something higher than "off" with actual inline code that nicely fits in the five bytes the jump instruction was previously taking up. It also overwrites several functions, replacing them with SSE implementations instead of the very painfully slow original x87 implementations.

There were some bugs, but those seem to have been fixed now. Not bad for a guy reverse engineering without the source code and only grabbing the low hanging fruit. With Bethseda not even setting the basic optimisation flags on the compiler, there was a lot of it to grab.
 
How did modder dude recompile their code? Dissassembly or something? That there are problems with the results say that Bethesda probably knew what they were doing by avoiding these compiler tweaks.

Disassembly and instruction replacing. The reason there were problems is one of the replacement functions was incorrect written and returned the wrong result.
 
Back
Top