From 52a36caa75b0dbd7eb69cde496d82d1fa6ace09e Mon Sep 17 00:00:00 2001 From: Alexander Petrov Date: Wed, 19 Aug 2026 18:07:36 +0300 Subject: [PATCH] =?UTF-8?q?=D0=A0=D0=B5=D0=B5=D1=81=D1=82=D1=80:=20P18=20?= =?UTF-8?q?=E2=80=94=20=D0=BC=D0=B5=D1=82=D0=BA=D0=B0=20=D0=BE=D0=B3=D1=80?= =?UTF-8?q?=D1=83=D0=B1=D0=BB=D0=B5=D0=BD=D0=B0=20=D0=BF=D0=BE=20X=20(?= =?UTF-8?q?=D0=BE=D1=82=D0=BB=D0=BE=D0=B6=D0=B5=D0=BD=D0=BE)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Пользователь заметил: Кид перерисовывается, хотя с пламенем не пересекается; на пиксель левее — перестаёт. Разбор: спрайт Кида занимает 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 --- applications/PoP/docs/perf_registry.md | 36 ++++++++++++++++++++++++++ 1 file changed, 36 insertions(+) diff --git a/applications/PoP/docs/perf_registry.md b/applications/PoP/docs/perf_registry.md index 5d9d79c..99b7cb4 100644 --- a/applications/PoP/docs/perf_registry.md +++ b/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. Накладные блита — ОТКАЧЕНО **Правка сделана и отменена по решению пользователя.** Критерий: если