My work on the Sidescroller library initially focused on adding features and making it easier to use. Lately the focus had shifted to performance. Even though people weren't using the library they were concerned about its efficiency. As irrational as that is, I suppose it's nice that people care =)
This concern for performance prompted the BYOND staff to add pixel movement. This meant I had to update the library to make use of this new feature. This was a problem because:
1. I was spending lots of time only making existing features use native pixel movement, I wasn't really adding to the library or improving it.
2. It limited what the library was capable of because the native pixel movement system cannot be easily extended.
3. There were essentially two versions of the library because some features (ex: ramps) couldn't be supported by native pixel movement.
The version 4 update fixes all of these problems!
The previous updated introduced the hybrid mode, which was a combination of the "native" and "library" modes. Library mode is the way the library used to work - all of the movement stuff was coded in DM and the library had complete control over how movement worked. Native mode was how the library worked when using native pixel movement - this improved performance but limited what was possible.
The hybrid mode uses built-in pixel movement vars/procs to greatly improve the performance of library mode. In version 4 of the library, hybrid mode is the only mode. This means that movement is again controlled entirely by the library. Not only is it possible to add new features, but it's easy and fast. It's easy because the library only has one mode, features don't have to be implemented different ways for library and native modes. It's fast because the library still makes use of procs like obounds() to improve performance while still implementing movement itself.
The changes in version 4.0 are:
- Removed the NATIVE and LIBRARY modes - the library now uses only the HYBRID mode. Since this is the only mode there's not an option for it.
- Removed the pixel-movement-native and pixel-movement-library files and changed the pixel-movement-hybrid.dm file to be called pixel-movement.dm instead.
- Renamed mob-movement.dm to movement.dm and moved the set_flags proc back to it.
- Renamed pixel-movement-common.dm to background.dm, since all it contained was code for handling backgrounds.
- Created collision.dm and moved a lot of code from the pixel_move proc to it.
- Added an optional argument to the front() proc. Calling front(4) will return a list of atoms within 4 pixels of the src object based on the direction its facing. Calling front(4, RIGHT) will force it to return a list of objects within 4 pixels of the object's right side, regardless of src's dir.
- Removed the offset_x and offset_y vars, you can now use pixel_x and pixel_y instead.
- Removed the FOUR_FLAGS flag from _flags.dm because all four flags are necessary for some of the library's internals.
- Changed the NO_STEPPED_ON flag to be called STEPPED_ON and made it enabled by default (this way all demos will work, but you can disable it to improve performance in your projects).
Hopefully the work done on the library will again focus on adding features and making it easier to use. I'd also like to create some more demos or tutorials related to the library.
I like this update because it makes the library work exactly how I've always thought it should work. The big, important, and heavily customizable features are implemented in soft code (which is just another way of saying they're implemented in DM) and the BYOND staff works to provide native features that can be used to improve the soft-coded features.
For example, consider the missile proc. Graphical effects like this are very important to games. This should make missile() a very useful proc, but it's not. It's not useful because it's not customizable - if you don't want your graphical effects to work exactly like missile() you have to re-code the whole feature yourself. You can't simply change how missile works.
This is actually quite a big problem. BYOND tries to do things for you so that things are easy - they give you the missile proc, so implementing that graphical effect is easy. The problem is that this makes an easy task easy, but doesn't make hard tasks (i.e. more complex graphical effects) any easier.
BYOND makes a simple graphical effect easy to create by providing you with the missile() proc, but that doesn't help you implement different effects - they're still just as difficult whether you have missile() or not. If BYOND instead provided you with some generic procs that could be used to create and manage visual effects, the missile() proc would be something you could implement yourself. Because you build it from native features it's still easy to implement, but it's also customizable and the native features can be used to implement other, more complex features.