snark13
6d7c1c8b6b
Замер 11/15 показал, что loose-механика берёт 28 872 такта в комнате, где не анимируется ни одна плита и не летит ни один кусок. Раскладка зондами m9..m12: два цикла по тайлам 9 852, обход 14 слотов mob 12 090, поиск куска над головой Кида 5 868 (там ещё и банковый трамплин). Два гейта: loose_any (статик pop_map.c) — «идёт ли анимация плит». Ставят пять мест записи ненулевой фазы: make_loose_fall, ветка потолка в check_press, do_knock для обоих рядов и восстановление фазы из room_modif при входе в комнату. Снимает его сам цикл, по факту прохода, в котором не осталось ни одной живой фазы. pop_mob_busy (резидент pop_state.c) — «занят ли слот падающего куска» (active или дочистка clean). Ставит mob_alloc, снимает обход по факту пустой таблицы. В резиденте, а не в pop_room.c, потому что читает его pop_map из банка 3, а писучие статики банкового модуля наружу не видны. Гейт отвечает не на «есть ли в комнате плиты», а на «идёт ли анимация»: у лежащей плиты-потолка фаза нулевая, и крутить нечего (вопрос пользователя). Асимметрия намеренная — ложная единица стоит одного холостого прохода, ложный ноль стоит застывшей навсегда плиты, поэтому взвод стоит рядом с КАЖДОЙ записью, а снятие только по факту пустого прохода. Стало: 132 / 996 / 546, вся функция 28 872 -> 2 760. На кадре работа 801 768 -> 767 928. Ожидание по реестру было -28 000. Покрытие: новый phys_loose_gate_survives_room_change на пятое место взвода (фаза восстановлена входом в комнату) — единственное, которое не прогонял ни один тест, и дающее самый тихий отказ. Мутационная проверка: со снятым взводом тест падает (фаза 3 вместо 4). Заодно отладочный старт сразу в целевую комнату: make ROOM=15 POS=2 (дефолт), roomtest стартует в 11/15 с Кидом в (0,2). kid_init ставит x = x_bump[col] + TILE_SIZEX, а это левая граница СЛЕДУЮЩЕЙ колонки — с неё физика относила Кида в тайл чомпера, и он погибал на старте (найдено пользователем). Сдвиг внутрь на 2: колонку определяет весовая точка кадра, поэтому число снято замером, а не выведено геометрией. План работ между сессиями — docs/perf_registry.md §4: очередь позиций со статусами, текущий бюджет сцены, рецепт её воспроизведения и метод замера. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Prince of Persia на ZX Sprinter
Порт Prince of Persia на компьютер Sprinter Sp2000 поверх нашего target-слоя SDCC (sprinter-cc / libc / libbgi). Цель — 320×256×256 (режим 0x81), VGA-256 ассеты оригинала переносятся почти впрямую.
Состояние (2026-08-01): играется весь уровень 1 — комнаты и переходы, Kid со всем набором действий, ловушки, ворота, дверь уровня, меч и бой, стражи с ИИ, HP и зелья. Нет: перехода на следующий уровень, звука, таймера/HUD, сохранений.
- Что в работе прямо сейчас —
roomtest/TASKS_OPEN.md. - Следующий этап (уровни 2+) —
docs/levels_plan.md. - Общий план и статус фаз —
docs/PORT_PLAN.md. - Правила работы для ИИ-сессий —
CLAUDE.md.
Что где
| Папка | Назначение |
|---|---|
roomtest/ |
Активная разработка. Уровень 1 целиком: фон композицией тайлов, Kid (seqtbl-анимация, ввод, коллизия, падение, зацеп, окклюзия), ловушки, ворота, стражи, бой. Свой README/CLAUDE/TASKS. |
docs/ |
Планы и разбор форматов ресурсов Apple II / DOS — см. индекс в docs/README.md. |
toolchain/ |
Python-упаковщики ассетов под Sprinter (рендер комнат, атласы тайлов/Kid, извлечение данных анимации) + эталонные скриншоты. |
poc/ |
Ранний proof-of-concept (снег, атлас, raw-клавиатура). Ассеты в poc/res/. |
bgtest/, coltest/ |
Точечные проверки фона и коллизии. |
SDLPoP/, PR/, mininim/ |
Референсные реализации движка (GPL) — читаем логику/константы, НЕ копируем код. SDLPoP/data/ — источник распакованных VGA-ассетов. |
Prince-of-Persia-Apple-II/ |
Оригинальный 6502-исходник 1989 г. |
MSDOS/ |
Локальные .DAT-ресурсы DOS-версии. |
Референсы = только справочник
SDLPoP/, PR/, mininim/, Prince-of-Persia-Apple-II/ используются как
справочник структур/логики и как источник готовых ассетов — их код НЕ
копируется в наш порт (лицензии несовместимы, ABI другой). Любая механика
сверяется с SDLPoP/src/ до реализации.
Форматы ресурсов
Формат уровня почти идентичен в Apple II и DOS (2304 / 2305 байт,
blueprnt). Графика различается принципиально, но брать распакованные PNG
из SDLPoP/data/ практичнее, чем декодировать сырой .DAT. Подробности —
docs/README.md.