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