snark13
f8493a4c04
Замер отделил луч от pop_frame_timers: таймеры со всеми тремя
спецсобытиями уровней стоят 1 962, луч — 36 786, то есть 5,6 % работы
кадра на девять чтений байта.
Причина оказалась НЕ в алгоритме. Сверка трёх референсов:
SDLPoP (seg003:688) — идёт по x с шагом 14 и на каждом шаге переводит x
в колонку делением. Причём сам SDLPoP признаёт в комментарии, что
«DOS PoP does this: tile_div_tbl[xpos]» — то есть оригинал брал
таблицу, а порт заменил её на / и %, потому что на 32 битах так проще.
Apple II (MISC.S CHECKALERT) — тот же алгоритм байт в байт, но перевод
x -> блок через таблицу BlockTable[x]. Ровно то, что у нас уже было
сделано (POP_TILE_DIV, 2026-08-10).
mininim — другая архитектура (тайловые позиции, своя механика), для
сравнения реализации не годится.
То есть алгоритмически мы уже были на уровне Apple II, а платили за
другое: pop_tile_at объявлен __banked, луч живёт в guards.c (банк 1), и
на КАЖДУЮ колонку шёл трамплин банк 1 -> банк 3. На сцене 11/15 (Кид в
колонке 2, страж в 8) это девять трамплинов за кадр.
Сделано:
1. луч переведён на КОЛОНКИ вместо x-координат. Это эквивалентно:
начальные x — ровно центры тайлов персонажей, а обратный перевод даёт
ту же колонку (floor((58 + col*14 - 58)/14) == col). Ушли 16-битный
шаг, 16-битное сравнение и индексация таблицы на каждой итерации;
2. тайлы отрезка забираются ОДНИМ банковым вызовом (pop_row_tiles)
вместо девяти;
3. внутри pop_row_tiles — быстрый путь для отрезка целиком внутри
комнаты: get_tile при ряде 0..2 и колонке 0..9 сводится ровно к
g_fg[row*10+col] & 0x1F, идём указателем;
4. буфер тайлов — file-scope, а не локальный массив (иначе каждое
чтение это -n(ix)).
Замер по шагам: 36 786 -> 24 048 (колонки + один вызов) -> 13 002
(быстрый путь + буфер). Синяя фаза 283 215 -> 259 500, работа кадра
654 990 -> 628 542, то есть -26 448 при ожидании -30 000.
Кэш-гейт «пересчитывать только при смене позиции» НЕ понадобился:
расхождения с оригиналом нет, луч считается каждый кадр, как и должен.
Поведение проверено в MAME: страж в боевой стойке, но не идёт — между ним
и Кидом чомпер, то есть can_guard_see_kid = 1 («видит, но не пойдёт»).
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.