# roomtest — доска текущих задач (обновлено 2026-08-01) Не список багов (открытые — [`bug_list.md`](bug_list.md), закрытые с разбором корней — [`bug_closed.md`](bug_closed.md)) и не план фаз (`../docs/PORT_PLAN.md`, `../docs/layout_plan_v2.md`, `../docs/levels_plan.md`), а то, **что берём в работу сейчас и в каком порядке**. Каждая запись: что сделать, почему именно сейчас, чем подтверждать результат. **Открытых багов нет** ([`bug_list.md`](bug_list.md)): остались незакрытые оптимизации [T-1](bug_list.md#t-1), [T-2](bug_list.md#t-2) и незаконченная [таблица обхода 24 комнат](bug_list.md#обход-всех-24-комнат-уровня-1). Правило проекта в силе: механику сверять с `../SDLPoP/src/` ДО кодинга; диагноз платформы подтверждать артефактом (брейкпоинт/дамп/.asm), а не гипотезой (memory `defer_unexplained_quirks`). --- ## P0 — делаем сейчас *(KBD-1 закрыт до финальной полировки, CLIP-1 сделан — оба ниже. P0 пуст; следующая в работе — P1, начиная с L1-START/L1-EXIT.)* ### KBD-1. Shift + стрелки: нажатия теряются — **ПРИЧИНА НАЙДЕНА, ФИКС ПРОВЕРЕН** > **Итог (2026-08-01).** Причина — не наш код и не DI-окна графики: при > зажатом Shift PS/2 удваивает трафик («fake shift»), а импульс запроса > прерывания здесь теряется примерно в 44 % случаев, и трёхбайтовый FIFO > SIO переполняется. Лечится ПЛОТНЫМ опросом: `kbd_raw_poll` повешен > idle-хуком на ожидание кадра (`gfx_set_idle_hook`, новый API libbgi) — > процессор всё равно проводит там ~42 мс из 60, крутя опрос луча. > > **Проверка в roomtest тем же счётным методом: 35 нажатий Shift+Home → > 35 make, ноль потерь** (до фикса — 9 из 10). Боевой сценарий тоже: > четыре Shift+→ подряд дали четыре осторожных шага, `Kid.x` 114 → 147. > Цена: `_CODE` +170 Б, кадровый бюджет не затронут (опрос стоит в > простое). Ниже — полный протокол, как к этому пришли. > > **ОСТАТОК (ручная проверка пользователем, 2026-08-01): «стало значительно > лучше, но иногда при зажатом Shift стрелка всё-таки пропускается».** > Ощущение, не замер — счётчики на 35 нажатиях подряд потерь не показали, > значит остаточная частота заметно ниже прежних ~15 %. **Задача осознанно > ОТЛОЖЕНА до финальной полировки всей программы** (решение пользователя); > сейчас клавиатура пригодна для работы. > > **Где именно осталась дыра — чтобы на полировке не начинать с нуля.** > Idle-хук покрывает простой, то есть ~2/3 кадра. Оставшаяся треть — это > занятая фаза, и там DI-окно одного accel-прохода доходит до ~650 мкс при > допуске FIFO ~300 мкс. Пачка байт, целиком попавшая в такое окно, всё > ещё может потерять байт — ровно «иногда». Порядок действий, если > вернёмся: > 1. Вернуть вызовы `kbd_raw_poll()` между блитами занятой фазы (они > бесплатны; сами по себе не помогали, но вместе с хуком закрывают > именно этот зазор) и при необходимости внутрь тайловых циклов > `pop_bg` — тогда слепым остаётся только тело одного блита. > 2. Мерить тем же счётным методом (см. ниже), а не на ощупь: скриптовые > нажатия ровнее человеческих, поэтому набирать выборку от 50 нажатий. > 3. Если и это не добьёт — остаются два рычага вне нашего кода: Scan Code > Set 3 через BIOS `$EA` (убирает «fake shift» в корне, но в MAME > непроверяемо — обратный путь к клавиатуре не разведён) и общий > `m_irq_off_timer` в драйвере MAME. **Симптом (пользователь, 2026-08-01).** Залипаний почти нет, но при УДЕРЖИВАЕМОМ Shift первые один-два нажатия ← дают осторожные шаги, дальше нажатия ← не отрабатываются, пока Shift не отпустишь. **Рабочая гипотеза (механизм, а не догадка «что-то с клавиатурой»).** Три известных факта складываются в одну картину: 1. **PS/2 Set 2, «fake shift».** При зажатом Shift нажатие РАСШИРЕННОЙ клавиши (стрелки — `E0`-коды) обрамляется фиктивным отпусканием/нажатием шифта: нажатие ← шлёт `E0 F0 12` + `E0 6B` = **5 байт** (без шифта было бы 2), отпускание — `E0 F0 6B` + `E0 12` = **5 байт** (было 3). То есть ровно в связке Shift+стрелка трафик удваивается. 2. **Приёмный FIFO SIO — 3 байта.** Пачка в 5 байт переживает только то, что мы успеваем вычерпывать её по ходу. Потерянный make стрелки = «нажатие не отработало»; потерянный break = залипание (его лечит `kbd_raw_sync`, но ценой сброса всех немодификаторных клавиш). 3. **Импульс IRQ клавиатуры в MAME живёт 32 такта CPU.** `mame/sources/MAME/src/mame/sinclair/sprinter.cpp`: `on_kbd_data()` выставляет `m_irqs->in_set<1>()` НА КАЖДЫЙ принятый байт (то есть старая запись в `docs/TODO.md` «MAME не даёт per-byte INT» — неверна), но тут же заводит `m_irq_off_timer` на 32 такта, а `irq_off()` снимает линию. **Если в эти 32 такта мы под `DI` — прерывание пропало насовсем**, байт остаётся в FIFO до следующего IRQ (следующий байт или кадровый 50 Гц). 4. **Наши DI-окна длинные.** Ядра акселератора держат `di` на ВЕСЬ блит (`libbgi/bgi256/_bgi_blit_cols_raw.c:47` — «один DI на весь блит»); порядок цены прохода — 13.6 К тактов (`libbgi/include/gfx.h`), это сотни микросекунд, на порядки больше 32-тактового импульса. Отсюда: **обе версии пользователя — про одно и то же.** Логика ввода (`pop_ctrl.c`, порт `read_user_control`/`safe_step`) сверена с SDLPoP и выглядит корректной: `safe_step()` ставит `control_forward = CONTROL_IGNORE`, и это снимается в `read_user_control()` при ОТПУСКАНИИ стрелки — то есть повторные тапы ← при зажатом Shift обязаны работать. Не работают они потому, что до нас не доезжает либо make, либо break стрелки. **План проверки — по шагам, каждый даёт артефакт:** 1. Счётчики в MAME: брейк на `_kbdraw_overrun` (запись) и на ветке `tr_kbd_drain` — сколько overrun'ов за 10 с при «Shift зажат, тапаю ←» против «тапаю ← без Shift». Ожидание по гипотезе: с Shift кратно больше. 2. Замер максимального DI-окна кадра: брейкпоинты на `di`/`ei` в `_bgi_blit_cols_raw` + `{printf totalcycles; g}` — получить реальную длину в тактах и в микросекундах. 3. **Спайк «блит без DI».** `docs/new/06-accel.md §6.6`: новая прошивка допускает работу акселератора при EI (по приходу прерывания он отключается, по `RETI` включается обратно); старая — нет. Собрать libbgi с убранным `di` в блит/heal-ядрах, прогнать roomtest в MAME: (а) не рушится ли картинка, (б) падает ли счётчик overrun из п.1. Если да — причина подтверждена, и дальше это вопрос «какая прошивка на живом железе» (по умолчанию оставить DI, режим без DI — опцией libbgi). 4. **Независимо от п.3 — `kbd_raw_poll()`.** Вычерпывание FIFO ОПРОСОМ (порт `0x19` бит 0 → читать `0x18`, тот же декодер make/break, что в трамплине) из главного цикла 2–4 раза за кадр между фазами `PROF()`. Снимает зависимость от «поймали ли мы импульс IRQ» вообще, стоит сотни тактов, графику не трогает. Реализация: вынести drain-цикл из `libc/irq/_irq_tramp.c` в общий кусок либо продублировать в `libc/kbd/kbd_raw_poll.c`; тело обязано идти под `DI` (гонка с ISR за деструктивное чтение порта 0x18). 5. Побочно сюда же играет **[T-2](bug_list.md#t-2) (idle-skip)**: не перерисовывать Кида, пока поза/координаты не менялись, — это минус heal+blit (то есть минус DI-окна) в самых спокойных кадрах, где как раз и тапают Shift+стрелку. 6. Только если после 3–4 симптом жив — копать логику `control_shift2`/`CONTROL_IGNORE` против `seg005.c:374..390`. **Критерий готовности:** при зажатом Shift десять тапов ← дают десять осторожных шагов (проверка в MAME через `:kbd:ms_naturl:*` напрямую, НЕ через `press_key` — тот дёргает обе клавиатуры, см. `docs/libc-reference.md` ``). --- ### KBD-1: ЧТО ИЗМЕРЕНО (сессия 2026-08-01) — гипотеза про DI НЕ подтвердилась **Методика.** Симптом «нажатие не отработало» переведён в счётчики, чтобы не спорить с глазами. Нажимается **Home** — тоже расширенная клавиша (тот же `E0`-префикс и тот же «fake shift», что у стрелок), но игрой игнорируется, поэтому Кид стоит на месте и рельеф комнаты на результат не влияет. Брейкпоинты с действием `{ b@ADDR = b@ADDR + 1 ; g }` (счёт без остановки машины) в трёх точках: вход клавиатурной ветки трамплина, чтение порта 0x18 внутри drain-цикла, запись make-бита для кода `0x6C`. Скратч-байты — хвост `ovr_tile[]` (в этом сценарии не используется). **Симптом воспроизведён скриптом:** при зажатом Shift 10 нажатий → до декодера дошло 9 make-байт. Без Shift потерь нет — ровно как сообщил пользователь. | Прогон | make дошло / нажато | overrun | |--------|---------------------|---------| | игра идёт, `kbd_raw_poll` ВКЛ | 9 / 10 | 3 | | игра идёт, `kbd_raw_poll` ВЫКЛ (патч `ret` в точке входа) | 9 / 10 | 4 | | игра ЗАМОРОЖЕНА клавишей «1» (блитов нет вообще, значит и длинных DI нет) | **8 / 10** | 6 | **Вывод 1: наши DI-окна ни при чём.** В замороженном кадре, где блитов нет и прерывания разрешены практически всё время, потерь НЕ меньше, а больше. **Вывод 2: `kbd_raw_poll()` в текущей расстановке бесполезен** — 9/10 и с ним, и без. Причина понятна задним числом: шесть вызовов стоят В ТЕХ ЖЕ точках, где прерывания и так разрешены, то есть добавляют ровно то, что трамплин сделал бы сам. Вызовы из `roomtest.c` убраны; сама функция в libc оставлена — она корректна и нужна как заготовка под «плотный опрос» (см. ниже), но в горячем цикле её держать не за что. **Вывод 3 (главный): байт теряется НИЖЕ нашего кода.** Счётчик чтений порта 0x18: 5 нажатий Shift+Home должны дать ровно 50 байт (нажатие `E0 F0 12` + `E0 6C`, отпускание `E0 F0 6C` + `E0 12` = по 10 на цикл). Насчитано **49** — и ровно один make потерян. То есть до процессора байт не доехал вообще, декодер тут ни при чём. **Вывод 4: прерывание на байт теряется примерно в 44 % случаев.** На тех же 49 прочитанных байтах — только **28 входов** в клавиатурную ветку трамплина (1.75 байта за вход). То есть больше сорока процентов импульсов запроса не были обслужены, и байты копятся в трёхбайтовом FIFO вплотную к его потолку; одна неудачная пауза — и байт потерян. ### KBD-1: ПОТОЛОК ПЛОТНОГО ОПРОСА ИЗМЕРЕН — приём лечит полностью `tests/kbdpoll` — программа, которая не делает НИЧЕГО, кроме `kbd_raw_poll()` в бесконечном цикле (ни графики, ни vsync, ни вывода: любая работа разредила бы опрос и испортила замер). Это физический максимум плотности. Тот же счётный метод, те же брейкпоинты-счётчики. | Прогон | нажатий | make дошло | байт прочитано / ожидалось | |--------|---------|-----------|-----------------------------| | контроль: Shift зажат 4 с, нажатий нет | 0 | 0 | 0 (Shift сам ничего не шлёт — автоповтора у модификатора нет) | | Shift + Home | **25** | **25** | **250 / 250** | **Ни одного потерянного байта.** Для сравнения: в игре при шести вызовах за кадр терялся 1 байт из 50. При такой частоте потерь вероятность случайно получить ноль потерь на 250 байтах ≈ 0.6 %, так что результат не совпадение. **Вывод: опрос — рабочее решение, вопрос только в ПЛОТНОСТИ.** Нужно опрашивать примерно раз в 0.5 мс (≈10 000 тактов), а шесть вызовов за 60-мс кадр давали один раз в 10 мс — в двадцать раз реже необходимого. **Где взять частоту:** логический тик = 60 мс, из них ~18 мс занято работой и **~42 мс процессор простаивает внутри `gfx_wait_vsync`**, опрашивая луч. Опрос там стоит ноль и покрывает две трети периода с запасом по плотности. Остаётся слепым только тело одного accel-блита под DI (до ~650 мкс) — разорвать его нельзя (см. «что НЕ делать»). **Почему нужна именно такая частота (вопрос «PS/2 же не даёт больше 30 нажатий в секунду»).** Частота опроса определяется НЕ темпом нажатий, а темпом байт ВНУТРИ одного нажатия и глубиной FIFO. Одно нажатие при зажатом Shift — это 5 байт подряд (`E0 F0 12`, `E0 6C`), отпускание — ещё 5, и клавиатура выдаёт их со скоростью провода: 11 бит на байт при ~10–16 кГц = ~0.7–1.1 мс на байт. Воронка — 3 байта. Значит между двумя вычерпываниями имеют право прийти максимум два байта, то есть вычерпывать надо не реже чем раз в ~1.5–2 мс (0.5 мс взято с запасом). **Даже ОДНО нажатие в секунду переполнит FIFO**, если в эти несколько миллисекунд его никто не разгребает. Замер это подтверждает: 1.75 байта за одно вычерпывание — уже 58 % ёмкости. В норме разгребает прерывание; опрос понадобился только потому, что ~44 % импульсов здесь теряется. **Альтернатива, которая убирает опрос совсем — уменьшить трафик, а не ускорять разгребание.** BIOS `$EA` (`FN_KBD_OUT`, `docs/new/09-input.md` §9.2) шлёт байт НА клавиатуру, то есть ей можно скомандовать: - **Scan Code Set 3** — нет ни «fake shift», ни `E0`-префиксов: make = 1 байт, break = 2. Нажатие с шифтом перестаёт превышать FIFO в принципе. - либо хотя бы отключить typematic (`0xF5`/`0xF7`). **Но проверить это в MAME НЕЛЬЗЯ:** в `sprinter.cpp` подключено только направление клавиатура→SIO (`m_kbd->out_data_cb() → rxa_w`); обратный путь (SIO→клавиатура) не разведён вовсе, так что команда просто уйдёт в никуда. Плюс пришлось бы переписать все наши константы кодов под Set 3. Значит это кандидат на «когда дойдём до реального железа», а не на сейчас. **Что сделано по этому плану (2026-08-01):** 1. ✅ Idle-хук в libbgi: `gfx_set_idle_hook(fn)`, вызывается в цикле ожидания луча внутри `gfx_wait_vsync`. Приложение ставит туда `kbd_raw_poll`. Полезен не только нам — любой программе даёт «качать» что-то в ожидании кадра. Осторожно с регистрами: цикл ждёт на BC-таймауте, вокруг вызова нужен push/pop, а сам таймаут в итерациях станет длиннее по времени. **Важно про цену: это НЕ новая нагрузка.** Опрос ставится ровно туда, где процессор и так впустую крутит `in a,(#0xFE)` — 42 мс из 60. Полезной работы не отнимается нисколько. **Ограничитель области, если «постоянный опрос» всё равно не нравится:** потери случаются ТОЛЬКО при зажатом модификаторе (замерено; без Shift потерь нет). Значит хук можно взводить лишь пока нажат Shift/Ctrl/Alt — тогда опрос работает исключительно в той ситуации, ради которой заведён. 2. ✅ Перемерено в roomtest тем же счётным методом: **35/35**, потерь нет. 3. ⏳ Вызовы в занятую треть кадра НЕ возвращены: одного idle-хука хватило. Держать в уме, если на реальном железе или на более тяжёлых сценах (несколько стражей) потери появятся снова — накрыть блиты дешевле, чем изобретать что-то новое. 4. ⏳ Ручная проверка пользователем — без неё этап не закрыт: скриптовые нажатия ровнее человеческих, и «залипания до отпускания Shift» они не воспроизводили с самого начала. **Куда смотреть дальше, если плотного опроса не хватит.** 1. **Драйвер MAME — НЕ ТРОГАЕМ** (решение пользователя: пересборка MAME на его машине занимает часы). Для протокола, подозрение осталось: `sinclair/sprinter.cpp` держит запрос от клавиатуры ровно **32 такта CPU**, и `m_irq_off_timer` — **один на два источника** (`irq_on()` экрана заводит его же, `irq_off()` гасит разом обе линии). То есть кадровое прерывание способно обрезать клавиатурный импульс — правдоподобное объяснение «44 % пропущенных импульсов». 2. **Реальное железо.** Если п.1 — чисто эмуляционный артефакт, на железе проблемы может не быть вовсе. Проверять при первом прогоне на живом Sprinter. **Про совпадение кадрового и клавиатурного прерываний** (вопрос пользователя, 2026-08-01). Документация Sprinter: оба приходят с вектором `0FFh`, различать по биту приёма байта в порту клавиатуры — «не пришёл, значит экран»; совпадение возможно, но «исключительно редкий случай» (в новой версии обещают развести жёстче через ПЛМ). То есть наш трамплин делает ровно предписанное. Известный побочный эффект: при совпадении мы обслуживаем клавиатуру и `reti`, пропуская кадровую цепочку и DSS — на потерю байт это не влияет (линия кадрового остаётся взведённой и вызывает повторный вход), но кадровый тик может пропасть. Отдельная мелкая правка, в KBD-1 не входит. **Что НЕ делать (проверено, стоило времени):** - **Снимать `di` в accel-ядрах libbgi нельзя.** Патч `di`→`nop` в `_bgi_blit_cols_raw`/`_bgi_heal_rows_raw`/`_bgi_blit_rows_raw` прямо в памяти **уронил машину в перезагрузку**. То есть режим «акселератор работает при EI» из `docs/new/06-accel.md §6.6` в этой прошивке/эмуляции недоступен — вопрос закрыт артефактом, а не рассуждением. - Дробить DI-окна по колонкам смысла тоже нет: см. вывод 1. --- ### CLIP-1. Аудит блитов: где клип не нужен — **СДЕЛАНО 2026-08-01** > **Итог.** Heal Кида и стража переведены на выбор ядра по тому же тесту, > что давно стоит у блитов. Замер в MAME (счётчики `totalcycles` на входах > `kid_heal` и `kid_tick`, то есть вся группа heal за кадр; комната 1, Кид > стоит, стража нет): > > | путь | тактов на кадр | кадров в выборке | > |------|----------------|------------------| > | клипающее ядро (как было) | **26 200** | 149 | > | noclip (стало) | **15 848** | 239 | > > **−10 352 такта на кадр, то есть −39.5 % с группы heal** (≈0.49 мс при > ~21 МГц). A/B честный: оба замера сняты в ОДНОМ прогоне, вторая половина — > с пропатченным в памяти условием (`jr nz` → `jr` в `pop_heal_fast`), то > есть на той же геометрии и в той же сцене. > > **Размер: −362 Б суммарно** (не плюс!): `_CODE` 25 289 → 25 306 (+17), > BANK2 13 792 → **13 676** (−116, свободно стало 2708 Б — это тот самый > тесный банк из рисков `levels_plan.md` §5), BANK3 6512 → 6249 (−263), > BANK4 без изменений. > > **Грабли, стоившие двух пересборок** (вынесено в память > `sdcc-static-inline-double-cost`): первым заходом хелпер был `static > inline` в `pop_bg.h` — и SDCC 4.5 И встроил его тело (181 Б) в каждое > место вызова, И оставил отдельную копию в КАЖДОМ TU, который видит > заголовок. `pop_guard_heal` раздулся с ~60 до 663 Б, итого +1091 Б в > `_CODE` и +636 Б в банке стража. Лечится обычной функцией в одном > резидентном модуле (`pop_draw.c`, W1 — из банков это прямой `call` без > трамплина, как у `pop_sword_draw`). > > **Проверено визуально:** обычная ходьба, прыжок, спуск и позиция «за > решёткой шва» (straddle — там как раз работает клипающий фолбэк) — > артефактов и следов нет. **Ниже — исходная постановка задачи (что и почему смотрели).** **Зачем сейчас.** Кадр занят на ~86 %; подготовка клипающего варианта стоит ~5.6 К тактов на вызов, а общее ядро против линейного — 13 288 против 4 617 тактов на спрайт 32×3 (`libbgi/include/gfx.h`). Это самая дешёвая оставшаяся оптимизация: не переписывание логики, а выбор ядра. **Что уже правильно** (шаблон, который надо распространить): блиты Кида, стража, клинка и брызг спрашивают `pop_onscreen_cols()` и уходят в `gfx_blit_cols_part_noclip`, иначе в клипающий вариант (`pop_kid.c:86,591,676`, `pop_gdraw.c:105`). **Что чинили:** - ✅ `kid_heal()` и `pop_guard_heal()` звали `gfx_heal` — **всегда с клипом**, хотя `gfx_heal_noclip` существует и `heal_off` в `pop_bg.c` им уже пользовался. Это heal 2–4 прямоугольников КАЖДЫЙ кадр; замер общего ядра — 11 658 тактов на heal 22×22. Теперь все три идут через общий `pop_heal_fast` (`pop_draw.c` + `_pop_draw.h`). - ⛔ `pop_room_clip_borders()` (`pop_bg.c`) — `gfx_heal(0,0,320,…)`: **оставлен клипающим осознанно**. Полоса шириной 320 не лезет в 8-битный параметр noclip-ядра, а бить её на два куска по 160 нет смысла: гейт `border_dirty` пускает туда только в кадрах падения, и выигрыш подготовки тонет в цене самих 320×28 пикселей. Причина записана прямо в коде, чтобы не «оптимизировать» повторно. **Что обязано остаться с клипом** (зафиксировано комментариями в коде): - кромочные тайлы фона (`blit_b` в `pop_bg.c`) — тайл у края экрана режется по построению; - спрайты при straddle (`kid_render_dx = ∓140`, комната Кида ≠ отрисованной) и при падении ниже поля — фолбэки в `kid_draw`/`pop_guard_draw`; - борта поля (`pop_room_clip_borders`) — см. выше. **Что уже было правильно** (шаблон, который и распространили): блиты Кида, стража, клинка и брызг спрашивают `pop_onscreen_cols()` и уходят в `gfx_blit_cols_part_noclip`. Отдельный случай — `pop_kid_img_blit`: noclip БЕЗ проверки, потому что единственный вызывающий (полоса HP) рисует по фиксированным координатам; это тоже помечено в коде. --- ## P1 — сразу после P0 (закрываем уровень 1 как ИГРУ, а не стенд) ### L1-START. Старт по данным уровня — **СДЕЛАНО 2026-08-01** Старт и оба рестарта (смерть, выпадение из уровня) сведены в один `pop_start_level()` — порт `start_level` + `do_startpos` + `set_start_pos` (seg003): комната/тайл/направление берутся из `pop_level_start_*`, направление инвертируется (`~start_dir`), поза входа — из `tbl_entry_pose`. У уровня 1 это «падение внутрь» плюс нажатие кнопки room5(0,2) — то самое, что захлопывает решётку за спиной. Проверено: старт даёт room 1, col 0, падение на row 1 — как по данным уровня. `#define ROOMNAV` оставлен ВКЛЮЧЁННЫМ осознанно: это наш чит, которого в оригинале не было, — как и `S` (выдать меч), `K`, `I`. Все они со временем съедутся в общий блок читов, разрешаемый в настройках (решение 2026-08-01). ### L1-EXIT. Выход с уровня (дверь уровня) — **СДЕЛАНО 2026-08-01** Портированы: ветка двери уровня из `up_pressed` + `go_up_leveldoor` (seg005:0482/0574) — в `pop_leveldoor_enter()` (`pop_map.c`, тайлы и геометрия) и `up_pressed()` (`pop_ctrl.c`, только последовательность); опкод `0xF1 END_LEVEL` в `play_seq` теперь инкрементит `pop_next_level` (порт `next_level`), а главный цикл по нему перезапускает уровень — ровно та точка, куда `levels_plan.md` §2.2 подключит загрузку уровня 2. Открытость двери проверяем по `modifier >= 42` (ветка `fix_exit_door`), а не по ванильному `leveldoor_open`: с ванильным условием можно войти в ещё ползущую створку. **Грабли, которые стоили отдельного разбора:** `go_up_leveldoor` сначала писал `Char.x`/`Char.direction`, и оба присваивания молча терялись — окно `Char` вокруг диспетчера возвращает назад ТОЛЬКО `curr_seq` и `sword` (`pop_savekid_state`). Направление оставалось «вправо», а все `DX` последовательности seq_70 отрицательные, поэтому Кид уходил ИЗ проёма влево. Вывод на будущее: геометрию персонажа в этом порте меняет `pop_map` (пишет в `Kid`), а не диспетчер. ✅ Косметика тоже закрыта: BUG-DOOR-CLIP (обрезка силуэта правым косяком проёма) — недоставало второй половины `clip_char` (`obj_clip_right`) и обрезки СПРАВА у колоночного блита. В libbgi добавлен `gfx_blit_cols_part_w(..., maxw)`; разбор — в [`bug_closed.md`](bug_closed.md). ### L1-TRIAGE. Ревизия багов — **ЧАСТЬ 1 СДЕЛАНА 2026-08-01** ✅ **Три Critical'а прогнаны в MAME и закрыты** (протокол с числами — в [`bug_closed.md`](bug_closed.md), раздел «Проверено в MAME 2026-08-01»): BUG-1 (провал на row 1 при переходе через открытые ворота) и BUG-2 (ping-pong при возврате) **не воспроизводятся**, BUG-3 (окклюзия climb-up на кнопке) закрыт фиксом `tile_code_drawn` от 2026-07-28. Заодно снят неверный диагноз BUG-1: репроекция Y при БОКОВОМ переходе — не наш пробел, а точное поведение `goto_other_room` (`SDLPoP/src/seg002.c:390` меняет только `x`). Список разделён на [`bug_list.md`](bug_list.md) (открытое) и [`bug_closed.md`](bug_closed.md) (закрытое + разбор корней). ✅ **Косметика окклюзии тоже закрыта** — BUG-CEIL-1/2/3 и BUG-OCCL-1 были починены кодом ещё в июле, а записи никто не снял: `ceil_over_kid_tile` (`pop_bg.c:1275`), `pop_ceil_modif` + `pop_ceil_shake_draw`/`_bake_empty` (`:547,815,827`), `bar` с `POP_YOFF+3` в `pop_room_redraw_seam_left` (`:793`), разделение слоёв по `add_backtable` vs `ptr_add_table` в `overlay_mid_tile` (`:1367`). Разбор — в [`bug_closed.md`](bug_closed.md). ⏳ **Осталось:** закрыть таблицу обхода 24 комнат ([`bug_list.md`](bug_list.md#обход-всех-24-комнат-уровня-1)) — заполнена на 5 строк из 24, инструмент (`ROOMNAV`) готов. Делать вместе с L1-PASS: это единственный оставшийся источник новых багов уровня 1. ### L1-SPEED. Игра идёт быстрее оригинала (найдено 2026-08-01) Сверка таймингов: оригинал — `BASE_FPS = 60` при `base_speed = 5` тиков на логический кадр (`SDLPoP/src/types.h:1373`, `data.h:869`) = **83.3 мс**, в бою `fight_speed = 6` = **100 мс**. У нас `roomtest.c` ждёт **три** `gfx_wait_vsync()` = 60 мс, и отдельной скорости боя нет — то есть примерно **+39 % к скорости эталона**. Соответствие: 4 ожидания (80 мс) обычно, 5 (100 мс) в бою. Условие «делать ПОСЛЕ CLIP-1» **снято** — CLIP-1 закрыт (см. P0). Проверка — секундомером по одинаковому отрезку рядом с живым SDLPoP, не «на глаз». ### L1-PASS. Сквозное прохождение уровня 1 От старта до двери уровня одним заходом: подбор меча, страж, кнопки/ворота, пики, loose-полы, зелье, падения. Это приёмка этапа 1 и одновременно регресс-база для уровня 2. Совмещать с [таблицей обхода 24 комнат](bug_list.md#обход-всех-24-комнат-уровня-1): известные баги закрыты, значит новые придут только отсюда. Точки, где стоит смотреть внимательно, — уже закрытая косметика окклюзии (потолок при прыжке вверх, шов при анимации решётки, грани дальней колонны) и подъём на тайл-кнопку: см. оговорку к BUG-3 в [`bug_closed.md`](bug_closed.md). --- ## Отложено осознанно (не брать, пока не появится причина) - **Звук** (CBL-эффекты, Фаза 5 `PORT_PLAN.md`) — геймплей не блокирует. - **Таймер уровня / HUD времени / меню / сохранения** — Фаза 6. - **[T-1](bug_list.md#t-1)** (пики: перерисовка по причине) — отдаётся почти бесплатно после [T-2](bug_list.md#t-2), отдельно не окупается. - **Отключение мыши на время игры** и **замена PRNG** — `../docs/ideas_backlog.md` (оба дают доли процента кадра). - **OPT-1** (хирургический редрой шва) — решено НЕ делать, стоимость транзиентная; разбор в [`bug_closed.md`](bug_closed.md).