Sprinter-SDCC/applications/SprPoP/docs/ideas_backlog.md

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

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

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

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

Факт 1 — когда оно вообще нужно. Зелье переворота — тип 4 (proc_get_object, seg006.c:1885 → toggle_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).

Готовить следующий уровень, пока играет мелодия конца текущего

САМАЯ ДАЛЬНЯЯ ВЕРСИЯ. Не полишинг и не порт: это улучшение ПРОТИВ оригинала. Планируем, но не раньше, чем закроем уровни и полишинг.

Идея (пользователь, 2026-08-28). Пока звучит мелодия конца уровня (и трек заставки между уровнями), экран не меняется — значит в это время можно успеть прочитать с диска следующий уровень, чтобы после музыки он появлялся сразу, а не через секунду-другую загрузки.

Что УЖЕ сделано и мерено (2026-08-28). Половина этого уже работает: трек заставки играет ПОВЕРХ загрузки уровня — так же, как в оригинале (seg003:68-108: load_intro возвращает управление, load_level() идёт под музыку, и только потом while (check_sound_playing()) на чёрном экране). Насос это переживает: 500 подряд вызовов pop_sfx_fill через всю загрузку — максимальный зазор 245 832 такта при дедлайне 251 000, ни одной пропущенной порции. Осталась вторая половина: мелодия конца уровня досиживается на ЖИВОМ экране пройденного уровня (как в оригинале, play_level_2), и только после неё начинается загрузка.

Оговорки, найденные при разборе.

1. Загрузку придётся разрезать надвое. Сейчас pop_level_switch мешает дисковую работу (файл уровня в EMM-страницу, атласы стража и тайлсета) с экранно-палитровой (pop_bg_load переписывает записи палитры и атласы, pop_guard_load физически применяет цветовые слоты, обе страницы заливаются, pop_pal_black). Вторую половину НЕЛЬЗЯ выполнять, пока на экране ещё живёт пройденный уровень — иначе палитра поедет прямо на картинке. То есть в «музыкальное окно» можно вынести только диск, а всё, что трогает палитру и VRAM, остаётся после.
2. Бюджет кадра. Ожидание мелодии идёт в игровом цикле (гейт pop_endmus_left + pop_music_busy()), кадр там обычный, 80-100 мс. Шаг подкачки должен быть такого же размера, как музыкальный — полстраницы (~16 мс), а не страница целиком; иначе кадры на экране пройденного уровня начнут дёргаться.
3. Память. Страницы следующего уровня придётся держать одновременно со страницами текущего — проверить EMM-бюджет (memory sprinter_emm_budget), тяжёлые тут не файл уровня, а атласы тайлсета и стража.
4. Риск невелик, но он в самом хрупком месте. Палитро-атласный обмен — источник уже пойманных багов (PAL-DUNGEON-STALE, PAL-L1-AFTER-INTRO), и трогать его ради экономии секунды стоит только на спокойную голову.

Выигрыш. Одна-две секунды один раз на уровень.

Музыка одним постоянно открытым архивом (замер 2026-08-31, НЕ сейчас)

Идея. Сейчас каждый трек — отдельный файл MUS/mNN.bin, и pop_music_load_begin открывает свой на каждый запуск. Свести треки в один файл и держать его fd открытым: вместо chdir+open+chdir останется lseek к смещению трека.

Почему это стоит внимания — разложение окна старта музыки (полный замер и метод — sound_plan.md §9):

шаг	цена	уйдёт?
ожидание pop_music_service в кадре	22,6 мс	нет
chdir #1	46,1 мс	да
open файла трека	34,5 мс	да
chdir #2	59,0 мс	да
чтение первых 8 КБ	34,0 мс	нет
итого	196,7 мс

Уходит 139,6 мс — но это ВЕРХНЯЯ граница: появляется lseek к смещению трека, которого сейчас нет вовсе (файл читается последовательно с нуля), и его цена НЕ ИЗМЕРЕНА. Реальный выигрыш = 139,6 минус lseek; померить можно тем же способом, lseek уже используется в pop_arc.c:89. Остаётся ≈ 57 мс, то есть старт трека ускоряется примерно вчетверо.

Где заметно. Реплики PV-сцены идут встык (три трека подряд), плюс каждый игровой джингл — смерть, зелье, подобранный меч.

Чем осложнено.

1. PBA1 под это не годится. Размер элемента там uint16 (≤ 64 КБ), а трек — до 1,2 МБ (m56, 78 страниц); резать по страницам нельзя, элементов вышло бы ~240 при POP_ARC_MAX = 126. Нужен свой индекс со смещениями — то есть эта задача СМЫКАЕТСЯ с MUS/MUSIC.IDX из music_runtime_index_plan.md: одно изменение раскладки, а не два.
2. Постоянно занятый файловый манипулятор — один из восьми (memory dss_fd_limit, девятый open вешает DSS). Рядом свои открывают POP.CFG, quicksave и загрузка уровня.
3. chdir убрать нельзя — он и есть половина выигрыша, но нужен старым DSS (POP_PATH_CALL); экономия берётся не его удалением, а тем, что открытие вообще перестаёт выполняться на каждый трек.

Оговорка. Задержка старта музыки сама по себе НЕ является дефектом: трек начинается на границе события, на слух это не сбой. У эффектов такой задержки нет вовсе — они целиком в EMM (см. sound_plan.md §9.1). Так что это оптимизация, а не исправление.