This site requires JavaScript, please enable it in your browser!
Greenfoot back
Twitter Twitter.hover
Duta
Duta wrote ...

2012/3/19

move(double distance)

Duta Duta

2012/3/19

# 
public void move(double distance)
{
    double rotation = Math.toRadians(getRotation());
    distance *= getWorld().getCellSize(); //You can remove this if your cell size is 1.
    int x = getX() + (int)Math.round(Math.cos(rotation)*distance),
        y = getY() + (int)Math.round(Math.sin(rotation)*distance);
    setLocation(x, y);
}
It might be just me, but I've been finding move(...) has been giving me issues with not calculating the move direction correctly (I think since the last update, not 100% though.), so I made this method that seems to work. Also this takes a double rather than int parameter for increased movement accuracy. I thought I'd post this up in case anyone else was experiencing the same problem and needed a new move(...) method
nccb nccb

2012/3/19

#
We do have a bug in recent versions of Greenfoot that mean move(int) messes up if the cell size is not equal to 1. That will be fixed in 2.2.0. Is that the problem? Otherwise, the issue is usually related to the int distances being rounded (e.g. try and move 1 unit at 30 degrees, it won't work very satisfactorily).
Duta Duta

2012/3/19

#
nccb wrote...
We do have a bug in recent versions of Greenfoot that mean move(int) messes up if the cell size is not equal to 1. That will be fixed in 2.2.0. Is that the problem? Otherwise, the issue is usually related to the int distances being rounded (e.g. try and move 1 unit at 30 degrees, it won't work very satisfactorily).
Yeah the problem is it doesn't actually go in the direction you're facing necessarily (especially at angles like 30 degrees and similar). Will this be fixed in the next release?
davmac davmac

2012/3/19

#
We do have a bug in recent versions of Greenfoot
Indeed, the code above contains the same bug. Line 04 should be removed, because setLocation(...) already takes cell size into account.
Yeah the problem is it doesn't actually go in the direction you're facing necessarily (especially at angles like 30 degrees and similar). Will this be fixed in the next release?
That is an issue with accuracy of position; you can fix it by moving in larger increments, or by using the SmoothMover class. It won't be "fixed" in the next release because it's arguably not a bug.
You need to login to post a reply.