Bresenham算法用整数误差累积替代浮点除法以避免累积误差和性能开销；通过sx/sy符号与abs(dx/dy)统一处理八象限；适配C++像素缓冲区时直接映射y*stride+x，并校准坐标系与端点边界。
为什么 Bresenham 算法不用浮点除法
因为每次 dx 或 dy 变化时，用浮点运算（比如 y += dy / dx）会引入累积误差，且除法开销大。Bresenham 的核
心是把斜率比较转成整数增量判断：用一个误差项 error 累积小数部分，一旦超过阈值（通常是 0.5），就触发像素 y（或 x）的跳变。实际实现中，把所有计算放大 2 倍，彻底消除除法和小数——只用加减和位移。
如何统一处理八象限的增量方向
不能只写第一象限（dx > 0 && dy > 0 && |dy| ）就完事。真实场景中起点可能在右下，终点在左上，x 和 y 都要递减。正确做法是先算出符号步长：int sx = (dx > 0) ? 1 : -1;、int sy = (dy > 0) ? 1 : -1;，再对 dx、dy 取绝对值参与主循环。这样一套逻辑覆盖全部八种方向，无需复制粘贴八份代码。
- 始终用
abs(dx)和abs(dy)判断主轴（横/纵） - 误差初始化为
error = abs(dx) - abs(dy)（对称形式，避免乘 2） - 当
error >= 0：沿主轴走一步，同时更新误差error -= 2 * abs(dy) - 否则：沿副轴走一步，误差
error += 2 * abs(dx)
怎么把算法嵌进现代 C++ 像素缓冲区（如 uint32_t*）
多数图形库（如 SDL、自定义 framebuffer）用一维 uint32_t* 存储像素，索引是 y * pitch + x。Bresenham 输出的是整数坐标 (x, y)，直接代入即可。注意：y 轴方向常与数学坐标系相反（屏幕原点在左上），但只要你的 buffer 布局一致，算法本身不关心“上下”，只依赖你传入的起点/终点坐标是否已按显示空间校准。
关键约束：
-
x和y必须在 buffer 有效范围内（0 ,0 ），建议循环内加边界检查，或提前裁剪线段 -
pitch是每行字节数，若每个像素 4 字节，则pitch = width * 4；索引公式为ptr[y * (pitch / 4) + x]或更安全地用ptr[y * width + x]（假设 pitch 对齐） - 颜色写入用
buffer[y * width + x] = color;，不要用setPixel(x, y)这类封装——那会掩盖性能瓶颈
void drawLine(uint32_t* buffer, int width, int height,
int x0, int y0, int x1, int y1, uint32_t color) {
int dx = x1 - x0;
int dy = y1 - y0;
int sx = (dx > 0) ? 1 : -1;
int sy = (dy > 0) ? 1 : -1;
dx = abs(dx);
dy = abs(dy);
int err = dx - dy;
while (true) {
if (x0 >= 0 && x0 < width && y0 >= 0 && y0 < height) {
buffer[y0 * width + x0] = color;
}
if (x0 == x1 && y0 == y1) break;
int e2 = 2 * err;
if (e2 > -dy) { err -= dy; x0 += sx; }
if (e2 < dx) { err += dx; y0 += sy; }
}}
为什么画短线时容易漏掉端点或重复绘制
常见错误是循环条件写成 while (x0 != x1 || y0 != y1)，然后在末尾手动写一次终点——这在 dx=0 或 dy=0 时极易越界或跳过。上面示例用 break 在设置完当前点后立即判断是否到达终点，保证每个整数坐标只写一次，且包含两个端点。另外，整数除法截断、abs(INT_MIN) 溢出、未处理 dx==0 && dy==0 的退化点，都是线上崩溃的隐藏源头。
真正棘手的不是算法逻辑，而是坐标空间对齐：UI 坐标系、OpenGL NDC、framebuffer 内存布局，三者 y 方向常常两两相反。验证时先画一条从 (0,0) 到 (10,0) 的水平线，确认它真出现在屏幕顶部，再动其他。
