From b6b214e225edf491aae2c9fcdd2e7b73af1ae916 Mon Sep 17 00:00:00 2001 From: Alexander Petrov Date: Wed, 19 Aug 2026 18:27:18 +0300 Subject: [PATCH] =?UTF-8?q?=D0=A0=D0=B5=D0=B5=D1=81=D1=82=D1=80:=20HEAL-WI?= =?UTF-8?q?DTH=20=D0=B7=D0=B0=D0=BA=D1=80=D1=8B=D1=82,=20P10=20=D1=80?= =?UTF-8?q?=D0=B0=D0=B7=D0=BE=D0=B1=D1=80=D0=B0=D0=BD=20=D0=B1=D0=B5=D0=B7?= =?UTF-8?q?=20=D1=80=D0=B5=D0=B0=D0=BB=D0=B8=D0=B7=D0=B0=D1=86=D0=B8=D0=B8?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit HEAL-WIDTH: плита 64->58, чомпер 64->61, габариты из каталогов атласов. На 11/15 медиана не сдвинулась (плит нет), максимум -960. Основной эффект ждёт прогона 13/23, где плит шесть одновременно. P10 разобран: «просто передать готовое из физики» не выйдет, величины РАЗНЫЕ. char_footprint берёт габарит кадра и расширяет диапазон на колонку под меч; set_char_collision тот же fpw корректирует на FRAME_THIN и меч не учитывает, а ряды у него — опорный curr_row, а не верх/низ спрайта. У оригинала обе задачи пользуются одними величинами, потому что он считает их один раз; у нас они исторически разошлись. Значит P10 — это сведение двух геометрий к одной, с риском для физики, которая сейчас работает правильно. Приоритет понижен до низкого, и записано, чего не хватает: отдельного замера самого char_footprint (сейчас известно лишь «вход + set_clip + footprint = 10 872»). Co-Authored-By: Claude Opus 5 --- applications/PoP/docs/perf_registry.md | 43 ++++++++++++++++++++++++-- 1 file changed, 41 insertions(+), 2 deletions(-) diff --git a/applications/PoP/docs/perf_registry.md b/applications/PoP/docs/perf_registry.md index 925c4c9..a0eb6b0 100644 --- a/applications/PoP/docs/perf_registry.md +++ b/applications/PoP/docs/perf_registry.md @@ -376,6 +376,44 @@ SDCC z80 разворачивается в `sbc` плюс `jp PO / xor 0x80 / jp ожидаемый выигрыш тут тоже стоит считать скромным, а риск он несёт несоразмерный. +### P10. Футпринт из физики — РАЗБОР 2026-08-19 (без реализации) + +Идея из `perf_backlog.md` §1: `redraw_at_char` (seg003:0430) берёт ГОТОВЫЕ +`char_col_left/right`, `char_top_row`, `char_bottom_row`, посчитанные в том +же кадре физикой (`set_char_collision`, seg006:0723), а наш +`char_footprint` (pop_bg.c) считает их заново внутри fore-прохода. + +**Разбор показал, что «просто передать» не получится: величины разные.** + +| | `char_footprint` (банк 2, fore) | `set_char_collision` (банк 3, физика) | +|---|---|---| +| ширина | габарит КАДРА `w` из атласа, `wh = (w+1)/2` | то же `fpw`, но затем **`FRAME_THIN` сдвигает края на ±4** | +| меч | расширяет диапазон на колонку (`sword >= DRAWN`) | не расширяет | +| колонки | `cLraw` до клампа (нужен для шва), затем кламп 0..9 | `coll_xl`/`coll_xr` в пикселях, колонки считает уже `calc_coll_window` | +| ряды | `rT`/`rB` от ВЕРХА и НИЗА спрайта, с форсом `rT = rB-1` | `Char.curr_row` — опорный ряд, это другое | + +То есть у оригинала обе задачи пользуются ОДНИМИ величинами, потому что он +считает их один раз в `set_char_collision`. У нас они исторически +разошлись: коллизии считают своё окно (с поправкой `FRAME_THIN`), fore — +своё (габарит кадра плюс колонка под меч). + +**Значит P10 — это не «передать готовое», а сперва СВЕСТИ обе величины к +одной, как в оригинале.** Работа не механическая: `FRAME_THIN` влияет на +коллизии осознанно (узкие кадры не должны цеплять стену), а fore-проходу +нужен полный габарит, иначе передние грани в крайней колонке не +перерисуются. + +**Чего не хватает для решения:** отдельного замера самого +`char_footprint`. Сейчас известно только «вход + `pop_fore_set_clip` + +`char_footprint` = 10 872», а оценка −11 574 в backlog взята из старого +замера другой сборки. Первым шагом нужен зонд между `set_clip` и +`char_footprint`. + +**Оценка приоритета:** низкая. Даже если `char_footprint` окажется всеми +10 872, он платится только когда персонаж рисуется (в статике fore-прохода +нет), а сведение двух геометрий к одной — это риск для коллизий, то есть +для физики, которая сейчас работает правильно. + ### P18. Метка «фон трогали» огрублена по X — ОТЛОЖЕНО (решение пользователя) **Найдено 2026-08-19 пользователем:** Кид перерисовывается, хотя с пламенем @@ -628,10 +666,11 @@ BUG-LATTICE-DOORTOP, BUG-SEAM-WEDGE-1) — только отдельным за | P4 | накладные блита — 6 663 на КАЖДЫЙ блит | частично сделано: **−408** | низкий | из четырёх правок сработала слабо; разбор ниже | | P14 | fore-проход персонажа | сводится к P4 + P10 | — | разбор ниже: цикл обходит всего 4 тайла | | P11 | мелочи с известной ценой | −26 000 | низкий | `clip_char_top` 8 658 подтверждён замером | -| P10 | футпринт персонажа из физики | −23 000 | средний | часть P14 | +| P10 | футпринт персонажа из физики | ? (нужен замер) | **высокий** | разбор ниже: величины физики и fore РАЗНЫЕ | | P6a/P6b | `trob_modif` из цикла, кэш префетча | −20 000 | низкий | тот же паттерн трамплина в цикле | | P7 | раскол `draw_tile` (G5) | −50 000 в 13/23 | средний | в 11/15 не играет | -| P8/P9 | HEAL-WIDTH + G8 | 5-6 % цены heal'ов | низкий/средний | **обязательная** по решению пользователя; для сцен с плитами | +| ~~P8~~ | HEAL-WIDTH | ✅ сделано: плита 64→58, чомпер 64→61 | — | эффект ждёт прогона 13/23 | +| P9 | G8 — пометка соседа полосой | не оценено | средний | для сцен с плитами | | P13 | objtable + отложенные таблицы, единый проход по тайлам | не оценено | очень высокий | большой рефакторинг слоя фона | | P12 | снять оснастку | −6 000 | нулевой | **последней**: без неё не мерить |