From 9a50ab20d7e1a87f169dbd72ac9827b475c833f2 Mon Sep 17 00:00:00 2001 From: Alexander Petrov Date: Mon, 17 Aug 2026 14:14:12 +0300 Subject: [PATCH] =?UTF-8?q?=D0=9A=D0=BE=D1=80=D0=B8=D0=B4=D0=BE=D1=80=20he?= =?UTF-8?q?al=20=D0=BF=D0=B0=D0=B4=D0=B0=D1=8E=D1=89=D0=B5=D0=B3=D0=BE=20?= =?UTF-8?q?=D0=BA=D1=83=D1=81=D0=BA=D0=B0=20=E2=80=94=20=D0=BF=D0=BE=20?= =?UTF-8?q?=D0=B2=D1=8B=D1=81=D0=BE=D1=82=D0=B5=20=D0=BA=D0=BE=D0=BC=D0=BF?= =?UTF-8?q?=D0=BE=D0=B7=D0=B8=D1=82=D0=B0=20(-12=20=D1=82=D1=8B=D1=81.=20?= =?UTF-8?q?=D0=BD=D0=B0=20=D0=BA=D0=B0=D0=B4=D1=80)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Держали константные 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 --- applications/PoP/roomtest/pop_room.c | 26 ++++++++++++++++++++++---- 1 file changed, 22 insertions(+), 4 deletions(-) diff --git a/applications/PoP/roomtest/pop_room.c b/applications/PoP/roomtest/pop_room.c index cbb437e..aac89f6 100644 --- a/applications/PoP/roomtest/pop_room.c +++ b/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; }