Jump to content


Community Members
  • Content Count

  • Joined

  • Last visited

  • Days Won


OptimusShepard last won the day on July 25 2018

OptimusShepard had the most liked content!

Community Reputation

78 Excellent

About OptimusShepard

  • Rank

Profile Information

  • Location

Recent Profile Visitors

3.181 profile views
  1. @django you're welcome I recommended a23b only, because it's needed, if you want to play multiplayer in the lobby. If you only want to play singleplayer, you can also use the newest svn version, so you can use such features like FXAA antialiasing, or sharpening
  2. @vladislavbelov could you help him please. I am not able to build this version on Linux either.
  3. I'm a bit confused, I was thinking, that the cache errors only occur on the new Threadripper 3000 series. I made a new workaround, which should prevent from crashing because of cache detection. But you would need to build the game by your own. Could you build it? The revision number of a23b is r21946. You need the new patch D3031. I'm not sure, if the Threadrippers always needs the patch D1789, but I guess, it shouldn't hurt to take this patch too.
  4. I guess, it's not the problem, that more than one of the guys has currently not the time, it's more who of them has currently not the time. Not everyone has the skills, to solve the last release blockers.
  5. Yep, like @Stan` said. With the current Zen2 based CPUs we get random slow-downs and speed-ups while playing the game. It's, like someone suddenly sets the game speed e.g. from 1 to 0,1 or 10. I don't have the skills, to review the patch, I only be able test it.
  6. I guess, that's not that easy, if you want to hire a person for this special problems. In general you need to find a person you can trust, the person needs the skills and also the code quality has to be good enough. Second, there is much conflict potential. There are many volunteers, which had worked thousands of hours in the last years for free. So why paying an external, new person instead of them? Third, one person wont be enough, as the code has to be reviewed, bevor it can be committed. If they only hire one person, this would be very inefficient, as he/she has always to wa
  7. I think I have found an easy general solution. Skipping the validation. These data are only used for the hardware report. So a validation is not necessary needed. So here is the new patch. @Froschkoenig84 please test it, and tell me, if everything is working now. system.zip
  8. I add the patch D1789, hopefully it work system.zip If this doesn't work you may want to test this here. I hardcoded some parts, so another chance ^^ system.zip @Froschkoenig84 does it work for you?
  9. I add the patch D1789, hopefully it work system.zip If this doesn't work you may want to test this here. I hardcoded some parts, so another chance ^^ system_hardcoded.zip So ignoring this bug?
  10. I guess, test.exe wont work, because it's normally only available with the development (svn/git) version. I didn't delete all unnecessary files out of the folder.
  11. Yep, this is what I meant. If we detect a false positive for TSC. Do you meant the performance difference at all, or only when using SSE? I guess, most of the differences are related to the AMD OpenGl drivers. Do you think the newer 2019 compiler would have a big performance benefit?
  12. I'm sorry to hear that. I will have a look on the code again, but I guess, without the possibility of debugging, my chances aren't that good to find a quick workaround. I have also already tried, to do the correct implementation, but the CPUID and the technical backround ist out of my knowledge. I hope @Imarok can fix it soon. On the Ryzen CPUs it was possible, to press multiple time continue (at the crash window), to launch the game. Maybe this will work on the Threadrippers too? If so, you can press Alt + Enter to change to fullscreen mode.
  13. Hello @Froschkoenig84 I may have a workaround for you. system.zip Try this, and give me feedback please. Our problem with the wrong hardware detection is, that we read the new CPUIDs in a wrong way. So we get a wrong index, to interpret the cache associativity value. My workaround for you replaces the associativityTable[idxAssociativity] directly by the associativity value. @Stan` I was thinking, if our timer problems are CPUID problems? Do we read the CPUID to get the right timer? I know from my SIMD patches, that we use CPUID in other parts of the code too. I think it might be goo
  • Create New...