Sidescroller

by Forum_account
Sidescroller
This library gives you the basic movement system of a platformer. You can make an action/platform game in minutes!

Sidescroller Update

ID:118422
 
Sep 11 2011, 1:22 pm
Sidescroller v3.0

This update adds a few new mob vars (accel, decel, and gravity) and support for BYOND's built-in pixel movement. Just like in the Pixel Movement library, any project that was created using the library will now automatically work with BYOND's built-in feature. Some features of the library aren't compatible (ramps), and because of this you can still configure the library to run in legacy mode (use soft-coded pixel movement).

Here's the list of changes:
  • Fixed a bug with fractional moves in the y direction. Thanks to Kaiochao for pointing it out!
  • Added accel, decel, and gravity vars to mobs. These vars are all 1 by default and control the mob's acceleration and deceleration rates (gravity being the acceleration rate due to gravity).
  • Added a demo called v3.0 that shows examples of using the new accel, decel, and gravity vars.
  • Added support for BYOND's built-in pixel movement. This is enabled by default, but you can switch back to legacy mode by enabling a compiler flag in _flags.dm. The legacy mode uses the old soft-coded pixel movement which is necessary for supporting ramps.
Sep 11 2011, 1:43 pm
A while ago I noticed that the Pixel Movement library was getting downloads at a higher rate than the Sidescroller library. In the last few days it finally passed the SS lib in # of downloads. I always thought this was strange because, even before native pixel movement was added, I always considered the sidescroller library to be way more useful. I try to pay attention to who is using the libraries and, not that I keep an accurate count, but it always seemed like there were more projects that use the sidescroller library.
Sep 11 2011, 4:44 pm
Why is it that the ramping system doesn't work with native pixel movement? Is there something you need access to that isn't provided?
Sep 11 2011, 5:47 pm
i downloaded latest version and i have 34errors: mostly missing vars and procs...why's this.?
Sep 12 2011, 3:42 am
Anime HQ wrote:
i downloaded latest version and i have 34errors: mostly missing vars and procs...why's this.?

Try going into _flags.dm and changing it to legacy mode (change the line "#define METHOD NATIVE" to "#define METHOD LIBRARY"). The flags in _flags.dm change what code gets compiled. You can comment out all #define statements in the library and put the #define statements in the .dme file for your project so that your project's settings aren't dependent on the library.

Tom wrote:
Why is it that the ramping system doesn't work with native pixel movement? Is there something you need access to that isn't provided?

I can probably get them to work, it's just more difficult because there's no built-in support for them. The change to support native pixel movement was pretty minimal, but ramps end up being special cases in more places. The library then ends up being a mix of native pixel movement for some collisions, soft-coded collisions for ramps.

I'm not sure what's provided. I'd have to implement ramps in turf/Enter() and atom/movable/Cross(), but I'm not entirely sure how they work. There's probably some way to get the necessary information (the move that was trying to be performed) and as long as adjusting step_x and step_y within those procs doesn't cause issues, it should work okay.
Sep 12 2011, 5:56 am
Actually, I'm not sure it would be that easy to add ramps. I need to handle the collision every time you make a move and Enter/Cross are only called when you begin to overlap the object. I'd need to override the collision detection and resolution. Ramps are even more of a special case than that because they also affect calls to bounds(), they'd often be turfs (and turfs don't have bound_ vars), and they affect some behavior that doesn't involve collisions (when you begin to walk down a ramp you stick to the floor).

I'd have to check, before calling Move() if the move would make you hit a ramp and preemptively adjust the parameters that'll be passed to Move() to make the move "proper", according to how the ramp goes. For example, if you try to move 8 pixels to the right and you're 5 pixels away from a 45 degree slope, I'd adjust the move to be (8,3) instead of (8,0), then call Move(). I'd have to do something similar for walking down slopes too.

The library can already do this because it can already handle ramps entirely in DM code. I'm not sure what could be added to make this easier to implement. I'd need access to a lot of stuff that's most likely too deeply internal.
Sep 12 2011, 3:06 pm
Ok I will
Sep 13 2011, 3:54 pm
There's a bug in the compilation. If you turn off FOUR_FLAGS an error will appear in mob-movement.

I'm guessing you should use ifdef FOUR_FLAGS like you do when defining on_ceiling and the other two for the chunk of code that processes their values, instead of the ifndev return.
Sep 13 2011, 3:56 pm
Yup, it fixed it, though I haven't tested it in game yet.

Old code:

           #ifndef FOUR_FLAGS
            return
            #endif

            // this still isn't perfect, but it's better. it's not
            // perfect because the bounding box is only offset, it's
            // not stretched.
            for(var/atom/a in bounds(src, -1, 0) - bounds(src))
                if(can_bump(a))
                    on_left |= (1 | a.flags | a.flags_right)

            for(var/atom/a in bounds(src, 1, 0) - bounds(src))
                if(can_bump(a))
                    on_right |= (1 | a.flags | a.flags_left)

            for(var/atom/a in bounds(src, 0, 1) - bounds(src))
                if(can_bump(a))
                    on_ceiling |= (1 | a.flags | a.flags_bottom)


New code:

            #ifdef FOUR_FLAGS

            // this still isn't perfect, but it's better. it's not
            // perfect because the bounding box is only offset, it's
            // not stretched.
            for(var/atom/a in bounds(src, -1, 0) - bounds(src))
                if(can_bump(a))
                    on_left |= (1 | a.flags | a.flags_right)

            for(var/atom/a in bounds(src, 1, 0) - bounds(src))
                if(can_bump(a))
                    on_right |= (1 | a.flags | a.flags_left)

            for(var/atom/a in bounds(src, 0, 1) - bounds(src))
                if(can_bump(a))
                    on_ceiling |= (1 | a.flags | a.flags_bottom)
            #endif
Sep 13 2011, 4:13 pm
I would also like to request a proc called px_rescue() which is empty by default but it gets called when the mobs loc is null due to the effect of pixel_move(). This way, if someone wants their mob to be repositioned onto the map after falling off, they can do so by overriding px_rescue().
Sep 13 2011, 5:07 pm
Another bug, mobs with a pwidth or pheight greater than 32 will not bump properly, and instead pass through each other. In my case world icon_size is 64 and the mobs height is 48.
Sep 13 2011, 5:10 pm
Well Forum_account it didn't workk and yeahh I noticed that too...
Sep 13 2011, 5:21 pm
Works fine for me except for a bug here and there. Oh also, Byondling nay-1
Sep 13 2011, 6:14 pm
Man pixel movement makes my game lag like crazy lol...
Forum_account can you please check out our source for us please.?
Our source is somewhat big you know, getting bigger nd bigger everyday...
Sep 13 2011, 11:10 pm
lol i did what you said Forum_account but now it says "procs.dm:131:error: unexpected token: LIBARY"