Документы отстали от кода: PORT_PLAN писал «PoC не начат», хотя играется весь уровень 1, а четыре плана были исполнены целиком. - PORT_PLAN: таблица статусов по разделам; фазы 0-3 сделаны, 4-6 нет; риски §8 п.1/п.3 закрыты, п.2 переформулирован под реальный движок (спрайтовый движок для персонажей не используется, лимит «21 спрайт» неприменим), п.4 — найдено расхождение таймингов: оригинал считает логический кадр за 5 тиков при BASE_FPS=60 (83.3 мс, в бою 100 мс), а мы ждём три vsync (60 мс) — игра идёт примерно на 39 % быстрее эталона. - levels_plan.md — новый: машинерия перехода между уровнями, второй тайлсет (palace), потабличные различия и читы SDLPoP, которые окупаются сразу. Инвентарь тайлов снят прямо с res200N.bin: уровень 2 не требует ни одного нового ассета и ни одной новой механики. - roomtest/TASKS.md — новый: доска текущих задач с критериями готовности. - Удалены как исполненные и перекрытые кодом: clip_char_plan, double_buffer_plan, loose_floors_plan, size_optimization_plan. Его §8 (замеры скорости отрисовки) не был перекрыт — перенесён в layout_plan_v2 §9, чтобы не потерять цифры. - KID_PLAN / gates_spikes_plan — шапки «реализовано, оставлено справочником»; room_model_plan — «S1 сделан, остальное не срочно». - docs/README.md стал индексом с отметками актуальности. - ideas_backlog: зелье переворота экрана — оригинал переворачивает готовый буфер построчно, спрайты не трогает; по данным уровней тип 4 встречается только на уровне 9, до него механика не нужна. - examples/scroll: ссылка на удалённый план вела к неверному факту «теневая копия одна — общая»; заменено на подтверждённое «у каждой страницы своя». Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
14 KiB
План: от одного уровня к нескольким (загрузка, переходы, тайлсеты)
Статус: план, 2026-08-01. Продолжает PORT_PLAN.md §7 (Фаза 1: «переходы
между экранами» → теперь между УРОВНЯМИ). Текущая точка: roomtest играет
уровень 1 целиком в одной комнате-за-комнатой модели, но уровень нельзя
ни выбрать, ни закончить.
Источник истины — ../SDLPoP/src/ (правило ../CLAUDE.md). Ключевые
места: seg000.c: load_lev_spr/play_level_2/init_game, seg005.c: up_pressed/go_up_leveldoor, seg006.c: play_seq → SEQ_END_LEVEL,
seg002.c (спецсобытия уровней), data.h:835..850 (потабличные различия
уровней).
0. Что уже готово (не проектировать заново)
- Формат и загрузчик уровня.
pop_level.c/.hчитает сыройres200N.bin(2305 Б) в отдельную EMM-страницу; путь — параметрpop_level_load(const char *). Мультиуровневость здесь стоит одной функции формирования имени. - Стартовая позиция уровня уже разобрана:
pop_level_start_room(),pop_level_start_pos(),pop_level_start_dir()— реализованы и пока НЕ вызываются (см.../roomtest/TASKS.mdL1-START). - Страж по данным уровня:
pop_level_guard()(портenter_guard), сохранение состояния между комнатами (pop_guard_state_save). - Палитра разложена по слотам ровно как в оригинале (
pop_pack_kid.pybuild_palette): env 0x50, wall 0x60, pot 0x40, kid 0x70, меч 0x80, страж 0x90. Это тот же раскрой, чтоset_pal_arr(0x50/0x60)вseg000.c:1140..1148, — значит смена тайлсета не требует переиндексации спрайтов Кида (см. §3). - Все 16 файлов уровней распакованы:
../SDLPoP/data/LEVELS/res2000.. res2015.bin(0 — демо-уровень).
1. Что реально различается между уровнями (замер по данным, не по памяти)
Таблицы из ../SDLPoP/src/data.h:840..847 + инвентарь тайлов, снятый прямо
с res200N.bin (маска fg & 0x1F):
| Ур. | Тайлсет | Страж | Новое против предыдущих |
|---|---|---|---|
| 1 | dungeon | обычный | — (текущая база) |
| 2 | dungeon | обычный | ничего нового: тот же набор объектов минус меч |
| 3 | dungeon | СКЕЛЕТ | чомперы |
| 4 | palace | обычный | тайлсет palace, зеркало (спецсобытие mirror_level) |
| 5 | palace | обычный | — |
| 6 | palace | ТОЛСТЫЙ | падение на входе (спецсобытие) |
| 7 | dungeon | обычный | — |
| 8, 9 | dungeon | обычный | — |
| 10, 11 | palace | обычный | — |
| 12 | dungeon | ТЕНЬ | seamless-выход (комната 23), исчезающий меч |
| 13 | dungeon | ВИЗИРЬ | мышь, особый выход |
| 14 | palace | нет | — |
| 15 | dungeon | нет | финал |
Прямое следствие для порядка работ: уровень 2 не требует ни одного нового ассета и ни одной новой механики — он проверяет ровно машинерию перехода. Это и есть первый шаг.
Прочие потабличные различия, которые придётся завести массивами по 16:
tbl_level_type (тайлсет), tbl_guard_type (−1 = стражей нет),
tbl_guard_hp, tbl_level_color (вариантные палитры, 1.3), tbl_entry_pose.
2. Шаг 1 — машинерия перехода (цель: уровни 1 → 2 → 3)
Порядок именно такой; каждый пункт проверяем в MAME отдельно.
2.1 Выход с уровня. Портировать up_pressed() ветку двери
(seg005.c:410..423) + go_up_leveldoor() (seg005.c:497): дверь рядом
(при/за/перед персонажем) И drawn_room != level.start_room И створка
открыта полностью (curr_room_modif >= 42 — вариант fix_exit_door) →
Char.x = x_bump[...] + 10, направление влево, seq_70_go_up_on_level_door.
Затем оживить опкод 0xF1 END_LEVEL в play_seq (../roomtest/pop_kid.c:418
— сейчас пустой break): ++pop_next_level, как seg006.c:662.
2.2 Цикл уровня. В main() после тика: if (pop_next_level != pop_current_level) → load_level(pop_next_level). Порядок сноса/подъёма
состояния (порт load_lev_spr + play_level_2):
pop_level_free → pop_level_load("LEVELS\\res200%d.bin") →
pop_trob_reset → pop_guard_reset → сброс tile-override'ов
(ovr_* в roomtest.c) → enter_room(pop_level_start_room()) →
kid_init(поза/позиция/направление из данных уровня).
HP через уровень переносится (в оригинале hitp_beg_lev), не сбрасывать
в максимум — сверить с seg000.c init_game/play_level_2.
2.3 Стражи по уровню. Завести tbl_guard_type[16]/tbl_guard_hp[16];
-1 = стражей на уровне нет (уровни 14, 15) — pop_guard_enter обязан это
понимать, иначе на 14-м полезут стражи из мусора. Для шага 1 (уровни 2, 3)
достаточно обычного стража, но проверку -1 заложить сразу.
2.4 Чит «следующий уровень» (Shift+L). Реализуется ровно тем же
pop_next_level — и без него отладка уровней превращается в прохождение
игры руками. Делать в этом же шаге, не позже (см. §4).
Приёмка шага 1: дверь уровня 1 → уровень 2 играется целиком → его дверь → уровень 3 стартует (чомперы могут быть ещё не портированы — тогда фиксируем как известное ограничение, а не «баг»).
3. Шаг 2 — второй тайлсет (palace, уровни 4+)
Ассеты. toolchain/pop_pack_bg.py уже читает PNG каскадом
VDUNGEON→VPALACE (та же логика, что в игре), но печёт ОДИН набор атласов
(pop_env0..4.atl, pop_wall.atl, pop_fore.atl ≈ 75 КБ). Нужен второй
набор из VPALACE (pal_env*.atl / pal_wall.atl), плюс torch_debris —
тайл, который встречается только на palace-уровнях. По EMM это ещё ~6
страниц при бюджете ~3.3 МБ — не проблема.
Палитра — главный технический вопрос, и он уже решён раскроем.
Тайлсет живёт в слотах 0x50..0x5F (env) и 0x60..0x6F (wall); Кид, меч,
страж, склянки — в других слотах. Значит смена тайлсета = перезапись 32
записей палитры (gfx_pal_set на обе страницы, как flash_bg в
roomtest.c), а НЕ перезагрузка kid.pal и не переиндексация спрайтов.
Сделать pal_dungeon.bin / pal_palace.bin (по 32 записи) и грузить при
смене типа уровня. Проверить артефактом: скриншот palace-комнаты против
рендера render_room.py для того же уровня.
Вариантные цвета уровней (tbl_level_color, level_var_palettes — это
уже 1.3, в 1.0 их нет): по той же механике, тот же диапазон слотов. Решение
на будущее — сначала базовые два тайлсета, потом при желании цвета.
Выбор набора в коде. pop_bg_load() сейчас грузит фиксированные имена;
превратить в pop_bg_load(type) с двумя таблицами имён + выгрузка старых
атласов при смене типа (atlas_free). Переключение — только на границе
уровня, не в кадре.
4. Читы SDLPoP: что взять на следующем этапе
Из ../SDLPoP/README.md (раздел Cheats). У нас уже есть: K — убить
стража, I — бессмертие (наш, в оригинале нет), S — выдать меч (наш),
+/− — обход комнат (ROOMNAV, наш).
Брать сразу вместе с переходами уровней (без них отладка дороже самой работы):
| Чит | Что даёт | Цена |
|---|---|---|
| Shift+L — следующий уровень | единственный вменяемый способ тестировать уровни 2..15 | тривиально: ++pop_next_level из §2.2 |
| R — воскресить Кида | у нас респавн по ↑ + таймаут; порт resurrect ближе к оригиналу и не мешает управлению |
низкая |
| Shift+S / Shift+T — +1 HP / +максимум | отладка боёвки без «ровно трёх попыток»; честная замена нашему читу бессмертия | низкая, HP-машинерия уже есть |
| [ и ] — сдвинуть Кида на пиксель (debug-чит SDLPoP) | прямо бьёт в наш класс багов «окклюзия/шов на один пиксель» — воспроизведение позы без ловли момента | тривиально |
Брать во вторую очередь:
| Чит | Почему позже |
|---|---|
| H / J / U / N + Ctrl+B — смотреть соседние комнаты | требует честной модели drawn_room ≠ Kid.room (наш S3-straddle, каркас есть: update_kid_render_dx). Зато потом заменяет самодельный ROOMNAV и попутно закрывает straddle-задачу |
| Shift+W — медленное падение (feather) | ветка JMP_IF_FEATHER (опкод 0xF7) в play_seq уже есть, но не проверена ничем — чит станет её единственным тестом |
| C / Shift+C — номера комнат | у нас номер рисуется палочками именно потому, что текст тянет 2 КБ знакогенератора в W2 (roomtest.c). Ждёт своего шрифта |
Не брать: Shift+I (переворот экрана), Shift+B (blind mode) —
развлекательные, к отладке порта отношения не имеют. −/+ (время) — нужен
таймер уровня, которого у нас нет (Фаза 6).
Отдельно, дорого, но очень ценно — F6/F9 (quicksave/quickload точного
состояния). Это сериализация Char + room_modif всех комнат + trob'ов +
состояния стражей. Даёт то, чего нам сейчас сильно не хватает:
воспроизводимый регресс в MAME («вот кадр, где баг») вместо ручного подхода
к позиции. Кандидат сразу после того, как заработают уровни.
5. Риски и что проверить артефактом до кодинга
- Размер кода. Замер сборки 2026-08-01:
_CODE25 119 Б, куча ~2.4 КБ, банк 2 (pop_bg) 13 792 / 16 384, банк 3 (pop_map) 6 331, банк 1 (guards) 1 896, банк 4 (pop_gdraw) 2 236. Чомперы, зеркало, скелет и второй тайлсет пойдут в банк 2 — там осталось 2.6 КБ. Прежде чем начинать §3, посчитать, куда лягут новые тайлы, иначе повторится история «банк 2 упёрся в потолок» (коммит2f3e854). Свободные номера банков есть (5+), гранулярность — файл. - Спецсобытия уровней (
seg002.c:level3_set_chkp,sword_disappears,Jaffar_exit, зеркало, мышь) — их НЕ надо портировать заранее. Для уровней 2 и 3 нужен только чекпойнт уровня 3. Остальное — по мере подхода к уровню. - Чомперы (уровень 3 и почти все дальше) — отдельная механика
(
animate_chomper+ коллизия + смерть); шаблон работы тот же, что у пик/ворот, см.gates_spikes_plan.md. tbl_guard_type = -1на уровнях 14/15: без проверки страж «появится» из неинициализированных данных.- Уровень 0 (демо) существует в данных, но в скоуп не входит.