Sprinter-SDCC/applications/SprPoP/docs/perf_green_phase.md

# ЗЕЛЁНАЯ фаза (слой фона) — анализ и оптимизация

Рабочий документ: живёт между сессиями.  Внизу **журнал правок** — каждая
запись с замером до/после.  Сцена, рецепт воспроизведения и зонды —
[`perf_l13_room23.md`](perf_l13_room23.md); там же ответ про 8-битные
габариты.  Парная фаза — [`perf_cyan_phase.md`](perf_cyan_phase.md) (её цель
достигнута).

Границы фазы в `sprpop.c`: от `PROF(4)` (строка 450) до `PROF(6)`
(строка 620).  Содержимое: `pop_loose_tick`, `pop_process_trobs`,
`pop_redraw_needed`, шов, смена уровня, сигналы провалов, вспышка.

**Бюджет: ≤ 400 000 тактов (растровый кадр = 430 000).**

| состояние | было (`c312e4a`) | стало (`af189a1`) |
|---|---:|---:|
| покой в комнате 23 | 35 760 | 35 760 |
| дрожат 6 плит-потолков | 366 000 | 335 400 |
| **пик каскада** | **805 000** | **546 900** |

**ЦЕЛЬ ФАЗЫ НЕ ДОСТИГНУТА: 546 900 против 400 000 (1,37×).**  Что осталось
сделать и почему это именно раскол `draw_tile` — §3.

---

## 1. Раскладка ПОСЛЕ правок (замер `af189a1`)

Пик — кадры 24-28 (посадки плит), больше не кадры провалов.

| участок | покой | дрожь | пик |
|---|---:|---:|---:|
| `pop_loose_tick` | 36 234 | 36 234 | **156 762** |
| `pop_process_trobs` | 1 050 | 1 050 | 1 050 |
| **`pop_redraw_needed`** | 924 | 288 800 | **380 568** |
| хвост (шов, смена уровня, сигналы, вспышка) | 9 336 | 9 336 | 10 776 |

`pop_loose_tick` изнутри на пике: два цикла по тайлам 9 852,
**`pop_loose_mob_tick` 154 074** (heal шести летящих кусков), остальное мелочь.

### Цена одной перерисовки: было → стало

| вид | было | стало | чем |
|---|---:|---:|---|
| `RDA_CEIL` — дрожащая плита-потолок | 48 785 | **43 536** | G2 + G3 |
| `RDA_CEIL_GONE` — запечь колодец | 251 335 | **138 318** | **G1** (клип полосы) + G2 + G3 |
| `RD_FLOOR` — щебень на месте посадки | 198 805 | **179 914** | G2 + G3 + снятая двойная пометка |

Штук за кадр: `RDA_CEIL` до 6, `RDA_CEIL_GONE` до 2, `RD_FLOOR` до 2.

### Детальный профиль `RD_FLOOR` (179 914) — главная оставшаяся статья

Снят зондами по каждому блиту (`pop_dbg_b1/b5`) и по рамкам
(`pop_bar_black`, `pop_cd_batch_begin/end`):

| участок | такты |
|---|---:|
| вход `pop_floor_bake` + `gfx_set_bank` | 2 382 |
| `pop_bar_black` 60×39 (включая `pop_cd_touch` 4 502) | ~15 500 |
| **контекст `draw_tile` #1** (5 чтений тайлов, `63*row`, индексация таблицы) | **13 584** |
| 4 блита тайла #1 | 50 718 |
| **диспетчер между блитами #1** (все `if (code == …)`) | **11 388** |
| **контекст `draw_tile` #2** | **13 584** |
| 4 блита тайла #2 | ~54 000 |
| **диспетчер между блитами #2** | **11 388** |
| хвост | 6 474 |

Итого: **105 500 — сами блиты (реальные пиксели), 74 400 — накладные**, из
которых 27 168 контекст двух `draw_tile` и 22 776 их диспетчер.

---

## 2. Что сделано (с чем сравнивать)

### G1. Окно клипа для точечной перерисовки — −90 000

`pop_t_win_set(x, ytop, w, h)` / `pop_t_win_clear()` в `pop_tile.c`: ставит
уже существующее окно `pop_t_fclip_*` на прямоугольник, который перерисовка
восстанавливает.  Работает в обе стороны — и предфильтр `pop_blit_b`
отсеивает куски мимо окна ДО `atlas_image`/`gfx_w0_map`, и `blit_b_clip`
режет остальные по нему.

Где сработало: `pop_ceil_bake_empty` — куски ряда 0 высотой 63 px рисовались
целиком, хотя восстановить надо девять строк полосы.  **Блит 21 447 → 7 619**,
вся перерисовка 251 335 → 138 318.

Где НЕ сработало — см. §4, отрицательные результаты.

Побочно: пока окно стоит, `pop_blit_b` не ставит пометку «фон трогали»
(признак fore-прохода), поэтому вызывающий обязан пометить прямоугольник сам.
В `pop_ceil_shake_draw` добавлен явный `pop_cd_touch` на область heal'а; в
`pop_ceil_bake_empty` и `pop_floor_bake` метит `pop_bar_black`, а лишний
второй вызов на ту же область снят.

### G2. Контекст тайла — file-scope, а не локали `draw_tile` — −55 000

Порт `load_curr_and_left_tile` (seg008:0339): у оригинала это
`curr_tile`/`curr_modifier`/`draw_xh`/`draw_main_y`/`draw_bottom_y` —
переменные модуля, а не локали.

Причина в кодогене: в `draw_tile` **57 вызовов**, и каждое живое через вызов
значение SDCC спиливал в стековый кадр — 26 байт кадра и **513 обращений
`-N(ix)`** (при ~46 замеренных тактах на обращение это ~23 600, что и
намерено).  Стало **33 обращения**, кадра нет, банк 7 −703 Б.

### G3. `blit_b_clip` — байтовый габарит + file-scope

Два шага, и важен порядок наблюдений:

1. **Байтового габарита ОДНОГО НЕ ХВАТИЛО.**  `sx/sy/dw/dh` → `uint8_t`
   (корректно: кадры атласов ≤ 56×63) дало 211 → 173 обращения, а
   22-байтовый кадр остался: значений, живых через шесть вызовов ядер libbgi,
   всё равно больше, чем регистров у Z80.
2. **Решило вынесение из локалей** (`bc_*`): 51 обращение, кадр 22 → 12 Б.

Клипованный блит 14 088 → 11 848.  Заодно `blit_b_oversize` больше не ходит
через `blit_b_clip` (там теперь байтовый габарит) — рисует напрямую
`gfx_blit_part`; это путь под полноэкранные подложки интро/финала.

### G4. Мелочи

- `pop_blit_b`: аргументы в file-scope (третий и дальше SDCC передаёт стеком,
  каждое чтение шло через `-N(ix)`) — 76 → 11 обращений.
- `pop_loose_mob_tick`: пометки всех кусков ОДНИМ пакетом
  (`pop_cd_batch_begin/end`) — было по 4 502 такта на кусок.
  176 772 → 168 600.
- Коридор heal куска — по фактической высоте СОБРАННОГО композита (было 24
  строки константой, стало 20).  168 600 → 156 762.

---

## 3. Что осталось: раскол `draw_tile` (позиция G5)

**Оставшийся разрыв: −147 000.**  Он весь в двух местах.

### G5. Расколоть `draw_tile` на узкие части, как в оригинале

**Ожидание: −50 000 … −60 000.**

У оригинала `draw_tile` (seg008:01C7) — это девять независимых вызовов:
`draw_tile_floorright`, `draw_tile_anim_topright`, `draw_tile_right`,
`draw_tile_anim_right`, `draw_tile_bottom`, `draw_loose`, `draw_tile_base`,
`draw_tile_anim`, `draw_tile_fore`.  Для ряда −1 он зовёт шесть из них
(`draw_tile_aboveroom`, seg008:01F2), для полосы у потолка — те же шесть плюс
`draw_tile_wipe(3)` (`redraw_needed_above`, seg008:02C1).

У нас всё это — ветки `if (row >= 0)` ВНУТРИ одной функции, то есть контекст
(13 584) и диспетчер (11 388) оплачиваются целиком всегда.  Расколов, каждая
точечная перерисовка сможет звать только нужные части:

- `pop_floor_bake`: вместо второго полного `draw_tile(row, col+1)` — только
  его правую грань и базу;
- `pop_ceil_shake_draw` / `pop_ceil_bake_empty`: дословный
  `draw_tile_aboveroom`;
- `pop_loose_shake_draw`, `pop_spike_redraw`, `pop_gate_redraw` — то же.

Риск средний: у `draw_tile` собрано много инвариантов (BUG-LOOSE-3,
BUG-LATTICE-DOORTOP, BUG-SEAM-WEDGE-1), проверять придётся прогонами всех
уровней.  Поэтому делать отдельным заходом, а не хвостом другой правки.

### G6. Меньше блитов в `RD_FLOOR`

**Ожидание: неизвестно, надо мерить.**  105 500 из 179 914 — это 7,6 блита,
и они рисуют настоящие пиксели.  Сократить можно только сократив то, что
восстанавливается: бар сейчас 60×39 от `yb+26`, а плита занимает по вертикали
меньше (её куски: левая грань `POP_LOOSE_FRAM_LEFT` 32×13 на `dmy = yb+62`,
низ `POP_LOOSE_FRAM_BOTTOM` 32×3 на `dby = yb+65`, правая грань в соседе
26×16 на `dby−1`).  То есть плита живёт в `yb+47 .. yb+65`, а бар начинается с
`yb+26` — **21 лишняя строка сверху**.

Проверять осторожно: бар заодно стирает и то, что рисует ДРУГИЕ куски тайла
(орнаментная лента `stripe_id` на `dmy−27 = yb+35` попадает как раз в
«лишнюю» часть).  Сузишь бар — надо убедиться, что ничего не осталось.

### G7. heal летящих кусков — 154 074 (28 % фазы)

Шесть кусков × ~25 700: сам heal 64×20 (по модели ~19 700) + пакетная
пометка + накладные `mob_tick_one` (16-байтовый кадр, 99 обращений `(ix)`).
**Сам heal у предела железа** — это 1 280 пикселей на кусок, оптимизировать
нечего, кроме площади.  Площадь уже подрезана до габарита композита.

Остаётся `mob_tick_one` (~4 500 на кусок = 27 000 на кадр) — то же лечение
file-scope, что у `draw_tile`.

### G8. Пометка соседа — узкой полосой, а не полным тайлом (идея пользователя)

**Ожидание: заметное, но не мерено.  Взять ПОСЛЕ обхода всех уровней**
(решение пользователя 2026-08-17: пока идёт отлов багов слоёв, каждая правка
добавляет переменных в картину).

Когда плита (1,8) падает, помечаются ДВА тайла:

| пометка | что делает |
|---|---|
| `(1,8)` → `RD_LOOSE_GONE` | бар 40 на своём x, бар 32 на соседе, `draw_tile(1,8)` + `draw_tile(1,9)` |
| `(1,9)` → `RD_FLOOR` | бар **60** на x соседа, `draw_tile(1,9)` ЕЩЁ РАЗ |

То есть сосед перезапекается ЦЕЛИКОМ и ПОВТОРНО, хотя потревожили у него
только левые 28 пикселей — там, куда свисает правая грань упавшего тайла.
`draw_tile(1,9)` при этом вызывается дважды на одну пометку.

Что такое эти числа (чтобы не сузить лишнего):

- **60 = 32 свой тайл + 28 СОБСТВЕННЫЙ свес.**  Правая грань пола (кадр 42,
  26 px) рисуется в клетке соседа с `x+32`, занимая `x+32..x+57`.  Для запечки
  САМОГО тайла 60 уже минимальны — сужать их нельзя;
- сузить можно только тот случай, когда тайл помечен ПОТОМУ ЧТО ИЗМЕНИЛСЯ ЕГО
  ЛЕВЫЙ СОСЕД: тогда нужна полоса 28 px у левого края, а не весь тайл.

Почему выигрыш не символический: `pop_floor_bake` стоит **179 914** тактов,
из них 105 500 — сами блиты.  Узкая полоса срезала бы и площадь бара
(60×39 → 28×39), и часть блитов — окно клипа там теперь стоит обязательным
(см. §4), так что отсев достаётся даром.

**Условия, из-за которых это не «просто уменьшить число»:**

1. `pop_floor_bake` — ОБЩАЯ функция: её же зовут кнопка (`pop_button_redraw`),
   зеркало, подобранный предмет и щебень на месте посадки.  Там меняется сам
   тайл и 60 нужны целиком.  Значит нужен отдельный вход (напр.
   `pop_floor_bake_edge(row, col)`) или параметр-прямоугольник — именно под
   пометку «изменился мой левый сосед».
2. Прежде чем выкидывать вторую пометку целиком, сверить ВЕРТИКАЛЬНЫЕ
   диапазоны: `pop_loose_bake_empty` кроет `63*row+46 .. +65` (20 строк), а
   `pop_floor_bake` — `yb+26 .. yb+64` (39 строк).  То есть сосед покрыт
   ВТОРЫМ баром не полностью, и просто снять пометку нельзя.
3. Ширина полосы = свес ЛЕВОГО тайла, а он зависит от типа тайла (у loose это
   8 px по комментарию в `pop_loose_bake_empty`, у пола 26).  Брать по
   максимуму (28) — безопасно.

### G9. Снять временную оснастку

Шесть `pop_dbg_b1..b6` внутри `pop_blit_b` — ~400 такта на блит; при 15
блитах зелёной это 6 000 на кадр.  Плюс `pop_dbg_kind`/`m16` (2 вызова на
перерисовку) и `pop_dbg_m5..m15`.  Снимать ПОСЛЕ окончания оптимизации: без
них не мерить.

---

## 4. Копия второй страницы — и почему она ТРЕБУЕТ окна клипа

Точечные запечки ставятся с `pages = 2`, срабатывают два кадра подряд (по разу
на страницу дабл-буфера) и оба раза считают одно и то же.  После первого раза
нужный прямоугольник уже лежит в ОЗУ-копии первой страницы, и его можно
скопировать: `gfx_copy_page` берёт источником ОЗУ-копию НЕактивной страницы
(то есть ЧИСТЫЙ фон — спрайты рисуются банком без тени и в копию не попадают),
а приёмник обновляет и в видео-ОЗУ, и в ОЗУ-копии.  Идея пользователя: тот же
приём, что при перевороте экрана (зелёное зелье), только без зеркала.

| | полная запечка | копия |
|---|---:|---:|
| щебень / кнопка (60×39) | 179 914 | ~35 000 |
| колодец полосы потолка (64×9) | 138 318 | ~17 500 |

**ДВА УСЛОВИЯ КОРРЕКТНОСТИ.**  Оба нарушались и оба дали видимые баги.

1. **Запечка обязана быть ОГРАНИЧЕНА копируемым прямоугольником.**
   `draw_tile` рисует тайлы ЦЕЛИКОМ, то есть пишет ШИРЕ бара; копия переносит
   ровно бар, и всё, что легло вне него, на второй странице остаётся прежним —
   страницы расходятся, это видно как МЕРЦАНИЕ через кадр.  У полосы потолка
   окно стояло с самого начала (G1), у `pop_floor_bake` — нет, и он мерцал
   торцами полов, плит и кнопок (найдено пользователем 2026-08-17: уровень 1,
   комната 6, Кид на кнопке (0,2)).  Поэтому в `pop_floor_bake` окно теперь
   стоит КАК УСЛОВИЕ КОРРЕКТНОСТИ, хотя по скорости само по себе убыточно
   (см. §5) — снимать его нельзя.
2. **Копия годится только если содержимое тайла между двумя кадрами не
   изменилось.**  У анимированного тайла (кнопка с идущим таймером связи)
   пометка обновляется КАЖДЫЙ кадр и картинка каждый раз другая.  Поэтому
   `pop_set_redraw`/`pop_set_redraw_above` гасят слот копии при ПЕРЕпометке
   (`pop_bake_slot_reset*`).

Плюс слот `bake_pg`/`bake_pg_above` помнит, НА КАКОЙ странице сделана первая
запечка: копируем только если первая была на ДРУГОЙ странице и дабл-буфер
включён.  Это покрывает переплетение двух запечек в одном кадре, однобуфер
(чит SPACE) и смену комнаты (`pop_bake_forget`).

---

## 5. Отрицательные результаты — НЕ повторять

### Окно клипа в `pop_floor_bake` — по СКОРОСТИ проверено ТРИ раза, каждый раз хуже

**Но оно всё равно стоит на месте: без него ломается копия второй страницы
(§4).**  Ниже — только про скорость самого окна.

| попытка | было | стало |
|---|---:|---:|
| до G3 | 187 266 | 198 279 |
| после G3 | 182 124 | 188 460 |
| после `pop_blit_b` file-scope, с детальным зондом | 179 914 | 188 417 |

Третья попытка объяснила причину: клипованный путь стоит **+1 500 такта на
КАЖДОМ** из 7,6 блитов (+11 400), а режет он только редкие высокие куски — в
трассе такие нашлись (34 878 → 25 872 и 28 818 → 24 090, всего −13 700), но в
среднем по 12 перерисовкам их нет.  Запись стоит в коде.

### Прочее (проверено раньше)

- **Не откладывать запекание на другой кадр** — запечка пишет ОЗУ-копию, из
  которой восстанавливает heal; отложенная даёт призрак плиты на месте дыры.
- **Не батчить смежные колонки в `pop_ceil_shake_draw`** — плиты стартуют со
  случайными задержками, в кадре дрожат разрозненные колонки, пробег почти
  всегда длиной в одну.
- **Не ускорять передачу пикселей** — предел железа (3+3 такта на байт,
  memory `blit_cost_model`).  В пиковом кадре «железный» минимум всех блитов
  ≈150 000 из 916 458.
- **`LOOSE-SHAKE-RUNS`** (пометки по сменам кадра): наивный вариант выигрыша
  НЕ даёт — пять смен × две страницы = те же десять перерисовок.  Работает
  только версия «пары и тройки», ~20 % и только на дрожащих плитах; оценка
  2026-08-13, не перемерена.  Подробности —
  `TASKS_OPEN.md#loose-shake-runs`.

---

## 6. Журнал правок

| дата | что сделано | зелёная: покой / дрожь / пик | коммит |
|---|---|---|---|
| 2026-08-17 | базовый замер | 35 760 / 366 000 / **805 000** | `c312e4a` |
| 2026-08-17 | G2 контекст тайла в file-scope | — / — / **747 954** | `a3c473d` |
| 2026-08-17 | G1 окно клипа в `pop_ceil_bake_empty` | — / — / **663 250** | `a3c473d` |
| 2026-08-17 | G3 `blit_b_clip` байты + file-scope | — / 335 400 / **575 730** | `a3c473d` |
| 2026-08-17 | `pop_blit_b` file-scope; пакетная пометка кусков | — / — / **557 706** | `b2da0b8` |
| 2026-08-17 | коридор heal по высоте композита | 35 760 / 335 400 / **546 900** | `9a50ab2` |
| 2026-08-17 | **копия второй страницы вместо второй запечки** | — / — / **423 558** | `5ef721e` |
| 2026-08-17 | `mob_tick_one` в file-scope; снята оснастка из горячих путей | 35 760 / 326 130 / **414 456** | `18ee60e` |
| 2026-08-17 | фикс мерцания: окно клипа в `pop_floor_bake` как условие корректности копии | замер после фикса — ниже | `35b7cd5` |
| 2026-08-17 | замер после фиксов уровня 1 (мерцание торцов, потолочный fore, сосед под плитой, блеск меча) | 35 760 / — / **417 630** | `40f0d46` |
| 2026-08-17 | **регресс после фиксов уровня 2** (чёрные бары, чит бессмертия) — в пределах шума | — / — / **419 526** | `ec1f384` |