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.
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.