Коридор heal падающего куска — по высоте композита (-12 тыс. на кадр)

Держали константные 24 строки «на всякий случай», хотя собранный композит
знает свою высоту: у дворца 16 строк, у подземелья 19.  Теперь коридор =
высота композита + две строки сверху и одна снизу (mob_heal_up/mob_heal_h
ставит mob_spr_build).  На самой дорогой операции кадра, помноженной на шесть
падающих плит:

  pop_loose_mob_tick   168 600 -> 156 762
  зелёная пик          557 706 -> 546 948
  работа пик           931 782 -> 920 862

Плюс ТРЕТЬЯ проверка окна клипа в pop_floor_bake — снова хуже (179 914 ->
188 417), и теперь ясно ПОЧЕМУ: детальный зонд по каждому блиту показал, что
клипованный путь стоит +1 500 такта на КАЖДОМ из 7,6 блитов (+11 400), а
режет он только редкие высокие куски (в трассе нашлись два: 34 878 -> 25 872
и 28 818 -> 24 090, всего -13 700), которых в среднем по 12 перерисовкам нет.
Запись в коде: больше не пробовать.

Заодно снят детальный профиль pop_floor_bake (одна перерисовка, 179 914):
  вход                                   2 382
  pop_bar_black 60x39 (вкл. pop_cd_touch) ~15 500
  контекст draw_tile #1                  13 584
  4 блита тайла #1                       50 718
  диспетчер между блитами #1             11 388
  контекст draw_tile #2                  13 584
  4 блита тайла #2                       ~54 000
  диспетчер между блитами #2             11 388
  хвост                                   6 474

Итог по сцене от базового замера:
  работа   1 437 150 -> 920 862  (-36%)
  зелёная    805 000 -> 546 948  (-32%)
  циан       631 800 -> 273 108  (-57%, в бюджете)

Проверено: 8 наборов tests-host зелёные; в MAME кадр с четырьмя плитами в
воздухе чистый (коридор сузился — следов нет), итоговая картинка прежняя.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

applications/PoP/roomtest/pop_room.c

@@ -103,6 +103,14 @@ static int bg_load_tile_pal(const char *name)
  * используется (malloc'ов в приложении нет), так что это её и не задевает.
  *
  * Собирается на КАЖДУЮ смену тайлсета: размеры частей у наборов разные. */
+/* Коридор heal падающего куска — по фактической высоте СОБРАННОГО композита
+ * (у дворца он 16 строк, у подземелья 19).  Держать константные 24 «на всякий
+ * случай» значило платить лишними строками на самой дорогой операции кадра,
+ * помноженными на число падающих плит.  Ставит mob_spr_build; стартовые
+ * значения — безопасный максимум (см. MOB_HEAL_UP/MOB_HEAL_H ниже). */
+static uint8_t mob_heal_up = 20;
+static uint8_t mob_heal_h  = 24;
+
 #define MOBS_MAXW 63
 #define MOBS_MAXH 19
 static uint8_t mob_spr[4 + MOBS_MAXW * MOBS_MAXH];
@@ -175,6 +183,9 @@ static void mob_spr_build(void)
     if (!mob_spr_put(74, 0,   0, top_off)) return;
     if (!mob_spr_put(70, 0,  -3, top_off)) return;
     if (!mob_spr_put(72, 32, -1, top_off)) return;
+    /* Коридор heal — по композиту: две строки запаса сверху, одна снизу. */
+    mob_heal_up = (uint8_t)(mob_spr[2] + 1);
+    mob_heal_h  = (uint8_t)(mob_spr[2] + 3);
     mob_spr_ok = 1;
 }
 
@@ -874,7 +885,14 @@ void pop_floor_bake(int row, int col) __banked
      * Причина: у этого тайла клипа нет, блиты идут БЫСТРЫМ путём
      * (gfx_blit_noclip), окно уводит их в blit_b_clip и при этом НЕ отсеивает
      * ни одного куска и НЕ режет ни одной строки — все куски щебня и так
-     * лежат внутри бара yb+26..yb+64.  Не пробовать в третий раз. */
+     * лежат внутри бара yb+26..yb+64.
+     *
+     * ТРЕТЬЯ попытка (уже с детальным зондом по каждому блиту) — тоже хуже,
+     * 179 914 -> 188 417.  Разложение показало, ПОЧЕМУ: клипованный путь
+     * стоит +1 500 такта на КАЖДОМ из 7,6 блитов (+11 400), а режет он
+     * только редкие высокие куски — в трассе такие нашлись (34 878 -> 25 872
+     * и 28 818 -> 24 090, всего -13 700), но в среднем по 12 перерисовкам их
+     * нет.  БОЛЬШЕ НЕ ПРОБОВАТЬ. */
     pop_t_bake_rest = 1;                             /* фон = покой (см. pop_t_bake_rest) */
     draw_tile(row, col);
     if (col + 1 < 10) draw_tile(row, col + 1);
@@ -1047,8 +1065,8 @@ static const int16_t MOB_Y_BOUND[5] = {-1, 62, 125, 188, 25};
  * Уже НЕ сужать: 24 строки — это след подземелья (19) плюс две строки поля с
  * каждой стороны.  Сужение до 18 «по палаццовому следу» сломало бы
  * подземелье. */
-#define MOB_HEAL_UP 20                /* верх коридора = mob_y − 20 */
-#define MOB_HEAL_H  24                /* .. mob_y + 3 */
+/* Сами величины коридора — в mob_heal_up / mob_heal_h у начала файла: они
+ * считаются из высоты собранного композита, а не константами. */
 
 /* Свободный слот = не летит И дочистка завершена (иначе затрём хвост,
  * который ещё не стёрт со второй страницы).  Общий для обычного отрыва и
@@ -1223,7 +1241,7 @@ static void mob_tick_one(mob_t *m, uint8_t pg)
          * ЗАДЕЛ: правильнее не перерисовывать соседа вовсе, а КЛИПОВАТЬ
          * правую часть куска — оригинал так и делает (add_mob_to_objtable,
          * seg007:1161: clip.right = 40).  Тогда коридор вернётся к 64x32.  */
-        pop_heal_off(MOB_X0(m->x), m->prev_y[pg] - MOB_HEAL_UP, MOB_W, MOB_HEAL_H);
+        pop_heal_off(MOB_X0(m->x), m->prev_y[pg] - mob_heal_up, MOB_W, mob_heal_h);
         m->prev_y[pg] = MOB_Y_NONE;
     }
     if (!m->active) { m->clean--; return; }