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

2014/12/31

turnTowards oddity

DoWhileNot DoWhileNot

2014/12/31

#
I'm new to Greenfoot (learning it so that I can teach it to my kids) and I'm working on a little scenario where a bug moves away from its leaf pile, looks around for food, and when it finds it, it heads straight back home to drop it off. Everything is working correctly - I'm using the following code to turn the bug towards its home leaf pile once it's full of chicken, but instead of turning exactly toward the pile, it only turns generally towards it - it'll walk in a straight line for a while, then it turns again to correct its angle, and then walks straight to the leaf pile. 
        
        List<LeafPile> allPiles = getWorld().getObjects(LeafPile.class);
        for(LeafPile pile : allPiles){
            int pileID = pile.queryID();
            if(pileID == getHomeID()){
                turnTowards(pile.getX(), pile.getY());
            }
        }
This isn't a problem for this little scenario - I actually kind of like the non-direct path that the little bugs take, but I can see it being an issue later on. Is this the way turnTowards works, or am I missing something?
danpost danpost

2014/12/31

#
There are hardware limitations at work here. The screen has only so many pixels that your actor can be located at. So when moving very short distances, you are limiting the number of different angles that the actor can move. There are ways to compensate for this behavior, all of which require keeping tabs on the exact location of your actor through added code. This would involve either using a non-integer field type (probably of 'double' type) or using a zoom factor (multiplying by a factor to give in-between values; then dividing by the factor to determine pixel location)..
DoWhileNot DoWhileNot

2015/1/2

#
I see what you mean. The solution for the hardware limitation looks like it's already been worked out though, using Vector and the SmoothMover subclass of actor.
danpost danpost

2015/1/2

#
DoWhileNot wrote...
I see what you mean. The solution for the hardware limitation looks like it's already been worked out though, using Vector and the SmoothMover subclass of actor.
That is what those classes were designed to do (particularly the SmoothMover class).
You need to login to post a reply.