snark13
babd40bc84
Контрольный замер перед оптимизацией (задача OPT-BLIT требовала начать с
него, а не с правок). Сцена: старт уровня 13, комната 23, шесть плит
сыплются с потолка вразнобой.
Пик логического кадра — 1 437 150 тактов при растровом кадре 430 000, то
есть 5-6 растровых кадров вместо трёх. По секциям (бюджет 400 000):
синяя 142 830 (в норме), зелёная до 805 000, циан до 632 000.
Что нашлось (всё подтверждено зондами, не гипотезы):
RDA_CEIL дрожащая плита-потолок 48 658 x до 6 = 292 000
RDA_CEIL_GONE запечь колодец 251 023 x до 2 = 619 000
RD_FLOOR щебень на месте посадки 198 259 x до 2 = 397 000
Внутри RDA_CEIL: heal 8 491 + draw_tile 39 029, а блитов в этом draw_tile
всего 1,17 на тайл (15-16 тыс.) — то есть ~23 700 тактов чистых накладных.
Подсчёт asm сходится до процентов: у draw_tile 26-байтовый стековый кадр и
513 обращений (ix), при ~46 замеренных тактах на обращение это те же
~23 600. У blit_b_clip — 22 Б кадра и 211 (ix).
Разбор одного pop_blit_b (157 замеров быстрого пути): atlas_image+w0_map
1 086, ядро libbgi 10 422, pop_cd_touch 4 502 (28%!), unmap+возврат 264.
В mob_render эти три pop_cd_touch к тому же ИЗБЫТОЧНЫ — коридор куска уже
помечен одним вызовом в pop_loose_mob_tick: 81 000 тактов в кадре впустую.
Итог по пиковому кадру: блиты 488 100 (34%), из них «железный» минимум
пикселей ~150 000; остальные ~1 150 000 (80% кадра) — наши накладные.
Узкое место не передача пикселей, а 16-битная арифметика в IX-кадрах.
Ответ на вопрос про uint8_t: просканированы все 109 .atl и наборы
TITLE/PV — максимум по игровому кадру 56x63 (kid3), фон 48x63, спрайты
комнаты принцессы 49x60. Шире 255 только восемь полноэкранных подложек
титров/сюжета (три 320x200 и пять 256..272), и все рисуются раз на экран.
Значит горячий путь переводится на байтовые габариты целиком, а подложкам —
отдельный банк / прямой libbgi (решение пользователя).
Документы (решение пользователя — вести работу по фазам, чтобы результаты
не теряись между сессиями):
docs/perf_l13_room23.md сцена, рецепт воспроизведения, зонды, канал clog,
сводка по кадрам, габариты спрайтов
docs/perf_green_phase.md зелёная фаза: раскладка, позиции G1..G6, журнал
docs/perf_cyan_phase.md циан: раскладка, позиции C1..C7, журнал
Отдельно записан рецепт воспроизведения: сцена повторяется ТОЛЬКО
перезапуском программы (ESC → зонды → roomtest). Возврат в комнату не
годится — упавшая плита уходит в страницу уровня насовсем; рестарт уровня
не годится — гряда доваливается заочно через trob комнаты 17, пока телепорт
уносит Кида; запись отладчиком на бегущей машине затирается тем же trob.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
139 lines
13 KiB
Markdown
139 lines
13 KiB
Markdown
# `applications/PoP/docs` — индекс + сводка по форматам ресурсов
|
||
|
||
## Индекс документов (актуальность на 2026-08-01)
|
||
|
||
**Живые планы — читать перед работой:**
|
||
|
||
| Документ | О чём |
|
||
|----------|-------|
|
||
| [`../roomtest/TASKS_OPEN.md`](../roomtest/TASKS_OPEN.md) | **Что берётся в работу сейчас** (не в этой папке, но входная точка) |
|
||
| [`../roomtest/BUGS_OPEN.md`](../roomtest/BUGS_OPEN.md) | Открытые баги roomtest (закрытые — в `BUGS_CLOSED.md` рядом) |
|
||
| [`impl_diff.md`](impl_diff.md) | **Осознанные расхождения с SDLPoP**: где мы сделали не дословно и почему |
|
||
| [`perf_l13_room23.md`](perf_l13_room23.md) | **Сцена и метод замера кадра** (каскад плит, ур.13 к.23): как воспроизвести, зонды, канал `clog`, сводка по кадрам, габариты спрайтов и ответ про `uint8_t`. 2026-08-17 |
|
||
| [`perf_green_phase.md`](perf_green_phase.md) | **ЗЕЛЁНАЯ фаза (слой фона)**: раскладка тактов, способы ускорения (G1..G6), журнал правок — рабочий документ между сессиями. 2026-08-17 |
|
||
| [`perf_cyan_phase.md`](perf_cyan_phase.md) | **ЦИАН фаза (персонажи + передний слой)**: раскладка тактов, способы ускорения (C1..C7), журнал правок — рабочий документ между сессиями. 2026-08-17 |
|
||
| [`perf_backlog.md`](perf_backlog.md) | Отложенная оптимизация отрисовки с замерами 2026-08-10 + **как мерить** (wait-state'ы, границы кадра). Позиции 1–7 переехали в фазовые документы выше |
|
||
| [`levels_plan.md`](levels_plan.md) | Следующий этап: уровни 2+, второй тайлсет, читы SDLPoP |
|
||
| [`levels_12_15_plan.md`](levels_12_15_plan.md) | **Уровни 12/13** (тень, Джафар, падающие плиты) + что такое 14/15 и 0. 2026-08-13 |
|
||
| [`midtable_analysis.md`](midtable_analysis.md) | **Слои отрисовки**: как устроены back/mid/fore и objtable в оригинале, чего стоит порт, развилки. 2026-08-13 |
|
||
| [`roomnav_skip.md`](roomnav_skip.md) | **Комнаты для отладочного телепорта**: какие пропускать и почему (посчитано по данным уровней). 2026-08-13 |
|
||
| [`layout_plan_v2.md`](layout_plan_v2.md) | Раскладка кода по окнам/банкам/страницам + замеры скорости отрисовки |
|
||
| [`room_model_plan.md`](room_model_plan.md) | `kid_room ≠ drawn_room` (straddle): сделан S1, остальное впереди |
|
||
| [`host_tests_plan.md`](host_tests_plan.md) | Модульные тесты движка под ucsim_z80: два шва, регрессии из `BUGS_CLOSED.md`, дифф против SDLPoP |
|
||
| [`shadow_render.md`](shadow_render.md) | **Вид Тени (OR+XOR)** — отложено: почему XOR несовместим с прозрачностью `#FF`, замер подготовки источника, четыре варианта |
|
||
| [`ideas_backlog.md`](ideas_backlog.md) | Осознанно отложенные гипотезы (мышь, PRNG) |
|
||
| [`prng_alternatives.md`](prng_alternatives.md) | Запасные генераторы, если упрёмся в бюджет кадра |
|
||
|
||
**Исполненные планы, оставленные как справочники:**
|
||
|
||
| Документ | Чем ещё полезен |
|
||
|----------|-----------------|
|
||
| [`PORT_PLAN.md`](PORT_PLAN.md) | Общая карта фаз со статусами; §6 (модель движения), §10 (режим памяти) |
|
||
| [`KID_PLAN.md`](KID_PLAN.md) | Модель персонажа: `char_type`, `actions_*`, устройство `play_seq` — нужна для скелета/тени/визиря |
|
||
| [`gates_spikes_plan.md`](gates_spikes_plan.md) | Раскладка объектов уровня 1 по комнатам, декод `LINKLOC`/`LINKMAP`, точные ссылки на seg-код |
|
||
|
||
**Форматы ресурсов** (ниже по этому файлу): `POP-DAT-FormatSpecifications.pdf`
|
||
/ `.txt` (первоисточник), `APPLEII_RESOURCE_FORMAT.md`,
|
||
`MSDOS_RESOURCE_FORMAT.md`.
|
||
|
||
Удалены 2026-08-01 как полностью исполненные и перекрытые кодом:
|
||
`clip_char_plan.md`, `double_buffer_plan.md`, `loose_floors_plan.md`,
|
||
`size_optimization_plan.md` (его §8 про скорость отрисовки перенесён в
|
||
`layout_plan_v2.md` §9). Ищутся в истории git, если понадобятся.
|
||
|
||
---
|
||
|
||
## Форматы ресурсов — сводка
|
||
|
||
**Каноническая спецификация форматов** — `POP-DAT-FormatSpecifications.pdf`
|
||
(+ текстовая конверсия `POP-DAT-FormatSpecifications.txt` для grep/цитирования):
|
||
*«Prince of Persia — Specifications of File Formats»*, Princed Development Team,
|
||
2008. Это первоисточник формата `DAT v1.0` (контейнер, индекс, чек-сумма,
|
||
кодеки RLE/LZG, палитры, уровни, звук), на котором построены и SDLPoP, и
|
||
Princed Resources. Документы ниже — наши практические заметки/сверки; при
|
||
расхождении источником истины считать спецификацию.
|
||
|
||
Цель этих документов — подготовить почву для будущего порта Prince of Persia
|
||
на ZX Sprinter, разобрав, как устроены ресурсы игры в двух доступных нам
|
||
версиях:
|
||
|
||
- [`APPLEII_RESOURCE_FORMAT.md`](./APPLEII_RESOURCE_FORMAT.md) — формат
|
||
уровней и графики по официально опубликованным исходникам 1989 года
|
||
(6502-ассемблер). Уверенность высокая везде — восстановлено прямым чтением
|
||
кода движка, а не догадками.
|
||
- [`MSDOS_RESOURCE_FORMAT.md`](./MSDOS_RESOURCE_FORMAT.md) — формат `.DAT`
|
||
ресурсов DOS-версии (исходников нет). Восстановлено эмпирически (разбор
|
||
байтов + перепроверка скриптами) и сверено с документацией открытых
|
||
сторонних инструментов (SDLPoP, Princed Resources).
|
||
|
||
## Главный вывод
|
||
|
||
**Формат уровня практически идентичен в обеих версиях**: Apple II `LEVELn`
|
||
занимает ровно 2304 байта (структура `blueprnt` — тайлы, связи
|
||
плит/дверей, граф экранов, метаданные старта Кида/стражников), а запись
|
||
уровня в DOS `levels.dat` занимает 2305 байт с байтовыми значениями тайлов
|
||
того же диапазона. То есть Джордан Мехнер перенёс формат карты уровня в
|
||
DOS-порт практически без изменений (+1 байт, вероятно контрольная сумма от
|
||
DOS-упаковщика). Это значит: раскладку `BLUETYPE`/`BLUESPEC`/`LINKLOC`/
|
||
`LINKMAP`/`MAP`/`INFO`, задокументированную по Apple II исходникам, можно
|
||
применять напрямую и к DOS `levels.dat`.
|
||
|
||
Формат же **графики отличается принципиально**: на Apple II это простой
|
||
несжатый rowbyte-формат hi-res экрана с плоской таблицей указателей; в DOS —
|
||
контейнер с оглавлением ресурсов (id/size/offset), с отдельными вариантами
|
||
под CGA/EGA/VGA — точный кодек пикселей внутри сырого `.DAT`-чанка не
|
||
восстановлен ни для той, ни для другой версии до конца. **Но для DOS-графики
|
||
это не блокирует работу**: в репозитории github.com/NagyD/SDLPoP (папка
|
||
`data/`) уже лежат готовые распакованные PNG для каждого спрайта/фона
|
||
(включая VGA-256-цветный вариант `VPALACE`/`VDUNGEON` — то, что нужно под
|
||
320×256×256 Sprinter), см. §5 `MSDOS_RESOURCE_FORMAT.md`. Это другой
|
||
релиз/сборка данных, чем наш локальный `MSDOS/` (некоторые звуковые `.dat`
|
||
отличаются по размеру), но нумерация ресурсов и формат контейнера — те же,
|
||
что подтверждено побайтовой сверкой уровня `res2001.bin`.
|
||
|
||
## Общий контейнерный формат DOS `.DAT` (кратко)
|
||
|
||
```
|
||
[0x00] u32 LE tableOffset — смещение начала таблицы оглавления
|
||
[0x04] u16 LE tableSize — размер таблицы оглавления
|
||
[0x06..tableOffset) — данные ресурсов (конкатенация чанков)
|
||
[tableOffset..tableOffset+tableSize)
|
||
— массив записей по 8 байт:
|
||
u16 size, u16 id, u16 offset(абсолютный), u16 reserved(=0)
|
||
```
|
||
|
||
Инвариант `tableOffset + tableSize == размер файла` подтверждён на всех 28
|
||
`.dat`-файлах в `MSDOS/`, и независимо — именованием файлов `res<id>.*` в
|
||
`data/` репозитория SDLPoP.
|
||
|
||
## Готовые ассеты для порта (важно для практической работы)
|
||
|
||
`github.com/NagyD/SDLPoP/tree/master/data` содержит не только код движка, но
|
||
и сами ресурсы игры — как сырые `.DAT`, так и распакованные поштучно файлы
|
||
(`res<id>.png` для спрайтов/фонов, `res<id>.pal` для палитр, `res<id>.bin`
|
||
для уровней). Для арт-ассетов (в т.ч. нужного полноцветного VGA-варианта
|
||
дворца/подземелий) практичнее взять их оттуда напрямую, чем писать свой
|
||
декодер сжатия пикселей DOS `.DAT`.
|
||
|
||
## Что дальше по форматам (не сделано и пока не нужно)
|
||
|
||
Порт читает уровень напрямую из `res200N.bin` (`roomtest/pop_level.c`), а
|
||
графику берёт из распакованных PNG `SDLPoP/data/` — поэтому ни один пункт
|
||
ниже сейчас не блокирует работу.
|
||
|
||
1. Точный кодек сжатия пикселей спрайтов в сыром DOS `.DAT` (нужен только
|
||
если понадобится читать именно нашу локальную копию `MSDOS/*.dat`
|
||
"как есть", а не ассеты из SDLPoP `data/`) — сверка с исходником SDLPoP,
|
||
`src/seg009.c`.
|
||
2. Семантика служебных полей `digisnd*.dat`/`ibm_snd*.dat` перед сырыми
|
||
сэмплами/нотами (частично прояснено документацией Princed Resources —
|
||
PC speaker: 1 байт заголовка + повторяющиеся тройки байт "2 байта частоты
|
||
+ 1 байт длительности"; WAV: 8 бит, моно, unsigned, 11025 Гц).
|
||
3. Назначение бит `secmask` в `BLUETYPE` (Apple II) и служебного блока
|
||
`id=2000` в начале DOS `levels.dat` (16 байт в нашей копии, но 2305 байт
|
||
в версии SDLPoP — расхождение между релизами, не разобрано).
|
||
4. Оценка, какие видеорежимы/цветовые палитры ZX Sprinter реалистично
|
||
покрывают исходную графику (CGA/EGA/VGA варианты в DOS-ресурсах против
|
||
hi-res Apple II) — отдельная архитектурная задача порта, не формат
|
||
ресурсов как таковой.
|