From 39c324753207aa4c35f363ab0fae4f15a83d5988 Mon Sep 17 00:00:00 2001 From: Alexander Petrov Date: Wed, 19 Aug 2026 18:56:07 +0300 Subject: [PATCH] =?UTF-8?q?=D0=94=D0=BE=D0=BA=2013/23:=20=D1=80=D0=B5?= =?UTF-8?q?=D0=B3=D1=80=D0=B5=D1=81=D1=81=20=D0=BF=D0=BE=D1=81=D0=BB=D0=B5?= =?UTF-8?q?=20=D0=B4=D0=BD=D1=8F=20=D0=BE=D0=BF=D1=82=D0=B8=D0=BC=D0=B8?= =?UTF-8?q?=D0=B7=D0=B0=D1=86=D0=B8=D0=B8=2011/15?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Максимумы по секциям против эталона mob-order-B-done: работа 911 862 (-1 986), синяя 149 106 (-10 704), зелёная 436 494 (-3 924), циан 382 770 (-10 230). Период 3 растра в 2341 кадре, 4 в 23, 5 в 2 — как в эталоне. Записано, почему сумма минусов по фазам не равна минусу по работе: максимумы разных фаз достигаются в разных кадрах, а «работа» — максимум суммы, а не сумма максимумов (вопрос пользователя). Отмечено, что зелёная по-прежнему выше растрового кадра и главный оставшийся кандидат для этой сцены — P9 (G8): сосед падающей плиты перезапекается целиком и повторно, при шести плитах это умножается. И записан урок процесса: прогон 13/23 обязателен после каждой правки loose-механики — именно он вскрыл пропущенный взвод гейта в check_fall_flo, которого не поймали ни хост-тесты, ни сцена 11/15. Co-Authored-By: Claude Opus 5 --- applications/PoP/docs/perf_l13_room23.md | 32 ++++++++++++++++++++++++ 1 file changed, 32 insertions(+) diff --git a/applications/PoP/docs/perf_l13_room23.md b/applications/PoP/docs/perf_l13_room23.md index b0e3dc0..6c1042e 100644 --- a/applications/PoP/docs/perf_l13_room23.md +++ b/applications/PoP/docs/perf_l13_room23.md @@ -237,3 +237,35 @@ memory `blit_cost_model`), а 16-битная арифметика в стеко Существующая страховка уже есть и остаётся: `pop_blit_b` уводит кадр с `img[1] | img[3] != 0` на общий путь `blit_b_oversize`. + +**Регресс после дня оптимизации 11/15 (`d0ac4b1`, 2026-08-19), 2367 кадров:** + +| максимум по секции | эталон `mob-order-B-done` | сейчас | разница | +|---|---:|---:|---:| +| работа | 913 848 | **911 862** | −1 986 | +| синяя | 159 810 | **149 106** | −10 704 | +| зелёная | 440 418 | **436 494** | −3 924 | +| циан | 393 000 | **382 770** | −10 230 | + +Период: **3 растра в 2341 кадре, 4 в 23, 5 в 2** — как в эталоне. + +Почему сумма минусов по фазам не равна минусу по работе: максимумы разных +фаз достигаются В РАЗНЫХ КАДРАХ (пик синей — не тот кадр, где пик зелёной), +а «работа» здесь — максимум СУММЫ, а не сумма максимумов. + +Что из правок 11/15 сюда дошло: P16 и P2b дали синюю и циан (они про +проверки и луч видимости, а те работают в любой сцене), HEAL-WIDTH дал +зелёную (плита 64 → 58 на шести heal'ах кадра). + +**Зелёная по-прежнему выше растрового кадра** (436 494 против 430 000). +Главный оставшийся кандидат именно для этой сцены — **P9 (G8)**: при +падении плиты помечаются ДВА тайла, и соседний перезапекается целиком и +повторно (`draw_tile` соседа дважды на одну пометку), хотя потревожены у +него только левые 28 пикселей. При шести падающих плитах это умножается +на шесть. + +**ВАЖНО ДЛЯ ПРОЦЕССА.** Этот прогон вскрыл регрессию, которую не поймали +ни хост-тесты, ни сцена 11/15: гейт `loose_any` (позиция P5) не взводился +в `check_fall_flo`, и плиты уровня 13 дрожали, не падая. Сцену 13/23 надо +прогонять после КАЖДОЙ правки loose-механики, а не только когда меняешь её +сознательно.