From: Russell Marks (russell.marks@dtn.ntl.com)
Date: Tue 01 Feb 2000 - 16:19:39 IST
> Thanks, Rus. :-) BUT, I *have* been looking in tons o' graphics books, > and none of 'em seem to have actual code. The closest I've found was > something by Michael Abrash, but even that didn't help 100%. Oh. Well, it seems there's a pretty neat/fast-looking routine in an old copy of the code from "Graphics Gems" (the AALines stuff). The copyright on that is, er, absent... :-) > The authors and the publisher hold no copyright restrictions > on any of these files; this source code is public domain, and > is freely available to the entire computer graphics community > for study, use, and modification. We do request that the > comment at the top of each file, identifying the original > author and its original publication in the book Graphics > Gems, be retained in all programs that use these files. I'm not sure where you can find the code these days (my copy dates from 1995), but I expect a web search would unearth it pretty quickly. Failing that, I could send you a copy. > Yet another improvement. Now, the antialiased line reads the existing > colors before it writes, to ensure a better blend with the background. > However, some of the diagonal lines still look crappy, especially in > 320 x 200 modes. This does mostly disappear in 640 x 480 and up. Yes, that looks much better, good stuff. It looks like the only remaining problem is that you're doing enough maths per pixel to raytrace the hind legs off a donkey. :-) I s'pose you could get away with that for most things these days though. What are you going to be using it for? (I did consider trying zblast with this, just for kicks :-), but with *that* many lines I think the slowdown might be noticeable. It might be a nice stress-test for it though.) Hmm. Tell you what, just as a simple speedup, how about replacing the percentage stuff with a `percentage' out of, say, 256? That fits the RGB stuff anyway, and would let you use bitshifts (I imagine gcc will optimise to using bitshifts when it can (i.e. for constants), so you most likely needn't even make them explicit), saving six divisions per pixel. The thing I don't get is that the program segfaults on my machine (with svgalib 1.4.1), at about the time the line enters the lower-left quadrant. I can't see an obvious reason why, but I thought I'd just mention it. -Rus.
This archive was generated by hypermail 2.1.4 : Wed 21 Jan 2004 - 22:10:23 IST