Elizabeth D Rather <erather@[EMAIL PROTECTED]
> writes:
> Duke Normandin wrote:
>> On Thu, 20 Mar 2008, Bruce McFarling wrote:
>>
>>
>> [snip]
>>
>>> : BOX3 ( x1 y1 x2 y2 -- )
>>> dup-points topline LINE
>>> dup-points rightline LINE
>>> dup-points bottomline LINE
>>> leftline LINE ;
>>>
>> So if I wanted to play with all of this as a learning exercise, how
would
>> I define LINE?
>
> The thought model is moving a light beam on the screen. It
> could be off, in which case it makes no mark, or on, in which
> case a line is drawn. Assume two words, ON and OFF, that
> control the beam. The beam stays in whatever state it's set.
> 0, 0 is the upper left corner of the screen.
>
> You have a "current position" in x,y coordinates:
>
> 2VARIABLE CURRENT
>
> And you have a word DRAW, which takes a *desired* position in
> x,y coordinates that drives the pen:
>
> : DRAW ( x, y -- ) GOTOXY CURRENT 2! ;
>
> GOTOXY is a common-usage word that mirrors GETXY by moving the
> cursor. It would probably actually be replaced by some graphics
> primitive.
>
> It's nice to have an incremental draw:
>
> : +DRAW ( dx, dy -- ) CURRENT 2@[EMAIL PROTECTED]
V+ DRAW ;
>
> (V+ would also be a primitive, adding two vectors. I'd write it
> in code, unless I had an optimizing compiler; YMMV. You'll
> probably also want V*/ for scaling world to screen coordinates)
>
> So, let's say you want a box, given the x, y size and x, y
> position of the upper left corner. You're going to have to
> manipulate the deltas:
>
>
> : BOX ( dx dy x y -- ) \ Box of size dx dy starting at x y
> OFF DRAW \ Pen at starting position; dx dy
> OVER 0 ( x 0) ON +DRAW \ Left to right; dx dy
> 0 OVER ( 0 y) +DRAW \ Top to bottom; dx dy
> SWAP NEGATE 0 ( -x 0) +DRAW \ Right to left; dy
> 0 SWAP NEGATE ( 0 -y) +DRAW ; \ Bottom to top
>
> Yeah, there's some stack manipulation. But I think it's
> straightforward, and easy to model in the head. I included
> line-by-line stack comments, although an experienced Forther
> probably wouldn't. It's also a good example to someone learning
> stack management.
Easy?
You had to include line-by-line stack comments to explain,
what is going on, and even in-line ones to show, what is on
the stack at the point.
First, you've introduced state, and you don't restore it on exit,
thus you propagate sloppy programming style.
Second, you've converted to relative drawing primitive, but very
inconvenient ones, if you're trying to solve tasks of that kind.
Third, you've chosen inconvenient order of parameters.
: box ( x y dx dy ) 2swap moveto
over right dup down swap left up ;
Even with stack juggling it is easier to understand.
--
CKOPO BECHA...
CKOPO CE3OH...
|
