Oh well. Rafael Rivera looked into that and the logic behind it turns out to be quite simple:. That makes sense and ties back to the original theory. With 3DNow! With this information, we put forward a hypothesis — something is possibly wrong with AMD SSE2 instructions, and the results of matrix inversion calculated on AMD with an intelsse2 path are either too inaccurate or completely incorrect.
We prepared a simple, standalone program to verify the precision of matrix inversions. Later, this file was read by a standalone test program and the results were recalculated again. To verify correctness, outputs from the game were then compared with outputs calculated by the test program. The last column indicates whether the game handles this data fine or if it glitches out.
We deliberately did not take imprecision of floating-point maths into the account and instead compared the results with memcmp :. At this point, we were ready to put forward a fix which would replace D3DXMatrixInverse with a rewrite of an x86 variation of the D3DX function and call it a day. What we were sure to be an issue coming from tiny differences in SSE2 instructions may have been a purely numerical issue after all. Therefore, we re-ran the same tests and the results were surprising, to say the least:.
With this in mind, we revised the theory behind that bug — without a doubt, the game is at fault for being too sensitive to issues, but with additional tests, it seems like D3DX may have been written with fast math in mind, while DirectXMath may care more about precise calculations.
This makes sense — D3DX is a product of the s and it is perfectly reasonable that it was written with performance being the main priority. For this function, we have developed a replacement using XMMatrixInverse. It works out of the box, without the need for an ASI Loader or any other third party software. To our best knowledge, the game now looks exactly how it should, without any downgrades in the lighting:. Not sure how to proceed? Check the Setup Instructions.
For those interested, full source code of the mod has been published on GitHub, so it can be freely used as a point of reference: See source on GitHub. In theory, this could also be a bug inside d3d9.
When playing the game on PCs with modern AMD processors, two areas in the game Noveria and Ilos show severe graphical artifacts: Well, that doesn't look nice. Is this really the issue, or is it caused by something entirely different? The Mass Effect trilogy is pretty great, and so it stands to reason that the Mass Effect Legendary Edition would be great too.
For the most part, it is, although not without caveats, including occasional reports of performance issues: We noted a couple of weeks ago that it ran " like an absolute dog " on some laptops because of the way it autodetects graphics hardware.
Some Steam users also reported lower-than-expected framerates. Repost from another comment's section: Awesome!
Someone should also do a replacer for the Prethoryn Scourge! Updated: No major changes has been done to the end game crisis as I know so this file should still work as intended. Also, there's too many reapers already, but I might do what you guys asked later on. You really should do the scourge, this and the contingency are cool and all, but the scourge is the only real eng game crisis thats similar enough to the reapers to warrent a replacement.
If you won't, just let someone else make it with these ships for you. I agree with mr. Person 10 Nov, am. Person: For now, no, I like the scourge organic monster look, but later on, maybe I'll do it. Person 9 Nov, pm. You going to do the scourge eventually too? They seem to be the most similar to what the reapers did in the ME games, at least with the whole "arriving from dark space to murder all organics" type thing.
Share to your Steam activity feed. You need to sign in or create an account to do that. Sign In Create an Account Cancel. Edit links. All rights reserved.
0コメント