X Positioning via decimals

you can move by decimals, but you need to put the decimal in an ALT VALUE - set position by 0.5 doesnt work.

set ALT A to 0.5

set x pos to x pos + ALT A does work.

You can't move by decimals - can't display on half a pixel although there are shaders to blur like subpixel movement.

The usual method is to store XY in alt values, and then set the real XY to alts. Alts will keep the decimal digits so you won't get uneven movement.

The Alt A variable should contain a value that you later use for the X Position of your active object..

Pseudo code:

( start of frame )speed = 0.1

While "right arrow" is pressed

--------Alt A = Alt A + speed

-------(set posX of the object): posX( Active) = Alt A (active)

It might help if you upload an mfa. It seems like either (a) you might have unrealistic expectations of how it'll move, or (b) you're not doing it quite right and it's not moving as smoothly as it should. Either way, an mfa should help clear things up.

Quote from WhatPixelYouOn

Sorry I'm not great at explaining it, perhaps my expectations are too high. I'd just like to know if using decimals, should I be able to create a X/Y Pos movement that is able to move as slowly and smoothly as some of the built-in movements?

I've made an example showing the difference in motion between using values and positioning, vs the built-in Ball movement. Notice how the Ball movement can move much slower, and appears to transition between speeds much smoother.

That's not how you do it, you set the X position to the subpixel X value directly, not adding to the current X position, and you control the Subpixel value instead (The subpixel position value is now your new X position to put clearly)..
See, basically positions are in integers (whole numbers), and as we are dealing with pixels, there is no such thing as decimal pixels, like there is no pixel 43.6, it's either pixel 43 or 44

When we do "subpixel", we actually fake it, it's more of an illusion to fake smoothness, what happens is actually a delay..
Say your Subpixel value was 1.1, when you set the real X poisition to that value, it would actually floor it, so it would jump to pixel 1, same with subpixel 1.2, 1.3, 1.4, 1.5, 1.5, etc. up to 1.9, until it jumps to pixel 2 in case subpixel is now 2.0, 2.1, 2.2, etc.

Hence why the illusion starts breaking more and more as the resolution of the game decreases and we scale up the window, you would quickly notice the jitter is indeed still there.

Corrected:
Please login to see this attachment.

• Note 1: I divide Spd by 10 instead as we can't enter decimal numbers for value in properties, and didn't want to set the value in events, but in reality spd 6 would actually mean spd 0.6...
• Note 2: The "Present" flag is used to help automatic initialization, instead of having to do it in a start of frame event and/or after creating the object.

Another thing I noticed from the example that you may also be misunderstanding how acceleration works, like for the built-in movement you gradually increase the speed, while for the custom one you just increase the X position, which is linear movement, not acceleration..

First of all, for the built in movement, you don't add decimals to the speed, it would just round it up to the nearest integer internally (Unless you did that intentionally so the object speeds up slower due to the delay), as built-in movements are already subpixel, and are based on 1/10 of a pixel, so speed 50 actually means the object moves 5 pixels each frame, speed 35, means 3.5 pixels, but of course as mentioned earlier there is no such thing as decimal pixels so it's all just an illusion by doing delays.

(also note that built-in movements are actually timer based, so in case the timer based movements option was enabled, set to 60, and the frame rate of the app was different from 60, like 120, it would move less pixels to maintain the same speed across any FPS, so for example if the speed was 40, on 60 FPS it would move 4pixels per frame, while for 120 fps it would move 2 pixels per frame. if this is not making sense to you no worries, I just wanted to note that out for information accuracy)

Second thing is, if you want acceleration for the custom approach, you would gradually increase the speed it self, meaning instead of moving by 0.01, you would move by 0.03 for example, and you keep increasing that value (You would be adding to the speed not position, and the speed is added to the position, but remember, subpixel position value, not the real position, for the real position you would just set it to the subpixel value)

Quote from WhatPixelYouOn

Sorry I'm not great at explaining it, perhaps my expectations are too high. I'd just like to know if using decimals, should I be able to create a X/Y Pos movement that is able to move as slowly and smoothly as some of the built-in movements?

I've made an example showing the difference in motion between using values and positioning, vs the built-in Ball movement. Notice how the Ball movement can move much slower, and appears to transition between speeds much smoother.

Try to keep this guiding principle in the back of your mind: X("Active") should be write-only.

The problem you've been having essentially comes down to rounding errors. You've been reading from the object's X position (the offending piece of code highlighted in red below)

Please login to see this picture.

What's the problem with reading the X position? Well, the X position is always an integer. So what you've been doing is calculating fine detail movement in your floating point code, but then discarding some of that fine detail each frame by converting some of that information into integer form.

So here's your example, modifed so that the floating point information gets stored and used properly between frames. Try this and you'll see the smooth and nuanced speed changes you were after.

Please login to see this picture.

The principle is simple. Instead of reading and writing directly to X("Active"), you instead write to an AltVal, which will be able to store floating point numbers (decimals). I've called it storedX in this example. In older examples, you'll often see people using Alterable Value X & Alterable Value Y for this purpose.

So you do all your reading and writing of numbers in this AltVal, and then at the very end, you set the X position to that altVal. This is what I mean by X("Active") should be write-only. You don't read from it. You just write to it at the end.

As Linky pointed out, the X position will still be in integers, because pixels are pixels and they work in integers. But whereas before you told your object to go to X=4.3 and it went to 4.0, now it will still go to 4.0 but will remember the 0.3 remainder and incorporate it into the next frame's calculation. This will make the movement smooth as you want it to be.

I second that, and it' s exactly what I wrote in my post above ( n. 5 ).