SprPoP: автономное приложение, выделенное из roomtest

Порт PoP переехал в applications/SprPoP — приложение, которое собирается
само: код, оригинальные данные, конверторы ресурсов и сборка внутри одной
папки.  Наружу знает единственный путь — корень тулчейна (SPRINTER_ROOT,
по умолчанию ../..).  applications/PoP/roomtest ЗАМОРОЖЕНА и остаётся
архивом закрытых задач, багов и исполненных планов.

Скопировано из applications/PoP/roomtest@4b74478.  Перенос проверен
побайтово: собранный sprpop.exe совпал с roomtest.exe того же коммита,
все 39 дисковых ресурсов и все 16 генерируемых заголовков — тоже, host-
тесты зелёные (15/15).

Раскладка:
  src/           рукописный C (roomtest.c -> sprpop.c)
  gen/           генерируемые заголовки, в репозитории
  assets/orig/   оригинальные данные игры, вне репозитория (копирайт)
  assets/packed/ то, что ложится на диск, в раскладке диска
  tools/         конверторы; все пути — в одном tools/paths.py
  build/         выход: exe, каталоги ресурсов, hdd/, промежуточные atl/

Сборка ресурсов: assets/packed и gen — версионируемые ВХОДЫ, а не то, что
пересчитывается каждым make.  Автоматика построена на ОТСУТСТВИИ файла, а
не на таймстемпах: git не хранит времена, и в свежем клоне сравнение по
времени превращалось бы в лотерею.  Недостающий ресурс или заголовок
чинится сам, рекурсивным вызовом в ветку генерации.

Музыка собирается из любого из четырёх наборов записей (make music-mp3,
music-mt32, ...); набор входит в имя stamp'а, поэтому смена набора сама
делает музыку устаревшей.  Длины реплик больше не захардкожены: упаковщик
печатает их в gen/pop_music_ticks.h, и шкала сцены выражена через них —
иначе mt32 (реплики на 6% длиннее) молча ломал катсцену.

Тулчейн: в app.mk два обратносовместимых крючка (SRC_DIR/BUILD_DIR),
HDD_IMG стал ?=; команда сборки roomtest не изменилась.  Корневой
make host-tests переключён на SprPoP.

Подгонка тайминга катсцены с принцессой (PV_MAGIC_LEAD): сцена
render-bound и идёт ~49 тиков/с вместо 60, из-за чего кода реплики
приходила раньше молнии.  Это обход, а не лечение; разбор с замерами —
docs/BUGS_OPEN.md, записи SND-PACE-DEAD, PV-RENDER-BOUND, MUS-LEFT-TEAR.

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

applications/SprPoP/src/_pop_draw.h

@@ -0,0 +1,47 @@
+/*
+ * _pop_draw.h — внутренний заголовок слоя отрисовки: выбор ядра libbgi
+ * (клипающее / линейное «noclip») по одному и тому же тесту для блита и
+ * для heal.
+ *
+ * ПОЧЕМУ ОТДЕЛЬНЫЙ ФАЙЛ, А НЕ pop_bg.h.  Обе функции — `static inline`, а
+ * SDCC 4.5 оставляет тело такой функции в КАЖДОМ TU, который видит
+ * объявление, даже если тот её не зовёт (memory
+ * `sdcc_inline_codegen_findings`).  pop_bg.h включают почти все модули PoP,
+ * то есть из общего заголовка эти ~100 Б размножились бы десятком мёртвых
+ * копий (замер CLIP-1, 2026-08-01: +1091 Б в _CODE и +636 Б в банке
+ * стража — за код, который там никто не вызывает).  Здесь их видят ровно
+ * три файла, которые реально рисуют: pop_bg.c, pop_kid.c, pop_cdraw.c.
+ */
+#ifndef POP_DRAW_H
+#define POP_DRAW_H
+
+#include <stdint.h>
+#include <gfx.h>
+
+/* Спрайт целиком на экране И укладывается в 8-битные параметры noclip-
+ * примитивов libbgi?  Условие входа в gfx_blit_cols_part_noclip: клипающий
+ * вариант платит ~5.6 К тактов подготовки на КАЖДЫЙ вызов, независимо от
+ * того, вылезает край или нет. */
+static inline uint8_t pop_onscreen_cols(int x, int y, uint16_t w, uint16_t h)
+{
+    return (uint8_t)(x >= 0 && y >= 0 && w < 256 && h < 256 &&
+                     x + (int)w <= 320 && y + (int)h <= 256);
+}
+
+/* Стереть прямоугольник (heal из ОЗУ-копии) тем же приёмом, что и блит:
+ * целиком на экране → линейное ядро без клипа.  Условие входа у
+ * gfx_heal_noclip ровно то же, что у gfx_blit_cols_part_noclip, поэтому
+ * тест один — общее ядро gfx_heal платит за клип и 16-бит, а не за пиксели
+ * (замер: 11 658 тактов на heal 22×22).
+ *
+ * НЕ inline (тело — pop_draw.c, резидент W1): SDCC 4.5 встраивал бы его в
+ * каждое место вызова по 181 Б И оставлял мёртвую копию в каждом TU — см.
+ * шапку pop_draw.c с замером.  Зовётся 5 раз за кадр, цена вызова тонет в
+ * стоимости самого heal.
+ *
+ * w/h тут int, а не uint16_t: вызывающие считают их вычитанием (h − skip), и
+ * отрицательный результат обязан быть no-op, а не превратиться в огромный
+ * unsigned. */
+void pop_heal_fast(int x, int y, int w, int h);
+
+#endif