As this demo project shown, when the x value(prined first line in each rect) between -1 and 0, it drawn as if 0<x<1.
values between -1~0 treated as -1, while 0~1 treaded as 0.
The second value in each rect is the x after " |0 ", that maybe the point caused this issue. It used in the pack() function(libs\screen\image.ts), and that called by many other functions, include “fillRect” and “drawRect”, etc.
A workround is minus 1 when -1<x<0, you can edit source code, to try it.
This issue not only impact in range -1<x<0, but all range x<0.
Saying “-1<x<0”, just for descript the issue easily.
Hi @richard @jwunderl
Correct me pls, if there’s any misunderstand of me.
yes, this is the result of us using
| 0 on all values in our draw functions. if I were to guess, I’d bet this also reproduces for all of our other draw functions (including images) which use the same trick.
the reason we use
| 0 like this is because it’s super fast on hardware. the question is, will fixing this negatively impact perf? i don’t know the answer, but we have to be careful here since it affects much of our most perf-intensive code.
@jwunderl didn’t you and i talk about this a long while back?
I don’t remember this one in particular for sure, but some cases like this, yeah (and similarly, a few places where we didn’t do this and added it in for consistency)- I’d personally probably lean towards saying that drawing at decimal places should probably be considered basically undefined behavior anyway (we could round but what’s it really mean to draw at half a pixel), and that if you particularly care for how things round it should be made explicit before calling fillRect (e.g. math.floor, math.ceil, math.round, etc) - we do |0 because it’s the cheapest & prevents things from crashing
yeah i agree, drawing at decimal places is undefined. this does prevent smoothly scrolling images past the 0 point, however (they’ll get hung up at the 0 point for an extra pixel). not sure if that’s enough of a scenario to fix it though