1. When things move in more than the standard 8 directions.
Moving one "pixel" at 30 degrees means you have an offset of (cos(30), sin(30)), which is (0.866..., 0.5), which rounds to (1, 1). It improves as you go faster, but really you shouldn't be forced to go faster when you're actually moving slowly.

2. When you want things to move slowly. The slowest you can move currently is one pixel per tick. At a framerate of 10FPS, the slowest you can move is 10 pixels per second. At a framerate of 30FPS, he slowest you can move is 30 pixels per second; still one pixel per tick. With decimal pixels, you can move less than a pixel per tick.

Both of these are important factors for top-down racing games, space games (ship movement), shooter games (laser-projectiles and even side-view Pocket Tanks-style), and more. Coincidentally, the games I just mentioned also require efficient object rotation.

You can just keep track of "partial" pixel steps manually, then move the full pixel when all the partials total more than 1. That's the only alternative I can think of.

I actually got around to doubling the icon size in a project and found it to be pretty awesome. I was using tile based movement so now gliding resolution doubled (there's twice as many pixels to glide across which means gliding can be smoother, and slower, or faster). At higher FPS, this looks really great, almost like that of a AAA 2D title.

Kaiochao wrote:

Twice as many pixels to traverse only means twice as many movement calculations in a given time. The really cool thing to do (which also fits BYOND's style better IMO) is to use 16x16, like in WARFORGE, CazHaz, Casual Quest, etc. because although you need a large view size, the heavily-repeated calculations are cut in half.

How is it twice as many movement calculations? You're just making all the graphics bigger, and the glide_size is doing the rest of the work (no extra traffic).

Edit: A 128x128 map is still a 128x128 map. There's only 16384 positions to occupy. Gliding is the transition between these positions at no extra cost to the server or client as they can both hold up their end of the bargain without using bandwidth to do so. Less calculation stress for the server by not having to keep track of pixels and calculations of those pixels per movable atom.

Kaiochao wrote:

1. When things move in more than the standard 8 directions.
2. When you want things to move slowly.

I don't think these are good reasons for fractional pixel movement. #2 is just ridiculous, as others have said you can only display single pixel movement as the slowest movement. Only anti-aliasing could get around that, and at that point is it really worth it? How slow is this freakin' game?! And for #1, again you can only display things on the grid so your trig will have to be rounded.

The only way that fractional pixel movement would have any affect on your game beyond cosmetics is if it was used for precise collision detection. To which I must ask, what really is the point? Your players will not be able to tell the difference, except they might see that it looks like things should be colliding when they are not.

Wouldn't you just store your own values, and then do your own rounding and set step_x and step_y your self? Even if you were programming your own game from scratch in c, at some point along the pipe line, your pixel value is going to be a pixel value on the screen. Byond allows you to directly set where these values lie (pixel_x, step_x) so in conclusion, you'd make all the floating point accurate math happen your self, and then supply a rounded version of the value to byond.

If your request is to have this be "built-in", I am going to burst your bubble and say they probably won't do that unless it has some sort of useful meaning. For example, if the rendering was done with quads in open gl, then yeah, it would make sense to expose those values to the programmer. But since everything works on a fixed integer system (because all display screens do), you're not going to get a deeper more meaningful value between 0 and 1. It doesn't make sense.

So really, your goal is to have a more accurate input while not caring about the output... so why don't you just handle the input your self, and round to the output?

Kaiochao wrote:

This is about the math behind the scenes, and it has nothing to do with appearance.

You don't have to repeat yourself. I certainly won't. I'm just wondering when fractional pixel movement, which apparently won't even be displayed to the player, is actually necessary to make a game work well.

But if you -really- need your car to move that slowly, why not accumulate the fractions as has already been suggested?
Or, you could change the scale. Why not move 9 pixels north and 5 pixels east each tic? Your server will certainly be happy about that :)

Oh sorry about that, these forums move at the speed of a gimped turtle. I'm always starved for something to reply to here...