balala wrote: ↑May 21st, 2020, 5:35 pm
Since I have no clue what is causing this, every idea is welcomed. So, if you have idea about the fix, please share it. Because I don't have the same issue as Jason, and so, I have no idea what's going on there.
I don't have an idea what is the cause of those glitches either, but the OP from the link I posted mentioned them as well, and he claimed his last posted code "solved" it. I doubted (and still doubt) that, but since he was OK with the result, I didn't pursue the idea further on.
And yeah, those "glitches" don't happen for me either, just like in your case. Unless, of course, the "glitches" are the sudden increasing / decreasing in the speed of an ActionTimer animation ... something I
did notice just about every time when using an ActionTimer animation myself. I didn't mentioned them yet on the forum because to me they seem like "normal" behavior of an "external" plugin when the CPU is busy (or busier, to be more precise) with other stuff in the system. Those sudden changes in the animation speed don't happen when using a "classic" animation type (i.e. through a counter and lowering the skin update rate), by the way.
A bit off topic, but since we're at it, I also noticed a significant CPU usage increase when using ActionTimer and doing other GPU intensive stuff (like watching a flash clip online, a YouTube video, etc). I tested all kinds of animation scenarios for two of my skins and it turned out that my method of doing the animation "the old way" (i.e. classic, no ActionTimer) was the most CPU friendly in those cases. I suppose it's because the AT measure requires additional updating to make use of dynamic variables, while a "normal" measure updating at the fast skin update rate does not. Also, using the [!MoveMeter...] bang instead of the usual [!UpdateMeter...][!Redraw] method seems to be a bit faster - I guess because !MoveMeter automatically handles only the things related to the meter in question, and not the whole skin redrawing...