Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How to draw ugly lines fast

cohost.org

Post reply on HN
Print view View original

41–47 of 47 posts

Re: How to draw ugly lines fast

#41

Post by gopla »

moloch-hai wrote: post #39
Agentlien wrote: post #29

Earlier quoted context omitted.

I was a bit surprised by this. Unless this was originally meant to be printed I can't see why a simple animation couldn't have been included. It's essentially pointing out the biggest issue with the article and then shrugging it off, while obviously putting a lot of effort into the writing.

That would be extra work, maybe enough the article would not be published. I will take what we got. Or you could post GIFs yourself. Maybe that seems like too much work?

Here is an article that goes through triangle rasterizing in detail, with explainations of subpixel precision - along with animations that show the quality improvement.

https://kristoffer-dyrkorn.github.io/triangle-rasterizer/

Re: How to draw ugly lines fast

#42

Post by danbruc »

derefr wrote: post #35
danbruc wrote: post #31

Earlier quoted context omitted.

Well, it is deterministic and all but I like my lines to connect the points I specify and not end at nearby ones. A line from (0, 0) to (90, 70) has a slope of 7/9. If you represent that with one fractional digit as 0.8 and then on each step just add 0.8 to the y coordinate, you will end up at (90, 72). If you want to reach (900, 700) you will end up at (900, 720). Two fractional digits will get you to (900, 702), th…

Can you avoid the error — without needing to use higher-precision math for every step — by 1. using higher-precision math only to calculate some control points along the line; and then 2. partitioning long lines into smaller overlapping lines that connect at the control points; so that you can then 3. draw those short lines with the cheap algorithm?

You probably could, but why? The only advantage that the algorithm could maybe claim is conceptual simplicity and this will be gone the moment you start trying to control those errors.

Re: How to draw ugly lines fast

#43

Post by peterfirefly »

ErikCorry wrote: post #37
wiz21c wrote: post #6

On old computers, you could go even faster by precomputing tiles representing little segments at various angles and then copying tiles. The trick here is to realize that you don't need many tiles to represent all the lines. The downside is that it's not quite accurate. But it's much faster. See an example here : https://github.com/wiz21b/lowtech#the-3d

Why 7x7 tiles? Is 8x8 not a much more natural size?

Not in that graphics mode on an Apple II. 7 bits of each byte gives you pixels, the eighth determines which bichromatic palette to use for those 7 pixels.

https://en.wikipedia.org/wiki/Apple_II_graphics#High-Resolut...

> The Apple II's Hi-Res mode was peculiar even by the standards of the day. [...] Each row of 280 pixels was broken up into 40 blocks of seven pixels each, represented in a single byte. Each pair of adjacent pixels generated a single color pixel via artifact color, resulting in an effective resolution of 140×192. The lower seven bits of each byte represented the pixels, while the most significant bit controlled the phase offset for that block of pixels, altering the color that was displayed.

Re: How to draw ugly lines fast

#44

Post by evancox100 »

gopla wrote: post #41
moloch-hai wrote: post #39

Earlier quoted context omitted.

That would be extra work, maybe enough the article would not be published. I will take what we got. Or you could post GIFs yourself. Maybe that seems like too much work?

Here is an article that goes through triangle rasterizing in detail, with explainations of subpixel precision - along with animations that show the quality improvement. https://kristoffer-dyrkorn.github.io/triangle-rasterizer/

Thanks, I had no idea what was meant by sub-pixel, starting from section 6 of your link will explain this and show the smoothed animation.

(By sub-pixel they mean more finely determining the endpoints of the lines on an arbitrary grid finer than the output pixels — NOT physical display sub-pixels.)

Re: How to draw ugly lines fast

#45

Post by wnoise »

fsloth wrote: post #21
OscarCunningham wrote: post #17

Is there a theoretical ideal of what line-drawing and anti-alliasing algorithms are aiming for? Is there a perfect line drawing algorithm you can use if you have the time?

There is a very good signal theoretic framework to discuss this. You can start reading from example Alvy Ray Smith's "A pixel is not a little square" http://alvyray.com/Memos/CG/Microsoft/6_pixel.pdf But in the end, the sampling kernel you choose to sample your line, and, what sort of geometric primitive your line is in the first place, defaults back to matters of taste so there is a very good theoretical basis for d…

The signal theoretic framework depends on bandwidth limitations that often don't hold for signals we want to produce. Sharp lines and boundaries are reasonable things to want.

I'd say the sampling kernels aren't fully matters of taste, but matters of the display or sampling technology instead. Pixels on CRTs are indeed not little squares, but pixels on anything else pretty much are -- though they can be non-contiguous squares, with different patterns for different colors, even, which eliminates any simplicity that the little-square picture intuitively captures.

Fortunately, all this starts to matter less and less as pixel size and spacing gets smaller and smaller.

Re: How to draw ugly lines fast

#47

Post by yesenadam »

ebjaas_2022 wrote: post #38
rahimnathwani wrote: post #28

Earlier quoted context omitted.

That won't work. There are many pages containing that misspelled word :(

44200 hits on Google, for that particular misspelling.

Is there a name for believing that figure Google spits out when it guesses the number of pages? A trustgoogle? A googull? I've seen it in so many places from people I'd think would know better.

Go to page 15 of the results (the last page) and it says

> Page 15 of about 142 results

If I "include omitted results" it claims 331 results, but these include pages with the "horizontal" spelling only...

Post reply on HN