Re: [glob2-devel] flags vs. areas: getting the best of both worlds

[Joe Wells]

Kai Antweiler <address@hidden> writes:

>>> I think distance should have a quadratic influence, so that flag
>>> has locally me power.
>>
>> I'm not quite sure what you mean.  Can you give an example?
>
> Maximize: radius / (distance * distance)
> But other formulars might be better.

I'm not sure how the formula you suggest would work in practice.  I
think it would probably have to be implemented and tried, so any
evaluation of that detail would need to wait for later.  And it could
be tried later, no problem.  With my suggestion, I know already
(without needing to implement and test it) that the boundaries between
regions controlled by two flags will be straight lines.  I think many
users will probably find these straight lines easier to use than more
complicated curves.

Anyway, this issue only arises when it is necessary to have
non-circular regions that are adjacent controlled by different flags.
There is no issue at all if the user can leave a gap of unmarked cells
between the two regions.

> Imagine an area of wood and wheat and you want two things:
> 1. get rid of the wood but keep the wheat
> 2. make a small path through the middle

Agreed.  That is likely to come up in practice.

>> I agree that one wants some notion of strength.  I think under my
>> proposal the radius effectively acts as the strength.  See my example
>> below.
>>
>>> For example you might want Flag B to govern most cells to it's left
>>> were it competes with Flag A, but not touch any of the cells to its
>>> right.  Let's say on the right are some cell that you want to be inactive
>>> now, but active at a later time.  And you can't make Flag A smaller
>>> without fragmenting the areas that it should govern.
>>
>> Can you give an example?
>
> I guess it is hard to come up with a good one, because radius and strength
> are positively correlated.
>
>                cc
> aa
> aa
>     bbbb
> a A bbbbB        ccc
>
>  aaa
>  aaa          ccddD
>
>
>> I add another flag C that requests zero workers and clears
>> nothing (and is therefore inactive).
>
> Ok. Works, but imagine that c part is not visible on the screen because
> it is too far on the right.  What you wanted to do is have a strong
> local B impact on the fields to the left that overwrite A.  When you
> increase B you won't expect it to change something far away that you
> don't see and that you don't have in mind right now.

This will be definitely be an issue.  Something would need to be done
to make sure it is easy to tell exactly which cells are affected by a
clearing flag.

In fact, this is already an issue for current clearing flags.  Right
now the only way to know for sure what cells are in the circular
region of a clearing flag is to try it and see what gets cleared.  :-)

>>> When we are already thinking about moving, we can think about
>>> approximating a stretching, shrinking and turning effect as well.
>>
>> What would the user interface for this be like?
>
> In the worst case: keyboard input.
> 4 Keys: stretch, shrink, turn left and turn right.

Rotating by 90 degree increments could be done.  However, I think it
would be hard to get any other rotations or stretching and shrinking
to do the right thing.  It would have all of the problems of rotating
and scaling bitmap images.

> In the best case: a touchpad which can detact two seperate movements.
> (maybe in the next decade.)
>
>> That is the hard part.  
>
> There are harder parts concerning the engine,

It depends.  How is the circular region of current flags actually
used?  Are all of the cells inside the region raised in some gradient?
If that is the case, just raise instead the new set of cells governed
by the flag under the new proposal.  That is a relatively small
change.

> but it is good that
> you care about the implementation effort.
> The easier code changes are the sooner they will be implemented.

-- 
Joe