Greenfoot

2011/9/26

Turtle graphics bug: move(), turn() overrides

2011/9/26

Folks, I've just started playing with Greenfoot as part of a project to develop programming teaching at my daughter's local school. I'm a C++ programmer (20 years) with enough Java to get by with, and many years ago I used to help teach LOGO to primary kids; Greenfoot looks like the modern way to do the same, and I'm really looking forward to getting the school using it. I was playing with the Turtle scenario and found that some of the subclasses (e.g. SquareTurtle) were moving but not plotting any lines. I've also been playing with my own FractalTurtle (see below) and found the same thing. The problem seems to arise because move() and turn() in Turtle have a 'double' parameter, while in Actor they are 'int'. So if (as in SquareTurtle) they are called with an 'int' the Turtle versions are bypassed and the non-plotting Actor versions are called. If you change the SquareTurtle code to explicitly use doubles (e.g. move(50.0); turn(90.0); ) then it works fine. This is Linux (Debian Squeeze) with Java 6. For your amusement, here's my FractalTurtle code... It's interesting the difference between the iterative step-at-a-time mode of programming that the act() model enforces vs. the conventional procedural model that it needed for recursion which we used to teach in LOGO - I've ended up making it spin round just to give act() something to do! Thanks and best wishes Paul ------

import greenfoot.*;  // (World, Actor, GreenfootImage, and Greenfoot)

/**
 * Turtle using recursion to draw a fractal tree
 * 
 * @author Paul Clark
 * @version 0.1
 */
public class FractalTurtle extends Turtle
{
    public FractalTurtle()
    {
    }

    public void act()
    {
        draw(6);
        turn(15.0);
    }
  
    public void draw(double depth) 
    {
      // Bottom out
      if (depth == 0) return;

      // Draw two-branched tree and recurse
      penDown();
      move(depth*15);
      turn(30.0);
      draw(depth-1);
      turn(-60.0);
      draw(depth-1);
      turn(30.0);
      
      // Return to start
      penUp();
      move(-depth*15);
    }
}

nccb

2011/9/26

The reason for this is historical. Greenfoot used to not include a move(int amount) method, so the turtle move was the only available move and thus there was no problem. Recently, we decided to add the move(int amount) method, and one of the drawbacks we were aware of was that any scenario that had a move(double) or move(float) method would suffer this ambiguity. We went ahead anyway, but you have run into the problems that this change can cause. One way to fix it is to add a move(int amount) method to Turtle that calls move(double amount) -- this would avoid the possibility of accidentally calling the Actor.move. You can do that in your version -- and we should probably do the same in our reference version of the scenario.

sandtreader

2011/9/26

OK, understood. Would it be helpful if I fixed this up and submitted it as a scenario, maybe with some interesting fractal bits and bobs too? Cheers Paul

nccb

2011/9/26

Yes -- an ideal location for that would be in our teachers' area, The Greenroom. You may also find some of the resources in the Greenroom useful for further supporting the teaching at your daughter's school.

mik

2011/9/26

To clean this up a little, I would probably replace the move(double) and turn(double) methods with an move(int) and turn(int) methods in the Turtle superclass. This was, move and turn would override the inherited methods, and the confusion goes away.

sandtreader

2011/9/26

I think move(double) is possibly good if you're doing precision work; I just provided move(int) and turn(int) in Turtle as 'nccb' suggested. Fixed version with some pretty fractal trees & snowflakes at Fractal turtles scenario I must say this is a very fun environment to play in for someone who is used to emacs & make! Kind regards Paul

You need to login to post a reply.

Activity

About

Documentation

Download

Discuss

Scenarios

Turtle graphics bug: move(), turn() overrides