CookiePLMonster

3 ms·

1.
by CookiePLMonster 8y ago
Will keep close tabs on this one, maybe I'll grab it depending on how cheap it goes during Steam sales =)
2.
by CookiePLMonster 8y ago
I had a quick look on Steam forums and I wouldn't be surprised if that indeed was the case! Interesting. Does the game have any kind of modding community behind it whatsoever?
3.
by CookiePLMonster 8y ago
Then again, it may not be strictly due to /fp:precise - I tried compiling with VS2010 too, and even though it was /fp:precise the bug did not manifest itself. Perhaps comparing assembly code would have given a definite answer, but
4.
by CookiePLMonster 8y ago
Either way, it may indeed be beneficial to return time as a double - so code which stores it in floats will not care about the change, but the code which uses it in intermediate calculations will and it will potentially benefit from it. Not
5.
by CookiePLMonster 8y ago
I don't - it's not my code I had to fix. And as for returning the result - original code does return a float, so while I could also return a double it probably wouldn't make any difference, as I expect the game to store those
6.
by CookiePLMonster 8y ago
While it is not mentioned in the article, I am aware of /arch:IA32 (don't use SSE instructions) and I have tried it - no luck. On the other hand, using /fp:fast with VS2017 did give me similar results to what VS2003/VS20
7.
by CookiePLMonster 8y ago
Quoting from the article: "Application Verifier doesn’t have such an option (all it can do is forcibly wrap around GetTickCount, which is not what we need here). " That said, I failed to observe this issue with TimeRollOVer enable
8.
by CookiePLMonster 8y ago
Values are already offset (in noted snippet, timer_begin is approx. the time process has started, as in - queried during initialization). While I'll defend the idea of modifying QueryPerformanceFrequency result to achieve desired resol