Sprinter-SDCC/applications/PoP/docs/KID_PLAN.md

Prince of Persia — Kid (персонаж): анализ и план

Статус: РЕАЛИЗОВАНО (2026-08-01). Kid играется целиком: интерпретатор seqtbl + frame_table (roomtest/pop_kid.c), диспетчер control() (pop_ctrl.c), коллизия/физика/зацеп (pop_map.c), бой и HP. Модель персонажа стала общей: Char-окно (pop_state.c) обслуживает и Кида, и стражей. Таблицы кадров и seqtbl уехали из _CODE в EMM-страницу (kid_data.bin, см. layout_plan_v2.md шаг 1).

Отступление от §2.1 плана: выбран ПАДДИНГ кадров (общий канвас), а не per-frame offset — компромисс зафиксирован в PORT_PLAN.md §6.1.

Документ оставлен как СПРАВОЧНИК по модели персонажа (char_type, категории actions_*, устройство play_seq, объём спрайтов) — он нужен при портировании остальных акторов (скелет, тень, визирь). Текущие задачи — ../roomtest/TASKS_OPEN.md.

Составлен 2026-07-16. Опирается на разбор SDLPoP/src/seg006.c (ядро физики/управления Kid), seqtbl.c (таблицы последовательностей), types.h (char_type, seq_, SEQ_, actions_*), SDLPoP/data/KID (спрайты). Фон уже готов и проверен на MAME (applications/PoP/roomtest, см. memory/pop_background_strategy) — Kid развиваем в том же roomtest как новый PoC (решение пользователя: старый poc/ не трогаем).

Копирайт: спрайты Kid (SDLPoP/data/KID) — Broderbund/Ubisoft. Использование настоящей графики Kid — сознательное решение пользователя (в отличие от плейсхолдера в старом poc/, см. PORT_PLAN §5.1).

---

1. Как устроен персонаж в оригинале (что портируем)

1.1 Состояние — char_type (14 полей, types.h)

frame       текущий номер кадра (индекс во frame_table_kid)
x, y        позиция (byte; x — с учётом direction)
direction   -1 влево / 0 вправо
curr_col,   логическая клетка (тайл), где персонаж
curr_row
action      КАТЕГОРИЯ действия (actions_*, см. 1.2)
fall_x,     скорость падения (fall_y<22 = 1 ряд, <33 = 2 ряда)
fall_y
room        комната
repeat      счётчик для удержания-ввода (напр. повторный прыжок)
sword       есть ли меч (бой — вне Фазы 1)
alive       жив/мёртв
curr_seq    УКАЗАТЕЛЬ в seqtbl (байткод текущей последовательности)

Состояние крошечное — легко живёт в W2.

1.2 Категории действия — actions_* (9 шт)

0 stand, 1 run_jump, 2 hang_climb, 3 in_midair, 4 in_freefall, 5 bumped, 6 hang_straight, 7 turn, 99 hurt. action определяет, как check_action()/play_kid() реагируют на ввод и физику каждый тик.

1.3 Движок анимации/движения — ГЛАВНОЕ

Движение НЕ физика, а байткод + per-frame смещения (подтверждает PORT_PLAN §6). Три уровня:

1. seqtbl — байткод-программа на действие. Опкоды (types.h): SEQ_DX(0xFB) сдвиг x на amount×direction, SEQ_DY(0xFA) сдвиг y, SEQ_FLIP(0xFE) разворот, SEQ_JMP(0xFF)/SEQ_JMP_IF_FEATHER(0xF7), SEQ_UP/SEQ_DOWN(0xFD/0xFC) смена ряда, SEQ_ACTION(0xF9) задать Char.action, SEQ_SET_FALL(0xF8), SEQ_KNOCK_UP/DOWN, SEQ_SOUND, SEQ_DIE/SEQ_END_LEVEL/SEQ_GET_ITEM. Байт < 0xF0 = НОМЕР КАДРА → ставит Char.frame и play_seq возвращается (один кадр за тик).
2. play_seq() (seg006.c:570) — интерпретатор: крутит опкоды из seqtbl + Char.curr_seq, пока не встретит кадр. ~15 case — портируется 1-в-1. Квирк: seqtbl использует АБСОЛЮТНЫЕ DOS-адреса в JMP; SEQTBL_0 = seqtbl - SEQTBL_BASE(0x196E) — при порте пересчитать базу (JMP-адреса в наших данных).
3. frame_table_kid[] (seg006.c:127, ~180 кадров) — на КАЖДЫЙ кадр: {image, sword_flags, dx, dy, flags}. image — индекс спрайта Kid; dx/dy — смещение позиции ЭТОГО кадра; flags: 0x1F weight_x, 0x20 thin, 0x40 needs_floor, 0x80 even/odd-pixel (влияет на x-рендер).

Тик персонажа: play_kid() (диспетчер по action+вводу) → play_seq() (двигает curr_seq, ставит кадр, применяет seq-dx/dy) → frame_table[frame] даёт image+собственные dx/dy → позиция и спрайт. У нас это ложится на sprite_frame+sprite_move (НЕ sprite_anim/sprite_moveto — см. PORT_PLAN §6: авторские таблицы, не автопрогрессия).

1.4 Управление — control_kid()/read_user_control() (seg006.c)

Читает ввод (у нас — held-state kbd_raw, уже готово, §2 PORT_PLAN) и по Char.action выбирает последовательность (seqtbl_offset_char(seq_id)). Логика «что можно из какого состояния» — ядро ощущения PoP.

1.5 Взаимодействие с картой — collision (seg006.c)

check_on_floor()/start_fall() — пол под ногами / падение в яму; in_wall() — упор в стену (сдвиг наружу); check_grab()/ can_grab_front_above() — зацеп за уступ; fell_out() — вывалиться из комнаты; check_spiked()/loose — ловушки; fall_accel()/fall_speed() — ускорение падения. Всё читает ТИП тайла (get_tile) — у нас это уже разобранные fg[]/bg[] (level.h/room1_data.h).

---

2. Спрайты Kid (219 шт, 16 цветов, 177 КБ)

• 219 PNG (data/KID), 16-цветные (палитра res400.pal, 16×RGB как env/ wall), макс кадр 53×35 — влезает в лимит движка 64×64. 177 КБ в 8bpp.
• frame_table_kid отображает кадр→image (индекс спрайта). Число РАЗЛИЧНЫХ image — уточнить (≤219); паковать те, что реально используются платформинг-последовательностями Фазы 1 (не все 219 — бой/катсцены отдельно).
• Палитра: Kid 16 цветов → слоты Sprinter 0x70-0x7F (env 0x50, wall 0x60 уже заняты; Kid не пересекается). Пиксель i: 0→0xFF, i→0x70+i. Тот же пайплайн, что pop_pack_bg.py.
• Атлас: прямая адресация по номеру image (как фон): kid[img>>5], idx img&31; ~7 EMM-страниц (или SHIFT=4). Свой пакер pop_pack_kid.py (переиспользовать код pop_pack_bg.py).

2.1 РЕШЕНИЕ ДО СТАРТА: per-frame offset vs padding

Кадры Kid — РАЗНОГО размера, а sprite_t рисует от угла фикс. w/h. Два пути (см. PORT_PLAN §6.1, memory/png_strip_padding_tradeoff):

• Padding (bottom-center) — просто, но 219×53×35 ≈ 406 КБ (раздув ×2.3).
• Per-frame offset — хранить XCO/YCO кадра (у оригинала он и есть, APPLEII_RESOURCE_FORMAT §2.2), рисовать blit(x+xco, y+yco); паддинг не нужен, память по факту (177 КБ). Требует лёгкого расширения хранения (offset рядом с кадром) ИЛИ ручного смещения в коде рендера Kid. Рекомендация: per-frame offset — оригинал так и делает (frame_table dx/dy

• image XCO/YCO), даёт точное позиционирование И экономию. Хранить xco/yco в нашей копии frame_table (добавить 2 байта/кадр — ~360 Б). Не тянуть расширение sprite.h — рисовать Kid прямым gfx_blit(x+xco, y+yco, img) (как фон), НЕ через retained sprite_t, раз позиция и кадр всё равно задаются вручную каждый тик.

---

3. Данные для порта (объём)

• frame_table_kid → C-массив ~180×(5+2 offset) ≈ 1.3 КБ (const, ROM).
• seqtbl (нужные последовательности) → C-массив байт. Весь seqtbl ~1-2 КБ; для Фазы 1 можно взять только платформинг-последовательности (вырезать бой/гардов 55-92) — оценить после разметки. JMP-адреса пересчитать под свою базу.
• Спрайты — атласы (EMM, не W2).

---

4. Фазы работы (по твоему списку, порядок по зависимостям)

Фаза K0 — конвейер спрайтов + отрисовка одного кадра

• pop_pack_kid.py: 219 (или подмножество) → kid*.atl + kid.pal (слоты 0x70), таблица кадр→image + xco/yco.
• Отрисовать Kid ОДНИМ кадром (stand) в roomtest поверх фона на верном тайле — проверить палитру/позицию/прозрачность на MAME.
• Артефакт-цель: Kid стоит на уступе комнаты 1 как в 1.1-2.png.

Фаза K1 — движок анимации (play_seq + frame_table)

• Портировать play_seq() (интерпретатор) + frame_table_kid + минимальный seqtbl (stand/run/turn).
• Прогнать несколько последовательностей вручную (stand→run→stop) — проверить, что кадры и смещения совпадают с оригиналом (сверять с SDLPoP/скриншотами, тайминг 50 Гц).

Фаза K2 — управление на месте + ходьба (твои а, б)

• control_kid подмножество: stand (2), run (1/84/13), turn (5/6), standing_jump (3), crouch (50/49), safe_step (29-44 — аккуратный шаг).
• Held-state через kbd_raw (готово).

Фаза K3 — коллизия с картой (твой п.3)

• check_on_floor/start_fall — падение в ямы (тип тайла под ногами из fg[]); in_wall/стоп у стены; fell_out (край экрана — пока без перехода комнат).
• Падения/приземления (seq 7/17/19/20) + fall_accel/fall_speed.

Фаза K4 — прыжки и повисание (твои а-прыжок, в)

• run_jump (4), jump_up (28/14), grab (8/16/24), climb_up (10)/down (68), hang (25/6), release (11/23). Это самый «PoP-овый» кусок — сверять дистанции/тайминг с оригиналом (не на глаз).

Фаза K5 — прочее (твой г)

• drink (78), level_door (70), crouch_hop (79), spiked/loose/chomped (ловушки, если тайлы есть в комнате), death (71).

Бой (меч, seq 55-92, стражники — seg005) — ВНЕ этого плана (отдельная фаза полного приложения, PORT_PLAN §7 Фаза 3).

---

5. Риски/решения ДО кода (правило defer_unexplained_quirks)

1. Per-frame offset (§2.1) — решить до K0 (влияет на формат данных). Рекомендация: xco/yco в frame_table, прямой blit.
2. seqtbl rebasing — JMP-адреса абсолютные (SEQTBL_BASE 0x196E); при порте пересчитать в оффсеты своего массива. Проверить на 1-2 seq.
3. Тайминг — оригинал (DOS) фиксированный тик; наш 50 Гц. Если логическая частота кадров иная — пересчёт dx/dy (PORT_PLAN §8.4). Сверять дистанцию бега/прыжка с эталоном.
4. Число реально нужных кадров/последовательностей для Фазы 1 — разметить (вырезать бой/катсцены/гардов), чтобы не тянуть все 219 спрайта и весь seqtbl.
5. Копирайт графики Kid — подтверждено решение пользователя (§вводная).

---

6. Что переиспользуем (готово)

• Фон комнаты (pop_bg.c) — Kid рисуется ПОВЕРХ (сейчас — прямым blit; heal против фона — когда/если понадобится через RAM-копию, фон её уже заполняет, GFX_BANK_TRANSPARENT).
• kbd_raw held-state (§2 PORT_PLAN) — готов и проверен.
• Пакер спрайтов/палитра (pop_pack_bg.py) — шаблон для pop_pack_kid.py.
• Разобранная карта комнаты (fg[]/bg[], level.h) — для коллизий.
• gfx_blit/gfx_w0_map из W0-атласа — проверенный путь (bgtest/roomtest).