A quick update of the planned changes to my sidescroller and pixel movement libraries to include the changes in BYOND v490:
First off, the libraries are still useful. It sounds like native pixel movement is all you need, but there's more too it than that (this is similar to the feeling that you get when you look at DirectX or OpenGL and think, "that's the whole graphics engine, what else is there to it?", then you realize you need to load and manage textures, 3D models, animations, etc.). It's not about how the feature is implemented, it's about how you use it. The library has always done two things: provide you with the feature and bridge the gap between the feature and how you'll use it. The feature itself was always just the library's pixel_move() proc, but if you take a look at the library you'll see there's a lot more to it than that one proc.
The new pixel movement feature replaces the library's pixel_move() and set_pos() procs. The new bounds() proc also makes some improvements available to set_flags(). Those were the three biggest CPU users in the library and they can all be converted to use the built-in feature. Because this conversion is possible, all demos that come with the libraries (and anything you wrote using the library) will automatically use the new feature.
There are many features that the built-in implementation doesn't provide. Of these, some may be added in the future, some may be added with soft code, and some may be neither. The libraries still provide you with the movement/action loops, velocity vars, position/size vars (px, py, pwidth, etc.), icon state management, movement speed restrictions, the flags vars, the can_bump proc (easier than using Enter and Cross), keyboard control, camera control, and probably some other things. The libraries also provide support for ramps and 3D movement which don't appear to easily integrate with the native feature.
I started working on updating the sidescroller library to use the new feature and, in a couple of hours of work, have it mostly working. I chose to start with the sidescroller library because it'll be the harder one to convert. Aside from 3D movement (which will likely always be handled in soft code), the sidescroller library contains every feature the pixel movement library has and then some. If this conversion is possible, converting the other library will be even easier.
Most of the pixel_move() proc is now handled by two calls to Move(). The set_pos() proc is now handled by overriding the Move() proc to udpate your px and py vars. The px and py vars are still useful because the native bound_x, x, and step_x vars make it difficult to compare the positions of two atoms (ex: is this atom to the left of that one?). If neither, one, or both atoms you're comparing are mobs (and have those bounds/step vars) you need to check the positions differently. With the pixel movement library's px, py, pwidth, and pheight vars belonging to all atoms you can compare the positions of any two atoms easily, there are no special cases.
The atom.Enter and mob.Cross procs now call the mob's can_bump() proc. I find this also to be simpler because the can_bump proc gives you one place to define what can stop a mob's movement. The mob's Bump() proc figures out the direction of the bump and calls the bump() proc (with a lowercase "b") with the same arguments it always had (the obstacle and the direction of the collision).
I'm still working on getting support for scaffolds but I don't foresee any huge problems there. The only remaining feature is camera control, since the new feature adds a little bit of its own. I don't expect huge problems there either (no more problems than the feature has always given me).
I expect to have it all working by tomorrow. It might take a day to test, but an update should be posted by this weekend.
Sep 6 2011, 4:11 pm