sho@tybalt.caltech.edu (Sho Kuwamoto) (03/08/88)
Has anyone written a lineProc that does a smidgen of anti-aliasing? Depending on the particular setup of the clut, this could look really bad, but I think this would be nice for what I want to do. I'm sort of writing a data analysis/graphing program (only sort of because I'm desparately trying to graduate) and since I don't need that many colors, I thought it would be nice to let users of 256 color machines select an anti-aliasing option where only 16 colors for graphs would be available but the lines would be anti-aliased. This routine should work for both white and black backgrounds. On a similar note, does anybody have any NFNT's of various sizes for Times and Helvetica? (Maybe Avant Garde too) -Sho SonicYouthREMBeatlesKateBushReplacementsResidentsHuskerDuSeveredHeadsArtOfNoise ChrisAndCoseyJoyDivisionKillingJokeLaurieAndersonWireLouReedSkinnyPuppyBrianEno (sho@tybalt.caltech.edu, sho@caltech.bitnet, ...!cit-vax!tybalt!sho)
oster@dewey.soe.berkeley.edu (David Phillip Oster) (03/18/88)
In article <5678@cit-vax.Caltech.Edu> sho@tybalt.caltech.edu.UUCP (Sho Kuwamoto) writes: >Has anyone written a lineProc that does a smidgen of anti-aliasing? Ya, I've done it. Here is the algorithm: 1.) draw the graph into an offscreen, black and white bitmap at double or triple resolution. 2.) Use a tuned assembly language routine to prowl the offscreen bitmap, converting square groups of bits into single, gray pixels, by counting the number of "on" bits in a square. Accumulate these in an offscreen pixmap. 3.) call CopyBits to display the offscreen pixmap. You will want to register the colors your offscreen pixmap uses in the pallette of the window you are displaying in, so no color table arbitratration will be necessary between the offscreen pixmap and the window's pixmap. Anybody willing to post a tutorial on doing a better algorithm? How about stereo on the Mac II? --- David Phillip Oster --A Sun 3/60 makes a poor Macintosh II. Arpa: oster@dewey.soe.berkeley.edu --A Macintosh II makes a poor Sun 3/60. Uucp: {uwvax,decvax,ihnp4}!ucbvax!oster%dewey.soe.berkeley.edu
flip@pixar.UUCP (Flip Phillips) (03/20/88)
In article <23322@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes: >In article <5678@cit-vax.Caltech.Edu> sho@tybalt.caltech.edu.UUCP (Sho Kuwamoto) writes: >>Has anyone written a lineProc that does a smidgen of anti-aliasing? [...] Well, there are a couple of reasonable ways to do it... the afore mentioned posting is a good example. You can simply low-pass filter the thing too... you can implement this in assembler pretty well [I'll post some 'C' code if anyone is interested] I also have a 'hard edge' anti-aliaser too which looks for abrupt changes in the image (i.e. a line across a white background) and only antialiases where it is necessary. It isnnt much faster but it is useful if you want to anti-alias as a post- line drawing step. You can use a mask layer if you dont want to anti alias anything else. (ie. draw bunch of lines, register lines in mask layer, draw other stuff (text, pictures). run anti-aliaser using mask layer...) I can post/mail this maybe... >Anybody willing to post a tutorial on doing a better algorithm? >How about stereo on the Mac II? Well, no stereo, but I do have REALLY fast 3d transform & patch subdivision routines for machines with a 68020/68881. (written on an SE w/ radius accelerator, tested on a II) Any takers? -- Flip Phillips {sun | ucbvax}!pixar!flip Pixar - Marin County, California