I'm coming to you because I've noticed some weird behavior on time based shaders on Android, briefly as time progresses the shader will become either jerky or pixelated or both. So I made you an example where it will become more and more jerky on Android.
I first thought it was a precision qualifier problem but even in `highp` the same behavior occurs (on another shader just put all the values in `highp` and nothing helps). For the example I'm sharing with you, this happens on my device which is an old thing as well as a friend's device which is much newer so I'm starting to doubt an accuracy issue or so it's is inherent in all phone chips but there is bound to be a way around this problem.
For now either I reset the time variable sent to the shader when I can or if the time value corresponds to a phase I modulate it to 2*PI.
Has anyone had this problem and knows what caused it and how to fix it? (other than with the solutions I cited which may cause other inconveniences in some cases).
It's most likely a precision problem indeed. So I can think of two possibilities.
Possibility one: your phone is ignoring the highp setting because it doesn't support it.
Possibility two: your phone does not support using highp precision in the functions you're calling (mod, fract), so they are converted to single precision to call the function.
pgimeno wrote: ↑Mon Feb 06, 2023 7:13 pm
It's most likely a precision problem indeed. So I can think of two possibilities.
Possibility one: your phone is ignoring the highp setting because it doesn't support it.
Possibility two: your phone does not support using highp precision in the functions you're calling (mod, fract), so they are converted to single precision to call the function.
I think so too and I'll rather consider option 2 because I've already noticed differences between `mediump` and `highp` on some shaders. The strangest thing is that there is exactly the same behavior on my friend's phone which is much more high-end than mine.
In any case thank you for your suggestion I had not thought that it could be due to the precisions used in the functions and it could explain a lot of things, I will try tests taking this into account, if I do not give any news on this subject then the best solution are the ones i quoted in my first post.
I don't know if it'll solve your issue but you haven't set the 'time' variable to highp. It'll get imprecise pretty quickly at mediump as time advances.
Also, if you're using love 11.3 or older then the value returned by love.timer.getTime() might start at a very high value and increase from there when love launches (it was changed in 11.4 to start at 0 when love launches.)
In general it's best to use a time difference from some point not too long ago, rather than some absolute time value, in order to maximize precision.
slime wrote: ↑Mon Feb 06, 2023 8:31 pm
I don't know if it'll solve your issue but you haven't set the 'time' variable to highp. It'll get imprecise pretty quickly at mediump as time advances.
Also, if you're using love 11.3 or older then the value returned by love.timer.getTime() might start at a very high value and increase from there when love launches (it was changed in 11.4 to start at 0 when love launches.)
In general it's best to use a time difference from some point not too long ago, rather than some absolute time value, in order to maximize precision.
Yes sorry, it's something I forgot to specify but whether I define `time` with the precision `highp` or not the result will be the same for me, it's even the first thing I tried when I noticed this problem.
Also I used `love.timer.getTime()` as an example this also happens when I use a `time` variable incremented with `dt`. And although I use 11.3 on PC the version of Löve I use on Android is indeed 11.4 and this problem only appears on Android.
