 考虑这个三角形，左下角是 (0, 0), 右下角 (3.0） 上边 （1.5， 5），从浮点数边来看，上边的点是包括的，中心被覆盖 如果舍入到整数坐标，那三个点的坐标（0， 0） （3.0） （2, 5) 显然这个时候像素（1，5）不在三角形内了
Activity
zengdelang commentedon Jan 24, 2023
蓝色点也会出现错误，浮点数的时候，中心是包括的，计算出来坐标是（0.5， 1.66666667），显然中心在三角形内，转换为整数后，计算出来（0.5， 1.25），这个时候这个像素不管是左上角还是中心，已经都不在三角形内部，也出现了，在浮点数坐标下，原本属于三角形内部的像素点，转换为整数后，反而这个点不属于三角形了
skywind3000 commentedon Jan 24, 2023
实际上使用定点数，情况会好不少
skywind3000 commentedon Jan 24, 2023
转整数，有算少的点，同样也有算多的点，整体面积不变，再，实际显卡内部用定点数，误差会小很多。
skywind3000 commentedon Jan 24, 2023
我曾经考虑要不要换成定点数，最后没换，因为定点数会让可读性变差很多，这是个教程，强调这里应该是一个整数即可，换成定点只是一步之遥，自己换吧。
zengdelang commentedon Jan 25, 2023
整体这里我觉的不好理解的地方，主要还要考虑TopLeft的情况，如果按照标准的浮点数计算来说，最简单的代码，就是 像素坐标 + 0.5 带入边界函数里，可以不考虑TopLeft的情况，唯一的问题是浮点数精度误差问题，容易出现接缝处有个别点不渲染的问题，使用整数是一种近似方法，在数值稳定性和计算速度能快不少，这块我网上看来不少教程，感觉都没说到近似问题，从斜率上感觉就是不精准，所以找了一个范例，但是如果按照这里的TopLeft的情况来做，其实会出现少点和不增加点的情况，比如一个直角三角形，（0， 0）， （10.2，5） （10.2，23.5）这样，右边的一列中心点不包括在浮点数三角形上，考虑TopLeft，整数三角形也把它剔除了，但是斜边就不好保证了，目前看确实是定点数最合理，考虑现实设备的尺寸，32bit的int类型，16bit整数部分，16bit小数部分，精度不输double
skywind3000 commentedon Jan 25, 2023
24 bit 整数，8 bit 浮点足够了。