Files
Sprinter-SDCC/applications/SprPoP/docs/ideas_backlog.md
T
snark13 31b82661eb 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>
2026-08-27 12:12:28 +03:00

8.0 KiB
Raw Blame History

Идеи и вопросы «на подумать» (PoP)

Не план работ, а список того, что осознанно отложено: каждая запись — гипотеза с причиной, по которой её стоит проверить, и с тем, что мешает сделать это прямо сейчас.

Зелье «переворот экрана» (upside-down)

Вопрос пользователя (2026-08-01). Тайлы фона у нас лежат строками, а кадры Кида/стражей — КОЛОНКАМИ (transpose_cols в pop_pack_kid.py, ради бесплатного горизонтального зеркала). Значит вертикальный переворот для персонажей заметно сложнее, чем для фона. Верно; но прежде чем это чинить, надо знать три факта.

Факт 1 — когда оно вообще нужно. Зелье переворота — тип 4 (proc_get_object, seg006.c:1885toggle_upside()). Скан всех уровней по данным (res200N.bin, тайл 10 = зелье, тип в backtable): тип 4 встречается впервые на уровне 9 (две склянки), и больше нигде. Тип 3 (перо, медленное падение) — уровень 7. То есть до уровня 9 механика не нужна вообще, и «на первом этапе просто не реализовывать» — не компромисс, а точное соответствие данным уровней 1..8.

Факт 2 — что именно делает оригинал. НЕ переворачивает спрайты. flip_screen (seg009.c:1042) → flip_not_ega (seg009.c:1023) меняет местами СТРОКИ готового offscreen-буфера (top↔bottom, порядок пикселей внутри строки не трогает — это вертикальное зеркало, не поворот на 180°). Вызывается вокруг отрисовки кадра целиком (seg003.c:296..301): перевернул буфер → дорисовал → перевернул обратно. Так что в оригинале это post-process всего экрана, и вопрос «как перевернуть колоночный спрайт» там просто не возникает.

Факт 3 — почему нам этот приём не подходит как есть. У нас нет шага «готовый offscreen → экран»: рисуем прямо в видеостраницу, а heal берёт фон из ОЗУ-копии этой же страницы. Переворот всей страницы построчно — это 320×192 Б копирования КАЖДЫЙ кадр, что мимо бюджета на порядок.

Варианты, которые надо будет взвесить (не сейчас):

  1. Предпечённые перевёрнутые атласы. Второй набор кадров Кида/стража, перевёрнутый по вертикали ещё в pop_pack_kid.py (там уже есть транспонирование — добавляется одной строкой). Рантайм: выбор набора + зеркальная арифметика Y. Память: ещё ~28 страниц EMM при бюджете ~3.3 МБ — не проблема. Похоже, самый дешёвый по тактам путь.
  2. Фон рисовать с обратным Y — для row-major тайлов строка остаётся непрерывным accel-прогоном, меняется только адрес назначения; цена — вызов на строку вместо вызова на тайл. Померить, прежде чем закладывать.
  3. Аппаратная помощь — до проектирования проверить, есть ли у акселератора направление копирования «вниз» (обратный инкремент адреса); если есть, вариант 1 может и не понадобиться. Смотреть docs/new/06-accel.md и docs/reference/accel_r.txt.

Почему не сейчас. Уровни 1..8 этого не требуют, а к уровню 9 у нас уже будет ответ на вопрос «сколько стоит кадр» (задачи CLIP-1/T-2) — без него выбирать между вариантами выше бессмысленно.

Заменить генератор псевдослучайных чисел

Сейчас стоит LCG оригинала, шаг на ассемблере (~1 020 тактов), бит-в-бит совместимый с SDLPoP. Есть более дешёвые Z80-генераторы (86–148 тактов), но потолок выигрыша — 2 814 тактов за кадр, 0.65 %, и он растворяется в обёртках вызова. Тексты процедур, разбор качества и порядок действий — prng_alternatives.md. Первый шаг там не про генератор: слить приведение к диапазону в ту же asm-процедуру, чтобы на вызов был один call, а не три.

Отключать мышь на время игры

Гипотеза. Мышь на Sprinter — источник прерываний (обёртки RST 30h, см. memory mouse_api). Игре она не нужна вообще: управление — raw-клавиатура (<kbd_raw.h>), которую мы и так забираем у DSS целиком. Значит каждое мышиное прерывание за кадр — украденные такты в бюджете, который у нас и без того занят на 86 %.

Откуда взялось (2026-07-30). При замере бюджета по 100 кадрам три кадра выбились до 552–647 К тактов (1.28–1.51 кадра) при типичных 371 К. Причиной оказалось движение мыши на ХОСТЕ: при неподвижной мыши 225 кадров подряд прошли без единого превышения. То есть эффект реальный и измеримый, просто в тесте он был наведён извне.

Что проверить.

  1. Есть ли у драйвера мыши (RST 30h) функция «выключить/включить» — разобрать список из 14 обёрток; если нет явной, посмотреть, что делает «hide cursor» и снимает ли она обработчик.
  2. Сколько тактов реально стоит одно мышиное прерывание на нашем железе (замер: breakpoint на входе ISR + totalcycles, при движении мыши).
  3. Не ломает ли отключение выход в DSS: состояние обязано восстанавливаться при exit, включая аварийный (atexit).

Почему не сейчас. Выигрыш проявляется только когда игрок реально двигает мышью, то есть в норме его нет; а риск оставить систему без мыши после выхода — заметный. Делать после того, как закроем стражей и займёмся бюджетом всерьёз (там же, где батчинг кроссбанковых вызовов и возможный возврат pop_bg в резидент --w3).