Not much information has been provided so I'm not sure how extensible the feature will be. It sounds like things will be handled internally and not much will be exposed to the developer for customization. In some ways this could be a setback, I'm not sure if it'll allow for some things (ex: the can_bump proc, 3D movement, ramps). Hopefully there will be some way to make the libraries compatible with the new feature so that anything made that uses the libraries will automatically make use of built-in pixel movement once it's released. I'm not confident that it'll be fully compatible, but we'll just have to wait and find out.
No matter how their built-in pixel movement works, the bounds var (described here) will be useful to my libraries. One of the limitations of the libraries is big atoms. For example, if you have an icon size of 32 you can set a mob's pwidth to 128 but it won't really behave as being 4 tiles wide. This is because when it checks for atoms that you collide with, it only looks in view(1). You may be 3 tiles away from the 128 pixel wide mob and be inside of it, but because it's outside of view(1) the library doesn't check for collisions against it. With the bounds var, the 128 pixel wide mob will appear in the view(1) list.
I wanted to add ceiling ramps, but ran into some problems and couldn't get them working perfectly. It's been close to a month since the last update and I have enough changes ready that I'll leave ceiling ramps for another update.
The changes are:
- Changed the SCROLL_X and SCROLL_Y constants to be named REPEAT_X and REPEAT_Y. These names make more sense since they are used to determine in which directions the background repeats. You can make any background move horizontally and vertically, even if it doesn't repeat in those directions.
- Created the /Controls object which contains the vars up, down, left, right, and jump. These vars contain the keys that correspond to those actions. Each mob has an instance of the /Controls object, so to change a mob's jump key to Z just do: mob.controls.jump = "z"
- Fixed a bug with the way the stepped_on and stepping_on procs were called. Previously there were times when they wouldn't be called when you land on the ground while not moving horizontally at the same time. Now they should be called in all cases that they apply.
- Fixed a bug with the behavior of ramps (it was most noticeable in the scaffold ramps in the movement-demo). I think it was caused by the support for fractional moves, but I'm not sure. Whatever caused it, ramps seem to work fine now.
- Fixed another bug related to ramps. Some cases where you bumped a ramp from the side weren't being handled correctly.
Pixel Movement v3.3
Just a couple of changes to path finding and path following:
- Changed the way path following (the mob.move_to proc) works. It should improve performance and make use of the move() proc's support for 8-directional moves.
- Changed the way path finding works. It now makes use of diagonal moves.