Apply statistical distributions to clicks #72
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Wanted to hook it up to the GUI, but am not as familiar with C#. Perhaps you can give me some tips or commit to the PR as well.
As such, the standard deviation value is hard-coded for now.
PR uses existing interval entry to define desired average CPS. Along with the, currently, hard-coded standard deviation, a normal distribution is generated for the target CPS which is used to assign timer intervals at command start and in the timer elapsed callback.
Long term, it'd be neat if different statistical distributions could be applied.
Tested out the changes, and they work as expected, though I believe I'm seeing slightly lower CPS overall. For example, tested with targeted CPS=13.33, STD_DEV=0.25, but would often see averages closer to 12.4. Did not see any higher than target CPS. Maybe I was just very very unlucky....
I suspect the timer callback blocks the timer from being re-armed, and perhaps the new logic is adding some more delay. Which brings me to a somewhat unrelated topic as to whether it'd be handy to profile and discount program runtimes when calculating new timer interval. Thoughts?
If the distribution logic is taking too long in timer callback and offsetting the time, could buffer N CPS samples ahead in some separate thread, so that timer callback can just O(1) lookup the value instead. However, I'd like to get back to gaming now lol.