Discussion in 'Release 57 Feedback' started by Sorthious, Aug 30, 2018.
I fully understand you. You could try using wine with DXVK.
I supported SotA because they have a Linux version. I would rather cut my support and move on than go down the Windows path.
So nVidia added a new OpenGL caching feature somewhere in May, that has a garbage clean up thing going on cached bigger then 120MB or 170MB.
You could try forcing the caching for SotA to its own directory, and forcing the option to not automatically clean (creating stutter/hitches) up the caches.
Or Disable the caching entirely (It is on default):
Could you give that a try @Barugon ?
I am currently away from the PC and did not have time to play around with it fully.
Also @Chris :
Are u guys using any caching on disk with SotA at all? As it seems I can not find anything in my home directory and or SotA directory.
As if you do not use caching on disk, then I can stop that trail right away with searching.
I'll try this tonight.
Do you remember what the environment variable is to get correct keyboard input on Linux is?
some brain food for the devs:
While average frame time is the most commonly investigated aspect of game performance, frame spikes (also known as “stutters” or “hitches”) are also very much worth our attention. Very long single frames or groups of frames are most usually caused by spikes in CPU workload. This could be, for example: Gameplay code, physics, loading assets, or “spawning” assets after loading them. When displaying a loading screen these frame spikes aren’t objectionable, but during gameplay they cause disruption to animation and input, severely degrading the user experience.
Ideally the extra workload caused by loading assets during gameplay should be carefully spread out over multiple frames so the per-frame CPU impact is low, and by using threads on a multi-core CPU the additional work is kept out of the critical path of game simulation and rendering. This should cause even a CPU-bound game to have minimal spikes. Game developers are justifiably spending a lot of effort architecting their engines to minimize these hitches and provide a smooth uninterrupted experience. However, on PC the resource model of the rendering API (such as DirectX) has to be taken into consideration because naïve implementations will cause hitching.
Before you are able to effectively address stutter in your application, you should implement a way of measuring it. Virtually all games have some way of showing average frame times and Frames Per Second, but measuring frame spikes is just as important. Logging and graphing frame times over time is a useful visualization which will highlight the occurrences of stutter. Once the worst frames have been identified, investigation can begin into what is causing the stutter to take place.
Another handy tool to visualize the smoothness of the game experience is to graph the frame times using percentiles. A graph of the top 10 percentile of frame times can be tracked during development to keep a finger on the pulse of stutter.
For more information on measuring stutter and graphing percentiles please take a look at Iain Cantlay’s post: Analysing Stutter – Mining More from Percentiles
Unfortunately, none of that helped.
Thanks, I also tried it out Today with no luck. It is probably this: https://www.shroudoftheavatar.com/forum/index.php?threads/hitching-freezes.139969/ almost 100% sure.
I would think that page flipping would be the fastest method of updating the display and as long as they're using triple buffering, there shouldn't be any performance degradation for syncing with vblank. At any rate, it doesn't seem like it would cause hitching.
Actually as soon as my FPS drops about 10 fps the hitching occurs. It looks like the vsync is trying to catch the huge drop in FPS and creates the hitching. Also the SotA vsync is forced to 30fps on my system with best settings enabled. But the FPS jumps all over the place, pretty unstable. I will do some more testing.
You guys wanted to know the difference in release and QA right? Release uses BLIT vsync, QA uses SPLIT vsync.
So, if this is the case, is there any reason why Split Vsync can't be implemented on Live?
I am not sure which QualitySettings.vSyncCount = ? triggers BLIT or SPLIT. The devs should know I guess. I am still in favor for QualitySettings.vSyncCount = 0; and let us users enable vsync on the drivers.
They could (if not already) use Application.targetFrameRate to set a target fps to 120 or 60 I guess. As we are not a First person shooter where the highest FPS possible is needed. SotA running Application.targetFrameRate=30 should be fine... Maybe even 60 to make everyone happy.
Devs please do correct me on any BS I am talking lol.
Separate names with a comma.