用位图分块+区域合并、距离场LUT查表、dirty rect增量更新，可显著降低战争迷雾CPU开销。
用位图+区域合并避免逐单位重绘
战争迷雾最耗 CPU 的地方，不是计算单个单位视野，而是每帧对每个单位都做一次完整视野扩散（比如 BFS 或 flood fill），再叠加到全局迷雾图上。当上百个单位视野大面积重叠时，重复写同一块内存、反复触发 cache miss、大量分支预测失败，CPU 就卡住了。
核心思路是：不把每个单位的视野当成独立图形去“画”，而是先聚合、再批量更新。
- 维护一个
std::vector<uint64_t></uint64_t>作为分块位图（比如每 64×1 个格子用一个uint64_t，支持快速 OR 合并） - 每个单位只负责生成自己视野对应的「位图块索引 + 掩码」，不操作全局图
- 所有单位提交后，用单层循环遍历所有块，执行
global_fog[block_idx] |= accumulated_mask[block_idx] - 避免使用
std::bitset—— 它的 operator|= 在非对齐访问时会引入分支和掩码计算，实测比裸uint64_t数组慢 1.8×
视野扩散改用距离场预计算 + 查表
运行时做 BFS 或锥形视野裁剪（如 atan2 判定角度）在单位多时开销爆炸，尤其当单位移动频繁但视野半径不变时，纯属浪费算力。
更稳的做法是离线生成「相对坐标 → 是否可见」的查找表：
立即学习“C++免费学习笔记（深入）”；
- 按最大视野半径 R 预生成一张
bool visibility_lut[2*R+1][2*R+1]，用一次 BFS 或几何裁剪填充 - 单位视野更新时，只做两次整数加法（中心坐标偏移）+ 一次二维查表，无分支、无浮点、无内存跳转
- 如果支持不同视野形状（如弓箭手窄远、坦克宽近），就为每种类型缓存一张 LUT，用
enum VisionType索引，别 runtime 重算 - 注意 LUT 的 Y 轴方向要和地图坐标系一致，否则 cache 行失效严重；建议用
lut[y * width + x]一维布局，而非二维数组
用 dirty rect 做增量更新而非全图重刷
迷雾图本身很少全屏变化——多数帧只有几十个格子从「遮蔽」变「可见」，或反过来。但很多实现每帧调用 render_fog_full()，把几 MB 的纹理全传 GPU，带宽和 CPU 绑定都拉满。
- 每个单位视野变更时，只记录其影响的最小包围矩形（
DirtyRect），用std::vector<sdl_rect></sdl_rect>或类似结构暂存 - 帧末合并重叠 rect：排序 + 单次扫描合并，O(n log n) 可接受（n 是单位数，通常
- 只上传合并后的 dirty 区域到 GPU，用
glTexSubImage2D或UpdateSubresource，避免全图同步等待 - 如果用 CPU 渲染（如 SDL_BlitSurface），也只对 dirty 区域调用
SDL_FillRect，别清整个 surface
std::vector 是陷阱，别用它存迷雾状态
看起来省空间，实际让 CPU 开销翻倍。因为 std::vector<bool></bool> 是特化模板，operator[] 返回的是代理引用（proxy reference），每次读写都带位运算和分支判断，无法向量化，LLVM 甚至拒绝对其 auto-vectorize。
- 改用
std::vector<uint8_t></uint8_t>（1 字节/格）或std::vector<uint32_t></uint32_t>（4 字节/格，方便 SIMD 批量清零） - 若真卡内存（比如 10k×10k 地图），用
std::vector<uint64_t></uint64_t>+ bit-manipulation，自己写set_bit(x, y)和test_bit(x, y)，确保编译器能内联成 bts/btr 指令 - 测试过：同样 8192×8192 地图，
vector<bool></bool>的随机读写吞吐比vector<uint8_t></uint8_t>低 3.2×，且导致 L1d cache miss rate 升高 40%
真正难的不是算法，是让所有单位视野变更能 batch 到同一缓存行里处理；一旦内存访问模式变成随机跨页跳，再好的优化也白搭。所以优先检查你的 FogState 结构体是否被 padding 破坏对齐，以及 dirty rect 合并后有没有意外触发 TLB miss。
