Newsgroups: comp.sys.apple2
Path: news.weeg.uiowa.edu!news.uiowa.edu!hobbes.physics.uiowa.edu!zaphod.mps.ohio-state.edu!howland.reston.ans.net!gatech!ukma!lunatix!pbenson
From: pbenson@lunatix.uucp (Paul Benson)
Subject: Re: Gradient Fill Algorithm
Organization: Lexington Public Access Unix. -KY- (606) 255-9121
Date: Sat, 10 Apr 1993 05:03:21 GMT
Message-ID: <1993Apr10.050321.13624@lunatix.uucp>
References: <1993Apr8.034504.10144@nuscc.nus.sg>
Lines: 26

In article <1993Apr8.034504.10144@nuscc.nus.sg> ltchean@iss.nus.sg (Lim Thye Chean) writes:
>Anybody have algorithm on gradient fill for a paint program? 
 
Thye Chean,
I wish you were in the states then I'd just tell you to call me.  This will
be hard to explain in text.  Okay, lets see if we have n colors and our
gradient range has x pixels in it (this is a straight line).  Then we
divide the line into n equal segments, i.e.
  | Seg1 | Seg2 | Seg3 | ..... | Segn |
  |______|______|______|_....._|______|
  1     x/n   2x/n   3x/n  (n-1)x/n   x <--- pixel 'number'
 
We also have a mix factor, m.  So, for a pixel located at pixel number
p, we calculate, color=FLOOR((p+rand(-m..m))*(n/x))+1.  Of course, you'll
have to check for boundary conditions.  Of course your mix factor should
be dependent upon the size, x, if you really want to be fair (i.e. for
a small x, the mix should be weighted for small deltas and a large x, one
increment of m should have the effect of moving the pixel more than one
value left or right). Does that make sense?
Of course this is a close (and fast) approximation of the real way to
do it.  The real way involves line slopes and intersections to provide
probability values.
Hope this helps.
-- 
Pauley
GEnie: P.Benson1