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