WACUP
Preview Build Discussion => Preview Build Discussion => Resolved Issues => Topic started by: paweltylman on December 26, 2020, 05:39:26 PM
-
Hello, my problem is in the title, i have only 55 fps regardless of resolution or windowed mode, please help.
-
(https://i.imgur.com/2tW0Dsz.png)
Did you set Fullscreen, Desktop Mode etc to "unlimited"?
-
Yes, unlimited everywhere.
also wen i set 30fps everywhere i have 27
-
What're your computer specs?
-
Intel Core i5-8600k @4.8Ghz
GeForce GTX 1660 GAMING OC 6G
WIN10 (latest update)
-
that wirde, but i did nothing and now i got 65fps regardless of resolution or windowed mode ?? set unlimited everywhere.
-
Are you running on a variable refresh rate monitor? Also what is the maximum resolution are you are able to run at?
As the fps limits are a target & not guaranteed to be what you'll get depending on the resolution that's trying to be rendered as well as whether the hardware is going to allow it & also what the complexity of the milkdrop preset(s) used.
From the screenshot provided, there's also the multi-sampling enabled for windowed/desktop mode which is going to reduce the overall fps & un-checking that can also be one option to get a higher fps. I mention that option as it's not something that should be enabled by default.
-dro
-
variable refresh - yes, but wen i turn off its still 55fps
maximum resolution - 2560x1440 but 55 fps even if set 800x600
complexity of the milkdrop preset(s) - i got everything on default and all preset(s) 55 fps
when i try set difdent setting at one point i got 65 now is 55 again
i also check nvida control panel fps limiter is off
older version of MilkDrop 2.26k working fine i get 250 fps or 200 or 160 depend on visualisation
it's like something is limiting fps on new version and i dont know what (i try also to on and off vsync aka page tearing nothing help.
-
Can you please see if the attached test build works any better.
-dro
[edit]
test build removed
-
unfortunatly no,
but i found something may be important: milk2_adapters.txt is missing in new version
(https://i.postimg.cc/tJ48Cpxr/111.jpg)
milk2_adapters.txt
Winamp version = 0x5066
Plugin long name = "MilkDrop v2.26k", version=200, subversion=5
Enumeration of Display Adapters:
1. Driver=nvldumd.dll
Description=NVIDIA GeForce GTX 1660
DeviceName=\\.\DISPLAY1
DriverVersion=0x000E17C9
VendorId=4318
DeviceId=9348
SubSysId=0x24841569
Revision=161
WHQLLevel=0
GUID=D7B71E3E 67C4 11CF 10 61 8A 04 1B C2 D6 35
-
Hmm, just to be doubly certain, you've mentioned 2.30.2 again in the above image but the new file was version 2.30.3 so was that definitely what was tried? (I have to ask as I've been assured of things being copied in the past by other users & that then wasn't the case).
The milk2_adapters.txt is purely a debugging related file which is never actively & is why I disabled generation of it.
Are you running just milkdrop or have you enabled the multi-vis support in build 6800 & have enabled more than one visualisation?
I'm currently stumped on what would be causing a persistently lower frame rate than my 'old' 1050ti is able to do even at 4K when nothing fundamental has been changed when it comes to the plug-in other than removing / changing a number of aspects related to plug-in to wacup contention (e.g. obtaining the currently playing information).
-dro
-
i try enable and disabled no differences.
-
Ok, I'll have to trawl back over all of the changes since 2.26k & see if I can try & find anything that'd have triggered this issue.
One thing that might be useful is to see what the level of gpu usage is when the 'broken' milkdrop is running as well as the general WACUP cpu usage. Also are you using the built-in FPS display option or something else to determine the frame rate?
-dro
-
Not sure if you're still following this or not but I've just spent the past 4hours tonight trawling back over all of the changes from 2.30 back to around 2.26k (from around October 2019 based on the commit logs) & I've not found anything obvious within the plug-in that could explain a drop in performance when there's less blocking code running now than before (I also should have realised that 2.26k was massively older compared to the current previews).
However I have noticed that the fps limiter doesn't seem to be right with a number of builds after that old one (e.g. 30fps runs at 22fps) so it's either due to the change in the compiler used (which was a change made around that time) & it's something about that which is causing the issue or I've broken something within my handling of vis render calls (irrespective of the input plug-in) within the WACUP core itself.
I'll be looking into this more as the "30fps runs at 22fps" thing is definitely odd especially with small window sizes where there's no obvious reason for a limitation in what's going on.
-dro
-
I've determined what I believe to be the cause of the performance regression & I'm now back to being able to run WACUP's Milkdrop build at the specified FPS without it being a factor lower. Am hoping to release a newer preview build with the fix later this week.
-dro
-
Fixed in v2.30.3. Thank you!
-
Not sure about that as the removed 2.30.3 test build didn't resolve the fundamental cause of the issue now I know what was going wrong. As there's a number of changes present in the current beta builds (soon to become a new preview build) that get Milkdrop (& potentially some other visualisations) running correctly again by managing the timer resolutions in a more consistent manner.
Without those changes (or ensuring each plug-in does it on its own) we get the issue that was reported in this thread due to the frame pacing waits varying too much & that is why it was running below 60fps or occasionally above 60fps. As the default OS resolution is around 15.6ms & with what was going on it could mean you'd get the next frame around the time wanted or it might have to wait for the next wait cycle (i.e. waiting ~31ms) which makes it hard to hit the desired 60fps (or other rate) targets.
-dro
-
100x Thanks :) WACUP 1.0.20.7170 resolve the problem.
-
Thanks for the quick confirmation that it's resolved with the new build.
-dro