How are Sprites moved with Decimal Numbers?

I've been wondering how Sprites are moved, if the given value for example is .X += 5.5 X. With decimal numbers. Since the smallest possible value of the screen basically is 1px, how are images moved when they have decimal numbers?

Are the numbers just automatically rounded? Or nearby pixels illuminated weaker so it appears halfway on it? I don't know, how is it handled?

EDIT: I also noticed an odd behaviour in Debug Mode. For a moment I thought, the sprite is just moved, if the position has updated to a new whole number. I came to this conclusion by moving the sprite += 0.5px on X every step a button is down, while running with 2FPS. I pressed the button at different intervals.

But when I was moving it by 0.1px every step, sometimes it was updating the screen and moving the sprite by 1px, when the current X position was 10.8 and sometimes at 10.6 (10 being a placeholder for any whole number here).

And then sometimes it wouldn't move at all, if X was a whole number and the screen was updated the next time.

Related to this I would actually like to know how exactly using a fixed framerate affects the reading of the events? - First I thought, the internal processing speed of the events is not affected, and it will just keep reading the event list top to bottom as fast as it can and render the image, and then just wait for the given fixed framerate interval time to pass, until it updates the screen.

Now I feel like it actually also reads the event list with a slower speed, because sometimes it doesn't recognize the button input, if I press it at different times until the next reading (which I assume is signaled by the blink that is visible in the debugger window). And it seems to recognize the button press, if I press it shortly before the next tick, and not recognize it, if I press it directly with the next tick starting (the blink happening).

If it was reading the events as fast as possible, I would assume it to recognize the button press at the beginning of the tick, not at the end.

However if it was actually processing the events slower, I am confused about how it would handle the rendering of the image into the backbuffer.

it automatically AA's the graphic to look like its making sub pixel movement if you have linear filtering (the default sampling mode) set. this can look ugly sometimes though. you can change the sampling mode (which causes tearing instead of subpixel blurring).

rounding the position when you want it to be non blurry (example when your character isnt moving) will fix the blurred look.

it automatically AA's the graphic to look like its making sub pixel movement if you have linear filtering (the default sampling mode) set. this can look ugly sometimes though. you can change the sampling mode (which causes tearing instead of subpixel blurring).

rounding the position when you want it to be non blurry (example when your character isnt moving) will fix the blurred look.

Construct uses Linear Sampling, but are You sure for everything? Because moving the sprite with 0.1 every step doesn't move the sprite at all, until the next whole number. In the info box it sais the sampling is just used for rotations and scaling.

Construct doesn't render anything, it only sends data to the graphic card. Those cards may behave differently, depending on the card's manufacturer or driver version, etc.

As far as I understand it (I may be wrong, but I'm almost sure), all spatial data is used relative on the graphic card. The output frame is 1.0x1.0, and everything else is relative to that.

For example, if the game frame is 800x400 and a sprite is 200x200, then it's 1.0x1.0 and 0.25x0.5

That's why subpixel values are possible, but how they are implemented graphically depends solely on the graphic card.

When defining linear or point sampling, or Multisampling, you are activating functions of the graphic card's driver.

You can't tell, how exactly it is implemented by just going down to 1 or 2 fps. For example, the graphic card may have a function that detects the frame rate and starts blurring the edges only if that frame rate is over a certain threshold (e.g. to still let 3D artists work accurately with their software).

also, when you zoom in those values are used for your more accurate location