# Thread: set X to X -0.3 moves by -1.0 : bug or feature?

1. ## set X to X -0.3 moves by -1.0 : bug or feature?

I just noticed that

Code:
```* Always
Active: Set X position to X( "Active" ) - 0.3```
will move the active 1 pixel each frame, while

Code:
```* Always
Active: Set X position to X( "Active" ) + 0.3```
will not move it at all. Is this expected behaviour? I personally would have expected neither to move the active.

2. sub pixel movement explained by Almighty zen taco https://www.youtube.com/watch?v=4isI09Naa70

3. I think you misunderstood my post. I know what subpixel movement is and how to achieve it, but it's irrelevant to the question being asked here, which is about whole pixel movement.

When Fusion moves something using the Set X position to.... action it uses whole pixels. The question is, why does Fusion convert 0.3 to a whole pixel value of 0, while it converts -0.3 to a whole pixel value of -1.0? If almightyzentaco happens to explain this somewhere in the video then please offer a timestamp. Forgive me if this sounds rude - that's not my intention - but I'm not watching a 30 minute video just to find out that it's got nothing to do with my question because you misunderstood it.

4. maybe i did misunderstand , i thought 0.3 is less that one pixel. . He explains it within the first 5 mins why fusion is moving things at 1pixel per frame. He calls it Flawing as Fusion rounds down to whole pixels. so 0.3 rounds down to 0 .. 2 mins 50 .. if that does not help sorry for wasting your time ..

5. I would consider this a bug. Maybe the inconsistency only occurs in the 0 to -1 range. Would be interesting to see what -1.3 does.

6. The question is, why does Fusion convert 0.3 to a whole pixel value of 0, while it converts -0.3 to a whole pixel value of -1.0?
To me it makes sense that 0.3 gets rounded down to 0 and it also makes sense that -0.3 gets rounded down to -1 Because Fusion flawing is rounding down to whole numbers.

7. Well if Fusion floors things automatically, then at least there's a logic to it, and it's not technically a bug. But in that case it seems like a design flaw in my opinion, though maybe there's a reason for it, like flooring numbers being cheaper on the cpu than truncating them, or something.

But in game development, negative values are used all the time, and usually there needs to be a perfect symmetry with how they're treated versus positive numbers.

For example, the reason I stumbled upon this in the first place was because I'd just spent a frustrating hour bug hunting trying to figure out why some of my objects were moving when they shouldn't be. Turns out it's because the objects had little remainder amounts (less than 0.5 or more than - 0.5) in their movement variables which I wrongly assumed Fusion would unilaterally ignore. So those objects travelling right or down would slow to a full stop while those moving left or up would move forever.

8. Yes that was the point i was trying to get across. That Fusion Floors automatically . I realized spelling was floors not flawing after i searched a few math sites.
After what i thought was logic was questioned.
I made an example to test it again and it still worked like i thought. . I am no math wiz but have a keen memory and what the Almighty Zen Taco said stuck in my brain.
heres my small test Mfa . for any one that wants to see it in action . Hold D and the counters show the values are whole numbers.

subpixel_test1.mfa

9. I think the last comment on that thread by Jacob explains it very clear, what happens is "flooring" as said already above.