MoveTo(20,50) LineTo(80,122) 命中的像素与 MoveTo(80,122) LineTo(20,50) 不同
一个非常简单的情况是绘制 (0,0) 到 (2,1)，它命中 (0,0)、(1,0)、(2,1)，同时绘制 (2,1) 到 (0,0) ) 命中 (2,1)、(1,1)、(0,0)，中间像素不同。
Bresenham 是否有一个版本，无论端点之间的绘制方向如何，都能命中所有相同的像素，并且仍然快速高效？我的网上搜索都没有发现任何关于这个问题的讨论。
遇到此问题的代码试图解决移动像素在从 (X0,Y0) 到 (X1,Y1) 的途中停止的问题。另一个从 (X1,Y1) 到 (X0,Y0) 以相反方向移动的像素是否会落在停止的像素上？在许多情况下，使用 Bresenham 计算像素位置会失败。
While doing some graphics programming, I was surprised to learn the typical implementation of the Bresenham line plotting algorithm gives different results when the endpoints are reversed. For example, a line drawn with MoveTo(20,50) LineTo(80,122) differs from MoveTo(80,122) LineTo(20,50) twelve times, each mismatch spaced six pixels apart, such as hitting pixel (78,119) when drawing in one direction while drawing in the other direction hits (77,119).
A very simple case is plotting (0,0) to (2,1), which hits (0,0), (1,0), (2,1), while plotting (2,1) to (0,0) hits (2,1), (1,1), (0,0), differing in the middle pixel.
Is there a version of Bresenham that hits all the same pixels regardless of drawing direction between endpoints, and is still fast and efficient? None of my online searches have turned up any discussion of this issue.
The code that ran into this problem was trying to solve the problem where a moving pixel stopped on its way from (X0,Y0) to (X1,Y1). Would another pixel moving in the opposite direction from (X1,Y1) to (X0,Y0) land on the stopped pixel? Using Bresenham to calculate the pixel positions fails for many cases.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
像素差异是由于舍入行为造成的。如果从低 X 到高 X 画一条线，那么当“真实”Y 为 0.5 时，它将向上舍入。如果以相反的方式画线，那么它会向下舍入。
解决方案（正如 MrSmith42 在评论中提到的）是始终在同一方向绘制同一条线。
Bresenham 的实现必须首先确定哪个轴是主轴，然后它将在循环中沿着主轴进行迭代。
确定长轴后，如有必要，应反转线路，以确保长轴沿正方向移动。
这将简化您的代码，并确保无论输入点的顺序如何，您都能得到相同的结果。
The difference in pixels is due to rounding behavior. If you draw a line from low X to high X, then when the "real" Y is 0.5, it will round up. If you draw the line the other way, then it will round down.
The solution (as MrSmith42 mentions in comment) is to always draw the same line in the same direction.
An implementation of Bresenham's must first determine which axis is the major axis, and it will then iterate along the major axis in the loop.
After determining the major axis, you should reverse the line if necessary to ensure that the major axis will be traversed in the positive direction.
This will simplify your code as well as ensuring that you get the same results no matter what order the input points are in.