ID:121030
 
Sidescroller by Forum_account
This library gives you the basic movement system of a platformer. You can make an action/platform game in minutes!
53 fans · Created Nov 3 2010
You might also be interested in my post from earlier this morning: pixel movement update.

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).
The biggest change aside from making hybrid mode the only mode is that the pixel_move() proc was split into multiple procs. To handle collisions the pixel_move() calls procs in collision.dm that handle collisions with ramps and blocks. Another big change is that the offset_x and offset_y vars have been removed. You can now use pixel_x and pixel_y instead.

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.
I've got money on Lummox JR getting annoyed at how much you were completely stomping them at their own project, FA.

Never stop programming DM for us, we need you. You're not the hero DM deserves, but you're the hero DM needs.
El Wookie wrote:
I've got money on Lummox JR getting annoyed at how much you were completely stomping them at their own project, FA.

That's one way to look at it. The way I hope the staff sees this is that it validates DM. This means that DM is good enough that you can implement big features like pixel movement with it, we don't need to have BYOND implement every feature for us. We might need some new built-in things to help us (this update relies heavily on the step_x, step_y, bound_width, and bound_height vars and the obounds() proc), but simply implementing features directly into BYOND isn't always the best idea.

Never stop programming DM for us, we need you. You're not the hero DM deserves, but you're the hero DM needs.

Heh, thanks! =)
Looking nice as always, thanks for the continuous upkeeping of your awesome libraries Forum_account! :D
El Wookie wrote:
Never stop programming DM for us, we need you. You're not the hero DM deserves, but you're the hero DM needs.

Batman quote?lol
El Wookie wrote:
I've got money on Lummox JR getting annoyed at how much you were completely stomping them at their own project, FA.

Never stop programming DM for us, we need you. You're not the hero DM deserves, but you're the hero DM needs.

Tom is just going to pull a Microsoft and hire FA.
Enzuigiri wrote:

Tom is just going to pull a Microsoft and hire FA.


Hopefully he does. F_A has the ingenuity that BYOND needs.
Bravo1 wrote:
Enzuigiri wrote:

Tom is just going to pull a Microsoft and hire FA.


Hopefully he does. F_A has the ingenuity that BYOND needs.


Going a bit too far imo but he certainly would help things programming wise.
Bravo1 wrote:
Enzuigiri wrote:

Tom is just going to pull a Microsoft and hire FA.


Hopefully he does. F_A has the ingenuity that BYOND needs.

I'm not sucking dick or anything, but F_A is a pretty nifty dude. He could practicly take Tom's job by the time the next update comes in!


And hai ET. I see you started a quote chain. KEEP IT GOING GUYS!
Masterdarwin88 wrote:
Bravo1 wrote:
Enzuigiri wrote:

Tom is just going to pull a Microsoft and hire FA.


Hopefully he does. F_A has the ingenuity that BYOND needs.


Masterdarwin88 wrote:
Bravo1 wrote:
Enzuigiri wrote:

Tom is just going to pull a Microsoft and hire FA.


Hopefully he does. F_A has the ingenuity that BYOND needs.

I'm not sucking dick or anything, but F_A is a pretty nifty dude. He could practicly take Tom's job by the time the next update comes in!


And hai ET. I see you started a quote chain. KEEP IT GOING GUYS!

Conspiracy

Bravo1 wrote:
Enzuigiri wrote:

Tom is just going to pull a Microsoft and hire FA.


Hopefully he does. F_A has the ingenuity that BYOND needs.

Lots of people have the ingenuity that BYOND needs - the feature tracker is full of requests for excellent, useful features. Some are duds but some would be great to have, and even with the voting system I'm not sure the staff can tell the difference.