snark13
6d7c1c8b6b
Замер 11/15 показал, что loose-механика берёт 28 872 такта в комнате, где не анимируется ни одна плита и не летит ни один кусок. Раскладка зондами m9..m12: два цикла по тайлам 9 852, обход 14 слотов mob 12 090, поиск куска над головой Кида 5 868 (там ещё и банковый трамплин). Два гейта: loose_any (статик pop_map.c) — «идёт ли анимация плит». Ставят пять мест записи ненулевой фазы: make_loose_fall, ветка потолка в check_press, do_knock для обоих рядов и восстановление фазы из room_modif при входе в комнату. Снимает его сам цикл, по факту прохода, в котором не осталось ни одной живой фазы. pop_mob_busy (резидент pop_state.c) — «занят ли слот падающего куска» (active или дочистка clean). Ставит mob_alloc, снимает обход по факту пустой таблицы. В резиденте, а не в pop_room.c, потому что читает его pop_map из банка 3, а писучие статики банкового модуля наружу не видны. Гейт отвечает не на «есть ли в комнате плиты», а на «идёт ли анимация»: у лежащей плиты-потолка фаза нулевая, и крутить нечего (вопрос пользователя). Асимметрия намеренная — ложная единица стоит одного холостого прохода, ложный ноль стоит застывшей навсегда плиты, поэтому взвод стоит рядом с КАЖДОЙ записью, а снятие только по факту пустого прохода. Стало: 132 / 996 / 546, вся функция 28 872 -> 2 760. На кадре работа 801 768 -> 767 928. Ожидание по реестру было -28 000. Покрытие: новый phys_loose_gate_survives_room_change на пятое место взвода (фаза восстановлена входом в комнату) — единственное, которое не прогонял ни один тест, и дающее самый тихий отказ. Мутационная проверка: со снятым взводом тест падает (фаза 3 вместо 4). Заодно отладочный старт сразу в целевую комнату: make ROOM=15 POS=2 (дефолт), roomtest стартует в 11/15 с Кидом в (0,2). kid_init ставит x = x_bump[col] + TILE_SIZEX, а это левая граница СЛЕДУЮЩЕЙ колонки — с неё физика относила Кида в тайл чомпера, и он погибал на старте (найдено пользователем). Сдвиг внутрь на 2: колонку определяет весовая точка кадра, поэтому число снято замером, а не выведено геометрией. План работ между сессиями — docs/perf_registry.md §4: очередь позиций со статусами, текущий бюджет сцены, рецепт её воспроизведения и метод замера. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
122 lines
8.3 KiB
Markdown
122 lines
8.3 KiB
Markdown
# Сцена и замер: факел + чомпер + страж, уровень 11 комната 15
|
||
|
||
Вторая целевая сцена для оптимизации (первая — [`perf_l13_room23.md`](perf_l13_room23.md),
|
||
каскад плит). Здесь узкое место другое: не разовый пик на каскаде, а
|
||
**постоянная** цена статичной комнаты, в которой одновременно живут два
|
||
факела, чомпер и страж.
|
||
|
||
Такты — `totalcycles` MAME (не такты Z80, ≈2,4× номинала, memory
|
||
`sprinter_wait_states_2x`). **Растровый кадр = 430 000.** Хвост кадра — три
|
||
`gfx_wait_vsync`, поэтому логический кадр занимает 3 растра, пока работа
|
||
укладывается в один; при работе 1..2 растра период становится 4.
|
||
|
||
## 1. Сцена
|
||
|
||
Уровень 11, комната 15. Проверено чтением состояния машины:
|
||
`pop_current_level` = 0x0B, `cur_room` = 15.
|
||
|
||
| кто | где | кадр |
|
||
|---|---|---|
|
||
| Кид | (0,2), x=98 | 15 (стойка с мечом) |
|
||
| чомпер | (0,3) | застывший (trob мёртв) |
|
||
| факел | (0,2) — пламя рисуется в ячейке (0,3) | анимируется каждый кадр |
|
||
| факел | (0,7) — пламя в ячейке (0,8) | анимируется каждый кадр |
|
||
| страж | (0,8), x=170 | 171 (боевая стойка) |
|
||
|
||
Ни Кид, ни страж не двигаются: сцена статична, разброс замера — сотни тактов
|
||
на 800 000.
|
||
|
||
## 2. Замер (`09f32ce`, база модуля `roomtest.c` = 0x42AD)
|
||
|
||
867 кадров, зонды A/C/D/E; детализация — тремя отдельными прогонами
|
||
(m1, m5..m7, M/F). **Период кадра: 4 растра во всех 866 интервалах.**
|
||
|
||
| участок | зонды | медиана | доля работы |
|
||
|---|---|---:|---:|
|
||
| **синяя: ввод + heal** | A→m1 | 141 048 | 17,6 % |
|
||
| **синяя: логика** | m1→C | 152 190 | 19,0 % |
|
||
| синяя, всего | A→C | **293 238** | 36,6 % |
|
||
| зелёная: `pop_loose_tick` | C→m5 | 28 872 | 3,6 % |
|
||
| **зелёная: `pop_process_trobs`** | m5→m6 | 92 448 | 11,5 % |
|
||
| **зелёная: `pop_redraw_needed`** | m6→m7 | 190 260 | 23,7 % |
|
||
| зелёная: шов/ворота соседа | m7→D | 9 336 | 1,2 % |
|
||
| зелёная, всего | C→D | **320 916** | 40,0 % |
|
||
| циан: `check_mirror` + `loose_mob_draw` | D→M | 37 458 | 4,7 % |
|
||
| **циан: Кид + страж + fore + HP** | M→F | 148 566 | 18,5 % |
|
||
| циан: `char_fore(KID)` + борта | F→E | 1 740 | 0,2 % |
|
||
| циан, всего | D→E | **187 758** | 23,4 % |
|
||
| **работа** | A→E | **801 768** | 1,86 растра |
|
||
|
||
Циан здесь **не** выделяется: 187 758 — это 0,44 растрового кадра, а разброс
|
||
за 867 кадров всего 174 такта (187 674..187 848). Впечатление «циан ~150 %
|
||
кадра» на глаз не подтвердилось — при периоде 4 растра полосы бордюра
|
||
размазаны по кадрам и на глаз не читаются.
|
||
|
||
## 3. Главная находка: чомпер справа от факела — 190 260 тактов/кадр
|
||
|
||
`pop_dbg_rdmax_tot` = **1**: за кадр перерисовывается РОВНО ОДИН тайл, и
|
||
стоит он все 190 260 тактов зелёной фазы.
|
||
|
||
Цепочка:
|
||
|
||
1. `TORCH_ANIM_DIV = 1` — факел меняет кадр пламени КАЖДЫЙ логический кадр;
|
||
2. пламя запекается в фон (`pop_torch_draw`, `GFX_BANK_NORMAL`), а канвас
|
||
пламени 16×18 лежит **в ячейке правого соседа** (seg008:560) — то есть
|
||
поверх чомпера;
|
||
3. поэтому `pop_process_trobs` метит соседа: `if (trob_rcode[i] == TILE_CHOMP)
|
||
pop_set_redraw(tp + 1, POP_RD_CHOMP, 1)` (порт `set_redraw_anim_right`);
|
||
4. `pop_chomp_redraw` отвечает на пометку **heal 32×64 + полный `draw_tile`**.
|
||
|
||
Расхождение с оригиналом именно в шаге 4. `set_redraw_anim_right` метит
|
||
слой **anim**, и оригинал возвращает только его (`draw_tile_anim_topright` →
|
||
`draw_tile_anim_right` → `draw_tile_anim`) — одну графику чомпера поверх
|
||
огня. Мы вместо этого стираем и пересобираем тайл целиком, со всеми слоями
|
||
(`draw_tile_right`, `base`, `bottom`, `loose`), которые пламя вообще не
|
||
трогало.
|
||
|
||
Цена по модели блита (`blit_cost_model`, 8791 + 198·h + 5,96·w·h):
|
||
heal 32×64 ≈ 33 700, значит на один `draw_tile` уходит ≈ 156 000 — сходится
|
||
с известным замером «полная запечка щебня 179 914».
|
||
|
||
Чомпер при этом **застывший**: своей анимации у него нет, поза не меняется,
|
||
возвращать нужно ровно ту же графику поверх свежего пламени.
|
||
|
||
## 4. Что это даёт и куда смотреть дальше
|
||
|
||
Ранжирование по цене (доля от 801 768):
|
||
|
||
| # | участок | такты | что делать |
|
||
|---|---|---:|---|
|
||
| 1 | `redraw_needed`: чомпер под факелом | 190 260 | вернуть только слой anim, как в оригинале — без heal и без остальных слоёв |
|
||
| 2 | синяя: логика двух Char | 152 190 | графики нет вообще; разобрать `pop_check_can_guard_see_kid` и два `play_seq` |
|
||
| 3 | циан: Кид + страж | 148 566 | оба будятся каждый кадр — метки фона от чомпера/факела накрывают обоих |
|
||
| 4 | синяя: heal двух Char | 141 048 | следствие того же: skip не срабатывает ни разу |
|
||
| 5 | `process_trobs`: два факела | 92 448 | ≈46 000 на факел при блите пламени 16×18 ≈ 14 000 — разобрать накладные |
|
||
| 6 | `loose_tick` | 28 872 | в комнате нет ни одной loose-плиты |
|
||
|
||
Пункты 3 и 4 — одна тема: пока фон трогают каждый кадр, `pop_char_skip_mask`
|
||
не может пропустить ни Кида, ни стража. Пламя метит узко (16×18), а вот
|
||
`pop_chomp_redraw` метит весь тайл со свесом — то есть пункт 1 чинит и часть
|
||
пунктов 3/4.
|
||
|
||
Связанные задачи: `HEAL-WIDTH` и G8 в [`perf_green_phase.md`](perf_green_phase.md)
|
||
— та же болезнь (полный тайл там, где хватает полосы), но на другом
|
||
материале.
|
||
|
||
## 5. Журнал правок по этой сцене
|
||
|
||
| дата | правка | работа | синяя | зелёная | циан |
|
||
|---|---|---:|---:|---:|---:|
|
||
| 2026-08-19 | базовый замер (`09f32ce`) | 801 768 | 293 238 | 320 916 | 187 758 |
|
||
| 2026-08-19 | **P5**: гейты холостого хода в `pop_loose_tick` | **767 928** | 285 864 | 294 384 | 187 764 |
|
||
| | | −33 840 | −7 374 | −26 532 | +6 |
|
||
|
||
Циан не изменился (+6 тактов — шум), и это ожидаемо: `loose_tick` целиком
|
||
лежит в зелёной. Синяя просела на 7 374 без прямой причины в правке —
|
||
скорее всего перераскладка кода банка 3 компилятором; проверять отдельно
|
||
не стали, знак верный.
|
||
|
||
**Полная очередь оптимизаций с оценками — [`perf_registry.md`](perf_registry.md).**
|
||
Там же разложена цена одного блита фона по этапам (замер 2026-08-19, 1603
|
||
блита) и модель зелёной фазы этой сцены.
|