Переходы в соседние комнаты по горизонтали (порт SDLPoP leave_room/ goto_other_room/find_room_of_tile), проверено в MAME (room2↔room3↔room9, room1↔room5 и т.д.): - pop_level: pop_room_load теперь извлекает и rightcol (col0 правого соседа), как leftcol — для коллизии/рендера правого шва. - pop_map: pop_map_set_edges(l,r,u,d, lcol_fg, rcol_fg) — связи + кромки швов. get_tile(col=-1)=lcol (col9 левого), get_tile(col=10)=rcol (col0 правого), с гейтом по связи (нет соседа → стена) — порт find_room_of_tile. check_leave (порт leave_room): передний край char_x_left<=54 / char_x_right>=201 (и обратные <=57 / >=198) → x∓140, сигнал pop_leave_dir (1=left,2=right). - roomtest: rcol-массивы; enter_room задаёт edges; обработчик pop_leave_dir переключает комнату по pop_room_link. - Фикс двойного перехода: без коллизии ЛЕВОГО шва Kid, войдя справа в соседа (curr_col=-1), стоял «в стене» → in_wall выбрасывал его на второй переход. Левый шов (get_tile(-1)=lcol) это чинит. docs/gates_spikes_plan.md — ПОДРОБНЫЙ самодостаточный план на след. сессию: интерактивные объекты (RAISE/DROP-кнопки, гейты, пики) + HP/смерть. Контекст текущего roomtest, форматы уровня (LINKLOC/LINKMAP @1440/1696), данные room6, декод связи кнопка(0,2)→гейт room8(0,9), триггер пик (check_spike_below), точные ссылки SDLPoP, фазы P0(персистентное per-room состояние+trob)/ S(пики+HP/смерть)/B(кнопки+гейты). NB: L3-вверх (climb-up в комнату сверху) ещё не сделан. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Форматы ресурсов Prince of Persia — сводка
Каноническая спецификация форматов — 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— формат уровней и графики по официально опубликованным исходникам 1989 года (6502-ассемблер). Уверенность высокая везде — восстановлено прямым чтением кода движка, а не догадками.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.
Что дальше (не сделано в этом заходе)
- Точный кодек сжатия пикселей спрайтов в сыром DOS
.DAT(нужен только если понадобится читать именно нашу локальную копиюMSDOS/*.dat"как есть", а не ассеты из SDLPoPdata/) — сверка с исходником SDLPoP,src/seg009.c. - Семантика служебных полей
digisnd*.dat/ibm_snd*.datперед сырыми сэмплами/нотами (частично прояснено документацией Princed Resources — PC speaker: 1 байт заголовка + повторяющиеся тройки байт "2 байта частоты- 1 байт длительности"; WAV: 8 бит, моно, unsigned, 11025 Гц).
- Назначение бит
secmaskвBLUETYPE(Apple II) и служебного блокаid=2000в начале DOSlevels.dat(16 байт в нашей копии, но 2305 байт в версии SDLPoP — расхождение между релизами, не разобрано). - Оценка, какие видеорежимы/цветовые палитры ZX Sprinter реалистично покрывают исходную графику (CGA/EGA/VGA варианты в DOS-ресурсах против hi-res Apple II) — отдельная архитектурная задача порта, не формат ресурсов как таковой.