Adventure Maker

by Woo
Game engine and starter kit. Platformer and adventure RPG games supported. No coding required. Just add your own map!
ID:2272611
 
The potential collision "bugs" mentioned here are from moving faster than the mover's own step_size, not world.icon_size. The DM Reference entry for Move() explains this. All you need to do is set step_size to at least the amount of pixels you're moving, because that causes the movement to be a "slide" rather than a "jump". Of course, for default movement to still work, you'd have to reset step_size to what it was before.

Fast-moving collisions, as well as slow-moving sub-pixel movements, are easily done using my Sub-Pixel Movement library.
Thanks for the explanation. This helped me learn more about what qualifies as slide movement. I also found the following in the DM Reference under "step_size var (movable atom)":

"When Move() is called by a step or walk, or by the built-in client movement verbs, a change of step_size is applied to step_x and/or step_y. Any movement within the speed of step_size, or up to one tile in distance (whichever is greater), is considered a slide and may partially succeed if an obstacle is bumped before reaching the final position."

This explains why the movement partially succeeds even when step_size values are low, because the tile size is still 32, and it uses whichever is greater to decide whether to use a slide. So freefall is working correctly as long as it is less than either step_size or the tile size.