Technical support > Windows
Attn Windows players with lag/slow performance w/2.4 dev builds
Destructavator:
I've noticed over time as the game developed that the Linux version, once compiled, runs rather smooth compared to the Windows build of the 2.4 dev branch, which runs at a godawful crawl on Windows 7 machines with multiple cores, and I've found a fix to this issue.
I found this works well and makes a *profound* performance difference on my new 64-bit Windows 7 i7 (eight cores) machine. Before this method I had to turn all graphics options down to lowest settings, and still the battlescape was painfully slow to the point of making it un-playable. After doing this method I'm about to describe, I can now turn everything all the way up and get smooth framerates.
This involves editing the config.cfg file inside the APPDATA folder with a text editor.
- First, you need to know exactly how many cores your machine has.
- Change the "set sys_affinity" value to exactly one greater than the total number of cores in your computer.
- If you don't plan on running other apps while playing, you can also change the "set sys_priority" to "1" instead of zero.
- In my case I also found it helped to increase the "set cl_maxfps" value to a multiple of my screen refresh rate, which in my case is ~60 (I live in North America, EU players might have a different default screen refresh rate, I really don't know for sure - I know that TV sets are different but don't know if the same is for computers over there). In my case I put it up to "120" and got very nice results.
That's really it, just those steps made a huge difference. I noticed that the default sys_affinity when I set up the game was "3" which would have meant both cores on a dual-core machine, but since I have eight cores the game - according to the console log - was confused and used just one core, the third one. Now it uses all 8 of them.
P.S. - I've installed NSIS installer system again and I hope to have a new, complete 2.4 dev test build for win32 uploaded soon, in the usual thread - for those who want to try this out.
mikeg:
Another remark: After study the source code, you can set the sys_priority to any other value than 0 or 1 to get real-time priority. But this can cause side effects such as problems with mouse, etc. Use it with caution.
Your description about sys_affinity seems to be incorrect, IMHO (take a look to source in win_shared.c:void Sys_SetAffinityAndPriority (void))
Regards
Mike
ManicMiner:
Well, I've had a play with the newer 2.4 builds and I don't see the problem you're getting.
That said, by far the most playable and stable build I've got is the very last one from SVN, built using Muton's script tool, and optimized for dual core with the cache sizes set as per my work laptop.
Consistent 47FPS with everything enabled except GLS, and that's not bad considering the laptop's a couple of years old.
Destructavator:
--- Quote from: ManicMiner on October 12, 2010, 09:34:42 pm ---Well, I've had a play with the newer 2.4 builds and I don't see the problem you're getting.
That said, by far the most playable and stable build I've got is the very last one from SVN, built using Muton's script tool, and optimized for dual core with the cache sizes set as per my work laptop.
Consistent 47FPS with everything enabled except GLS, and that's not bad considering the laptop's a couple of years old.
--- End quote ---
You're probably not having this issue because, from what it sounds like, you only have two cores. The issue is that the recent versions of the game (the last SVN one is rather old now) gets confused running on systems with more than two cores, so on a quad- or eight core machine (mine has eight), the game only uses one core and runs slow, but with just one or two cores, there's no problem.
I haven't actually looked at the code, but I'm guessing it is outdated, written to accommodate either one or two-core systems.
That being said, should I:
A - Sticky this for Windows users, until the code is updated?
or
B - Move this topic and treat is as a (logic?) bug? (Until the code is patched)
Edit: FYI to anyone who wants to update the code: Machines with even more cores are coming out, I have a friend waiting to make a purchase on a 12-core system. Therefore, to avoid having to patch things again in the future, I'd suggest supporting future machines with a lot more than eight cores. Don't get me wrong, I'm not expecting support for enough cores to fill up a 64-bit integer value with any machines coming out in the next few years (methinks that would be overkill), but something adequate to work with machines that are in use by the time this project is complete (as in having the plot finished) would make sense.
Mattn:
latest git master should fix the issues - if it works for you, let me know and i will merge it back into 2.3.1
Navigation
[0] Message Index
[#] Next page
Go to full version