weird behavior

[Wouter]

> weird behavior
> Alex Tweedly alex at tweedly.net
> Mon Jul 19 19:06:54 EDT 2004
>
>     * Previous message: weird behavior
>     * Next message: weird behavior
>     * Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
>

--snip

> Not true if you add the polygon in the IDE. You can create a polygon 
> with 3
> vertices, leaving it to default to opaque. (click at 100,100 - click at
> 200,100 - double-click at 200,200)
> The result is that two edges are drawn (i.e. NOT the third closing 
> edge),
> there is no additional (duplicate) point not added to the point list. 
> If
> you give it a fill colour, you will see that it is filled as though the
> third closing edge were there - but the edge itself is not drawn.

No not correct, you didn't do the action complete (and please this is 
no offence). You left out following comment:

< Draw a so called open polygon and **add 2 returns for welformed-ness 
sake**.
Deselect the polygon and reselect it and have a look at the points: the 
so called open polygon is closed now, the first point is added.>

If you draw an "open" ploygon like that and if you look at the points, 
then it is what you called a *malformed polygon*.
If you add 2 returns to make it a *welformed polygon* and  then 
deselect and reselect you will see the engine adds the starting point.
And yes it will be filled, in both cases if there are enclosed regions.
(I only looked at the way the engine works)

> (Though the point, and the drawn edge, will be added when you do 
> certain
> edits to the polygon.)
> And if you do the same thing in a script, you get the last point 
> duplicated
> for you.
>
> >Your so called "welformed <open> polygons" are in fact <closed> ones 
> if
> >the opaque property is set.and the engine gets his way.
> >Have a look at the points.
> >  Draw a so called open polygon and add 2 returns for welformed-ness 
> sake.
> > Deselect the polygon and reselect it and have a look at the points: 
> the
> > so called open polygon is closed now, the first point is added.
>
> See my counter-example above :-)
> btw - after creating the polygon, I deselected the polygon, saved the
> stack, and quit Revolution, then restarted it - all to make sure I was 
> not
> being misled by the Property Inspector lagging the stack contents.

See above

>
> In any case, it is not a requirement that all edges exist on an opaque
> polygon. You can draw an opaque polygon with blank lines in the middle 
> of
> the point list. This results in those edges being left undrawn, and the
> fill behaviour is straightforward (though hard to describe in words). 
> It
> produces a set of non-contiguous shapes; the series of edges between 
> any
> two blank lines (or the start->blank line, and blank line->end) 
> produces a
> filled shape, with an implicit edge being used in the fill but not 
> drawn.
>

Some language problem.
<  it is not a requirement that all edges exist on an opaque polygon >

         the *existence* of en edge

 From the point of the viewer: if it is not drawn, it does not exist.
But from the point of view of the engine, it depends on the order of 
the points to draw
the polygon (or any other form) if an edge exists and if it is visible 
or not.
If a polygon contains a couple of regions, these do not become 
individual polygons, though it can look like it.
>

> I see it as a real bug. If I create a 20-sided opaque polygon, with the
> first point not being duplicated at the end, that produces a filled 
> shape,
> with the last edge not drawn. Then I add a blank line at the other side
> (i.e. between points 10 and 11) of the polygon, and suddenly the last 
> edge
> becomes drawn.  Surely that's a bug ?

No. It is the way the engine works with graphics in relation to the 
opaque property.

>
> But I see no need to add a new property - the existence or 
> non-existence of
> blank lines already provides enough expressive power to describe 
> everything
> needed. Unfortunately, both the engine and the documentation would 
> need to
> change.
>
>
> -- Alex.


I like this, so many different ways to look at the same object, thing, 
problem or whatever.
I am sorry if what I say is not correct from the point of view of a 
particular language.
But there is something like: if your first programming language was C, 
you tend to look at any other language from the point of view of the 
first one you learned. And with assembler this tendency is even worse 
:-))


For Geoff's famous starbattle:   go stack url 
"http://www.inspiredlogic.com/rev/starbattle.rev";

Have fun.

Greetings,
WA