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.
In either case, it looks like the way you use the built-in feature will be awkward so a library will be needed to create an easier way for DM developers to use the feature. This is unfortunate because, at least to me, there's a huge difference in motivation. I'm motivated to add support for features that BYOND lacks, but I'm much less motivated to "fix" features that BYOND botched. For example, the Interface library started as a library to fix a botched feature (winset/winget) but quickly turned into adding support for new features (JavaScript-DM interaction).
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.
Sidescroller v2.8
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.
I tried to think of what people will try to do with the pixel movement and sidescroller libraries (ex: flying, double jumps, wall climbing, etc.) and code them in such a way that those features would be easy to add. Most features can be added with 10-20 lines of code. Some features have built-in support (ladders, scaffolding, pathfinding) so it's just a matter of setting a var or calling a proc. I didn't always get things right on the first try, but after using the library quite a bit myself (the sidescroller library, at least) I started to get a better idea of how things should be laid out. The Tiny Heroes code is very much the same way. It's very easy to work on, I just haven't had much time lately.
I hope the BYOND staff takes the same considerations into account for their implementation, but I'm not optimistic it'll happen. They don't seem to have the game development experience to know what would make it useful, simple, and versatile. They also don't seem to have much interest in trying to get it right the first time and, based on how other features have turned out, I wouldn't expect to see iterations of drastic changes after its initial release.
On the bright side, as long as their built-in feature doesn't break my libraries they're still completely viable to use. I haven't been making a lot of progress on Tiny Heroes lately, but Bravo1's Tanx nicely shows off what the pixel movement library can do (and, unfortunately, what BYOND's poor mouse handling can't do).