用整数计算边界判断有问题

[zengdelang]

考虑这个三角形，左下角是 (0, 0), 右下角 (3.0） 上边 （1.5， 5），从浮点数边来看，上边的点是包括的，中心被覆盖
如果舍入到整数坐标，那三个点的坐标（0， 0） （3.0） （2, 5) 显然这个时候像素（1，5）不在三角形内了

[zengdelang]

蓝色点也会出现错误，浮点数的时候，中心是包括的，计算出来坐标是（0.5， 1.66666667），显然中心在三角形内，转换为整数后，计算出来（0.5， 1.25），这个时候这个像素不管是左上角还是中心，已经都不在三角形内部，也出现了，在浮点数坐标下，原本属于三角形内部的像素点，转换为整数后，反而这个点不属于三角形了

[skywind3000]

实际上使用定点数，情况会好不少

[skywind3000]

转整数，有算少的点，同样也有算多的点，整体面积不变，再，实际显卡内部用定点数，误差会小很多。

[skywind3000]

我曾经考虑要不要换成定点数，最后没换，因为定点数会让可读性变差很多，这是个教程，强调这里应该是一个整数即可，换成定点只是一步之遥，自己换吧。

[zengdelang]

整体这里我觉的不好理解的地方，主要还要考虑TopLeft的情况，如果按照标准的浮点数计算来说，最简单的代码，就是 像素坐标 + 0.5 带入边界函数里，可以不考虑TopLeft的情况，唯一的问题是浮点数精度误差问题，容易出现接缝处有个别点不渲染的问题，使用整数是一种近似方法，在数值稳定性和计算速度能快不少，这块我网上看来不少教程，感觉都没说到近似问题，从斜率上感觉就是不精准，所以找了一个范例，但是如果按照这里的TopLeft的情况来做，其实会出现少点和不增加点的情况，比如一个直角三角形，（0， 0）， （10.2，5） （10.2，23.5）这样，右边的一列中心点不包括在浮点数三角形上，考虑TopLeft，整数三角形也把它剔除了，但是斜边就不好保证了，目前看确实是定点数最合理，考虑现实设备的尺寸，32bit的int类型，16bit整数部分，16bit小数部分，精度不输double

[skywind3000]

24 bit 整数，8 bit 浮点足够了。