Pixel Movement

by Forum_account
[Share] [Zip]

Pixel Movement v5.1 Update

ID:308566
 
Feb 15 2012, 1:18 pm
I posted an update earlier today. The big changes are:
  • The library now uses the Keyboard library for input. Many vars and procs (ex: the keys list, the lock_input() proc) have been moved to the client.
  • Some default movement behavior has changed. The can_bump() proc now functions more like BYOND's default movement (dense mobs bump into each other). I also changed the way mobs slow down.
  • Added the mob.accel and mob.decel vars. These are used to control how quickly (or slowly) mobs accelerate and decelerate when moving.
The change to how mobs slow down may have a big impact. Previously, it was a common problem that AI-controlled mobs would continue to move after reaching their destination after you called move_to(). This will no longer happen - the mobs slow down if they're not following a path. Unfortunately, this may create new problems if there were situations where this lack of slowing down was desirable. If you simply want a mob to never slow down you can set its decel = 0.

If the change to can_bump() is causing problems, you can easily override it to switch it back to the old behavior:

mob
    can_bump(atom/movable/m)
        if(istype(m))
            return 0
        return ..()
#1 Feb 17 2012, 10:19 pm
Love the demos, but it's impractical to use the isometric one. I tried to use it for a 100x100 map and the farther I got from location 1,1,1 the more the frame-rate dropped; and it wasn't a small drop, either.
#2 Feb 20 2012, 5:04 am
I don't think I've ever tried it with a large map. The library doesn't behave any differently for isometric maps than it does for top down maps. This might be a BYOND bug.
#3 Feb 21 2012, 3:39 am (Edited on Feb 21 2012, 3:49 am)
control-schemes/zelda:
- movement is bugged, (example: try to hold down the 'up' key for a while and then press 'down' key; look what happens then. You move automatically in directions you don't want to)
- it is possible to leave the map through top right corner

intermediate-demo:
- not sure if it is possible now, but should be nice if you add some sort of pushing limit so you can push 1 box and it's fast, 2 boxes at once and it's slower and you cannot push like 3 or more boxes.
- it's visually ugly when you push 2 boxes (that are in a straight line) at once. The one you are not touching to is shaking like shakira.

EDIT: If you push the box into the ice, I think it shouldn't increase its speed. Speed of box on ice should be the same as in the moment when you pushed it on that ice.

Sorry for bad english :P
#4 Feb 21 2012, 5:49 am
The problem with the boxes is because of how they're pushed. When you're pushing a box you're not maintaining contact with it. When you push the box you slow down and the box accelerates, so you're only pushing the box every other tick. By the time you push it again the box has slowed down so it can never build up speed. On ice, the box doesn't slow down so when you do push it, it only speeds up (which is why it can go faster on ice).

It's implemented just about the simplest way possible. I'm not sure how easy all those things will be to add but I'll try to fix it up.
#5 Feb 23 2012, 8:48 am
have any way to use only the code collision with native BYOND pixel movement?
#6 Feb 25 2012, 4:16 am
In response to Diego 110578 (#5)
Diego 110578 wrote:
have any way to use only the code collision with native BYOND pixel movement?

I'm not sure what you mean.

BYOND's native pixel movement handles collisions. The library implements that itself. You have to either use the library's collision detection or BYOND's.

The library does use a lot of BYOND's features related to pixel movement. For example, it sets each object's bound_width, bound_height, step_x, and step_y vars. This way the library can make use of the obounds() proc when checking for collisions. Before BYOND supported pixel movement, the library checked for collisions against all atoms within oview(1) when you moved. Now it can use obounds() to check for collisions against atoms in the exact space you'll be moving through. This was the slowest part of the library and this change really sped things up. The library's collision detection takes about as much time as BYOND's.
#7 Oct 4 2012, 12:53 am
Quick question: With the library I noticed that pwidth and pheight draw the bounding box from the bottom left and then out the programmed dimensions. Is there a way to move the bounding box from the bottom left to, say, the middle of a tile? I'd rather not have to offset the objects to fit the box.
#8 Oct 24 2012, 6:17 pm
In response to Reformist (#7)
Although the native BYOND pixel movement uses bound_x/y for that, this library just makes you use pixel_x/y. Unless it's been changed, of course, but I don't recall that happening yet (nor do I expect it to happen).