Floating point rasterization brings me back to 1993 style rasterizers (when I was 5…) and all of the problems they entail. Dropouts, double renders, endless edge problems, seams… rasterization is a lot of fun. It’s one of the only areas I can think of where fixed point isn’t merely a feature, it’s a necessity.
Not that rasterization was the point. :)
Ironically, I searched for a reference explaining all of these problems, and wound up finding my own HN comment. https://news.ycombinator.com/item?id=21736821 (Who said HN results rarely show up on Google?)
That five part Chris Hecker rasterization series really is the jams though. It covers so much ground, and it even has code that can (with effort) still run. I’ve wanted to reimplement it in JS and make a web version.
Getting edge equations done right / consistently is certainly important. That's not actually a floating point vs fixed point argument though.
There's always going to be rounding and clamping. With fixed point code or fixed-function hardware it's obvious and explicit. You can do all the same range reduction work in fp32.
Modern rasterizers have been outputting "24-bit Z" aka the equivalent of [-0.5, 0.5] in fp32 forever. Said another way: fp32 hardware perfectly implements a signed 23-bit fixed point :).
Not that rasterization was the point. :)
Ironically, I searched for a reference explaining all of these problems, and wound up finding my own HN comment. https://news.ycombinator.com/item?id=21736821 (Who said HN results rarely show up on Google?)
That five part Chris Hecker rasterization series really is the jams though. It covers so much ground, and it even has code that can (with effort) still run. I’ve wanted to reimplement it in JS and make a web version.