Реестр: P18 — метка огрублена по X (отложено)

Пользователь заметил: Кид перерисовывается, хотя с пламенем не
пересекается; на пиксель левее — перестаёт.

Разбор: спрайт Кида занимает x 213..224, колонка считается как x >> 5,
и 224 — ровно первый пиксель колонки 7, где лежит метка от пламени
(y 33..50).  По вертикали пересечение настоящее, по горизонтали его нет:
пламя в той же колонке занимает x 232..247, зазор восемь пикселей.

То есть P15 исправил огрубление по Y и оставил его по X.

Отложено по решению пользователя с его же аргументами: x не влезает в
байт (0..319), значит нужны 16-битные сравнения в горячем пути, а они у
SDCC z80 дороги настолько, что могут съесть выигрыш; огрубление вдвое —
лишний сдвиг при записи и проверке плюс потеря точности.

Записана непроверенная идея: хранить границы как смещение ВНУТРИ колонки
(0..31, пять бит) — байта хватит и сравнение 8-битное, но запись
усложняется для прямоугольников через несколько колонок.

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

applications/PoP/docs/perf_registry.md

@@ -352,6 +352,42 @@ SDCC z80 разворачивается в `sbc` плюс `jp PO / xor 0x80 / jp
 `pop_sprite_size_limits`).  **−276 в статике, −1 134 в циане динамики**,
 плюс 24 байта `_DATA`.
 
+### P18. Метка «фон трогали» огрублена по X — ОТЛОЖЕНО (решение пользователя)
+
+**Найдено 2026-08-19 пользователем:** Кид перерисовывается, хотя с пламенем
+не пересекается; на пиксель левее — перестаёт.
+
+Разбор по памяти машины.  Кид `x = 156`, спрайт занимает **x 213..224**,
+экранные y 43..83.  Метка колонки 7 — y 33..50 (пламя правого факела).
+Колонка считается как `x >> 5`, то есть по 32 пикселя, и спрайт достаёт до
+224 — ровно первый пиксель колонки 7.  По вертикали пересечение с меткой
+настоящее (43..50), поэтому слот считается задетым.
+
+А по горизонтали пересечения НЕТ: пламя лежит в колонке 7 на x 232..247,
+между ним и Кидом восемь пикселей зазора.  На пиксель левее спрайт
+кончается на 223, `223 >> 5 = 6`, колонка 7 не задета — и перерисовка
+пропадает.
+
+То есть P15 исправил огрубление по Y и оставил его по X.
+
+**Почему отложено (аргументы пользователя):**
+
+- x лежит в 0..319 и в байт не влезает — нужен `uint16_t` на границу, то
+  есть 4 байта на колонку (80 байт на две страницы), и **16-битные
+  сравнения в горячем пути**.  А они у SDCC z80 дороги ровно настолько,
+  что могут съесть весь выигрыш (см. отрицательные результаты выше);
+- огрубить x вдвое (`x >> 1`, диапазон 0..159 влезает в байт) — это лишний
+  сдвиг и при записи, и при проверке, плюс точность падает до 2 пикселей.
+
+**Непроверенная идея на будущее:** хранить границы НЕ в экранных x, а как
+смещение ВНУТРИ колонки (0..31, пять бит).  Тогда байта хватает и сравнение
+8-битное, но запись усложняется: прямоугольник, пересекающий несколько
+колонок, даёт частичные диапазоны у крайних и полные у средних.
+
+**Когда браться:** если после других позиций бюджет всё ещё не сойдётся.
+Выигрыш будет именно в пограничных положениях, а их в игре много —
+персонаж почти всегда стоит рядом с чем-то анимированным.
+
 ### P4. Накладные блита — ОТКАЧЕНО
 
 **Правка сделана и отменена по решению пользователя.**  Критерий: если