Sprinter-SDCC/applications/PoP/roomtest/TASKS_OPEN.md

roomtest — доска ОТКРЫТЫХ задач (обновлено 2026-08-08)

Что берём в работу сейчас и в каком порядке. Каждая запись: что сделать, почему именно сейчас, чем подтверждать результат.

• закрытые задачи с протоколами и замерами — TASKS_CLOSED.md;
• открытые баги — bug_list.md, закрытые с разбором корней — bug_closed.md;
• планы фаз — ../docs/PORT_PLAN.md, ../docs/layout_plan_v2.md, ../docs/levels_plan.md.

Состояние на 2026-08-07: пользователь прогнал ВСЕ комнаты уровней 1 и 2 — крупных багов нет. Приёмки L1-PASS и L2-PASS закрыты; с прогона открыты три записи по уровню 2, из них цвет стража и брызги уже закрыты (см. bug_closed.md); открытым остался чит +/− в бою. Уровень 3: скелет сделан и проверен в MAME 2026-08-07 (бой, падение в пропасть, окклюзия), чомперов ещё нет.

Разгрузка банка 2 сделана 2026-08-08 (MEM-BANK2): 90.4 % → 35.8 %, свободно 10 512 Б — холодная половина уехала в банк 7 (pop_room.c), чомперам места с запасом.

DRAW-CHAR сделана и ПРОВЕРЕНА 2026-08-08 (протокол и замеры — TASKS_CLOSED.md): отрисовка теперь одна на всех Char. Банку 2 она дала всего +265 Б — место под чомперов дала уже MEM-BANK2.

Правило проекта в силе: механику сверять с ../SDLPoP/src/ ДО кодинга; диагноз платформы подтверждать артефактом (брейкпоинт/дамп/.asm), а не гипотезой (memory defer_unexplained_quirks).

---

ТЕКУЩАЯ ЦЕЛЬ: уровни 1–3 (подземелье) отлажены целиком

Решение 2026-08-04: palace (уровни 4+) откладываем, доводим до играбельности три dungeon-уровня. Основание — они не требуют ни одного нового ассета фона: инвентарь тайлов, снятый с res200N.bin, показывает, что новое появляется только так —

ур. 1  empty, floor, spike, pillar, gate, closer, potion, loose, debris,
       opener, level_door L/R, torch, wall, skeleton, sword     ← всё есть
ур. 2  bigpillar_bottom(8), bigpillar_top(9), doortop(12)       ← есть (2026-08-04)
ур. 3  chomper(18)                                              ← НЕТ механики
ур. 4  lattice_pillar(25)…lattice_right(29) + тайлсет palace    ← отложено

#	Задача	Что	Блокирует
1	GUARD-PHYS	физика стража = физика Кида (одна над Char)	ядро сделано 2026-08-07; открыт живой сценарий в MAME
—	DRAW-CHAR	отрисовка одна на всех Char — закрыта и проверена 2026-08-08	—
—	MEM-BANK2	разгрузка банка 2 — закрыта 2026-08-08: 90.4 % → 35.8 %, свободно 10 512 Б	—
2	L3-CHOMP	СЛЕДУЮЩАЯ: чомперы (5 шт)	прохождение ур. 3
—	L3-SKEL	скелет ур. 3 — сделан 2026-08-07, ждёт финальной приёмки	—
3	L3-PASS	приёмка уровня 3 (обход комнат)	закрытие цели
—	DRAW-COST	кадр уложился в бюджет 2026-08-09: 470 964 -> 425 600 тактов, период цикла 4 растровых кадра -> 3 (игра быстрее на треть). Дальнейшее — запас, не срочность	плавность на ВСЕХ уровнях
—	L1-SPEED	игра на ~39 % быстрее оригинала	ощущение от ВСЕХ уровней; берётся в любой момент
—	TUNE-1	параметры движка → cfg-файл (сейчас pop_tune.h)	отладка таймингов и моды; берётся по мере надобности

Сделанное по этой цели — в TASKS_CLOSED.md: L2 (машинерия уровней), L2-PASS, L1-PASS, L3-CHKP (чекпойнт уровня 3), MEM-BANK5, CLIP-1, KBD-1, DBG-CHEATS.

---

Ждёт ФИНАЛЬНОЙ приёмки уровней 1–3

Сюда попадает то, что уже работает в проверочном прогоне, но должно быть подтверждено на сквозных прогонах уровней — потому что задевает механику шире, чем собственный сценарий.

• Зацеп ПРЯМО В ПРЫЖКЕ (POP_ENABLE_JUMP_GRAB, pop_tune.h, сделан 2026-08-06, предварительно проверен пользователем). Почему нужен именно финальный прогон: точки вызова стоят не только в check_action, но и в ОБЕИХ ветках check_bumped — то есть код вклинивается перед обычным ударом о стену. Регрессия проявится не в самом зацепе, а рядом: удар о стену с зажатым Shift, осторожный шаг у стены, отскок в прыжке. На уровнях 1–3 это надо специально потрогать в паре мест каждого уровня. Напоминание: в ВАНИЛИ этого зацепа нет (у SDLPoP — enable_jump_grab), так что сверять его с оригиналом «как есть» нельзя — только с SDLPoP при включённых enhancements. Прогон 2026-08-07 (уровни 1 и 2) регрессий рядом не показал, но специально на удар о стену с Shift не проверялся.

P0 — делаем сейчас

GUARD-PHYS. Страж живёт по тем же правилам, что Кид — ЯДРО СДЕЛАНО 2026-08-07

Что уже работает (решение пользователя: переносим физику на Char, без предварительных замеров — иначе третий-четвёртый экземпляр той же логики неизбежен).

• физика переведена на Char: pop_map.c целиком работает с активным персонажем, а кто в Char — решают окна loadkid/savekid и loadshad/saveshad, как в оригинале (seg006:809). Два входа: pop_phys_tick (порт хвоста play_kid_frame) и pop_guard_phys_tick (порт play_guard_frame) — списки вызовов отличаются ровно тем, чем в оригинале;
• take_hp стал общим (pop_take_hp в резиденте pop_guard.c): урон идёт тому, кто в Char, по charid. Раньше у боёвки и у физики были свои копии, причём у физики неверная — правила hitp_curr мимо дельты и про не-Кидов не знала;
• порт веток по charid в land() (seg005:173): страж гибнет с двух рядов, тень падает как с одного, у не-Кида приземление даёт боевую стойку; check_guard_bumped (seg004:0522), droppedout + guard_follows_kid_down (seg002:09F8), check_guard_fallout (seg002:0241);
• pop_savekid_state снова полное Kid = Char, а pop_load_fram_det_col пересчитывает колонку ЛЮБОМУ персонажу — обе заплатки существовали только потому, что физика знала один Kid.

Проверено: tests-host — трассы Кида не изменились ([phys] ok: 1723, тот же эталон), новый набор t_char (32 проверки) покрывает ветки по персонажам; в MAME проверено, что игра жива (респавн, бег, падение, приземление). Цена: _CODE +80 Б, банк 3 (pop_map) 7973 → 8485 (51.8 %), банк 1 (guards) 2042 → 2156.

Проверено пользователем 2026-08-07: страж СПРЫГИВАЕТ ЗА КИДОМ на ряд ниже — связка «ИИ + физика» работает вживую, не только в тестах.

follow_guard портирован и проверен в MAME (2026-08-07): уровень 1, бой в комнате 3, Кид отступает влево — страж приходит следом (Guard.room 3 → 2, X перенесён через шов), ровно как в SDLPoP. Условия отбора покрыты тестами t_char (7 сценариев: пороги 91/165, «не бой», мёртвый, вверх/вниз, занятая соседняя комната). Сцена вскрыла отдельный баг — BUG-SWORD-GHOST-1: при переходе в бою Кид прячет меч и дальше дерётся пустой рукой.

Осталось (потому и запись открыта):

1. check_chomped_guard — вместе с L3-CHOMP;
2. ветки check_guard_fallout для тени и скелета (скелет возрождается в комнате 3) — вместе с L3-SKEL;
3. страж, нажимающий напольную кнопку, вживую не проверялся (код — общий check_press).

Почему это была ОДНА физика, а не «сделаем стражу свою». В оригинале слот Guard — не «стражи», а все НЕ-Киды: тем же play_guard_frame ходят страж (charid 2), скелет (4, ур. 3), тень (1, ур. 4/5/6/12), визирь-Джаффар (ур. 13), толстяк (FAT, ур. 12) и мышь (0x18, ур. 8) — tbl_guard_type = {0,0,0,2,0,0,1,0,0,0,0,0,4,3,−1,−1}, а autocontrol_opponent (seg002:628) разводит их ТОЛЬКО по ИИ. То есть второй экземпляр логики пришлось бы делать не один раз, а пять.

Гард по X: страж не уходит САМ — но его МОГУТ ПЕРЕНЕСТИ. Поправка к формулировке, которая была здесь раньше («страж не покидает комнату ни в каком виде») — она неверна, контрпример дал пользователь: в SDLPoP страж из комнаты 3 оказывается в комнате 2 вслед за отступающим Кидом.

Разделять надо два разных механизма:

• своим ходом — не может. Физика персонажа слота Guard обёрнута Char.room == drawn_room и Char.x >= 44 && Char.x < 211 (seg000:1252), и никакого check_leave в его списке вызовов нет. Провалившегося ниже комнаты убирает check_guard_fallout (seg002:0241) — вниз он не уходит.

• следом за Кидом — переносит движок. exit_room (seg002:03C7) вызывается ПОСЛЕ того, как комнату сменил Кид, и решает судьбу стража:

  if (Guard.alive < 0 && Guard.sword == sword_2_drawn) {      // жив и В БОЮ
      if (guards_tile[kid_room−1] >= 30 ||                    // в новой комнате
          guards_seq_hi[kid_room−1] != 0) {                   // своего живого нет
          if (ушёл ВЛЕВО)  { if (Guard.x >= 91)  leave = 1; } // страж далеко — остаётся
          else if (ВПРАВО) { if (Guard.x < 165)  leave = 1; }
          else if (ВВЕРХ)  { if (Guard.curr_row >= 0) leave = 1; }  // всегда → не идёт
          else             { if (Guard.curr_row < 3)  leave = 1; }  // вниз → не идёт
      } else leave = 1;
  } else leave = 1;
  leave ? leave_guard() : follow_guard();
  

  follow_guard (seg002:039E) стирает guards_tile в ОБЕИХ комнатах (0xFF — «стража здесь нет», чтобы он не раздвоился) и гонит стража через goto_other_room в окне loadshad/saveshad.

Что это значит для нас. У нас в enter_room (roomtest.c:265) стоит безусловный pop_guard_leave() — то есть всегда ветка leave_guard, и страж ВСЕГДА остаётся. Портировать надо сам exit_room-выбор: условия «жив + меч вынут + в целевой комнате нет своего стража + он у нужного края» и follow_guard. Пороги 91/165 — это «страж у того края, в который ушёл Кид»; вверх и вниз оригинал не пускает никогда.

Чем подтверждать: уровень 1, комната 3 — начать бой, отступить влево в комнату 2: страж обязан прийти следом и продолжить бой (как в SDLPoP на скриншотах пользователя). Обратная проверка: если в соседней комнате СВОЙ живой страж — переход не происходит.

L3-CHOMP. Чомперы — механика уровня 3

Где: 5 штук, комнаты 5(тайл 4), 16(23,24,25), 22(26). Дальше они почти на каждом уровне, так что это вложение не только в ур. 3.

Что портировать: animate_chomper (seg007) — состояние в room_modif, как у пик/ворот, значит шаблон уже отработан (gates_spikes_plan.md); коллизия и смерть Кида в сомкнутых челюстях (seg004/seg006); отрисовка кадра по модификатору (draw_tile_anim, ветка tiles_18_chomper).

Место в банке 2 расчищено (MEM-BANK2, 2026-08-08): 35.8 %, свободно 10 512 Б (было 1074 Б) — холодная половина слоя фона уехала в банк 7 (pop_room.c). Считать место ДО кодинга всё равно обязательно (levels_plan.md §5.1); чомпер — это анимация тайла (холодная перерисовка), поэтому его отрисовка ложится в pop_room.c, а состояние — в room_modif, как у пик и ворот.

Ассеты УЖЕ упакованы (2026-08-07): pop_pack_bg.py кладёт в атлас весь набор кадров чомпера явно (CHOMPER_BOT_IDS 101-105, CHOMPER_TOP_IDS 111-113, CHOMPER_FORE_IDS 106-110 + кровь 114-123 mono-силуэтом цветом 12). Раньше в атласе не было НИ ОДНОГО его кадра: render_room.py пропускает анимированные тайлы, а tile_table[0x12].base_id = 0 — отсюда и «чомпера не видно вовсе». Рост: pop_env3.atl 5200 -> 12937 Б, pop_fore.atl 7763 -> 12359 Б, число EMM-страниц НЕ изменилось (7).

Чем подтверждать: комната 22 уровня 3 — чомпер (2,6) анимируется и рисуется (сейчас его не видно вовсе, см. раздел «Уровень 3» в bug_list.md); смерть Кида в сомкнутых челюстях.

L3-SKEL. Скелет — единственный противник уровня 3

Важно: в данных уровня 3 стражей нет вообще (guards_tile пуст во всех 24 комнатах). Единственный враг — скелет, и он не «страж из данных», а спецсобытие check_skel (seg002:1044):

в комнате 1, когда Kid.curr_col == 2 или 3 и дверь уровня открыта, тайл tiles_21_skeleton (комната 1, тайлпос 15) стирается в пол, а на его месте поднимается персонаж: charid_4_skeleton, меч сразу вынут, seq_88_skel_wake_up, skill 2, HP 3.

Ещё два тайла скелета (комнаты 17 и 19) — декорация, они не оживают.

Сделано 2026-08-07 (ждёт живой проверки на уровне 3):

• атлас скелета — pop_pack_guard.py SKEL собирает poc/res/skel/g0..g3.atl (28 кадров, 30 КБ, 4 EMM-страницы); упаковщик получил параметр набора (GUARD/SKEL). Палитра у скелета СВОЯ (SKEL/res750.pal), а не из res10.bin: на уровне 3 tbl_guard_type != 0, значит curr_guard_color = 0 и оригинал палитру не подменяет вовсе;
• pop_guard_load выбирает набор по типу уровня и заливает палитру скелета; Makefile кладёт атласы в SKEL\ на диск;
• check_skel (seg002:1042) — порт в guards.c: уровень 3, комната 1, дверь уровня открыта, Kid.curr_col 2 или 3, тайл 21 на (5,1) → тайл стирается в пол (обе страницы), персонаж встаёт с seq_88_skel_wake_up, мечом наголо, skill 2, HP 3. Зовётся из главного цикла ДО логики персонажей, как в play_frame;
• leveldoor_open — флаг появился (pop_state.c), взводит анимация двери при modif >= 43 (seg007:456);
• enter_guard — ветка charid_4_skeleton: встаёт сразу активным (меч вынут), а не в стойке покоя;
• возрождение — check_guard_fallout: упавший скелет, под комнатой которого лежит комната 3, появляется там снова (x 133, ряд 1);
• ИИ — autocontrol_skeleton (seg002:685): меч у скелета вынут всегда.

Регресс: tests-host зелёные, t_char вырос до 65 проверок (добавлены два сценария возрождения). Цена: _CODE +80 Б, банк 1 (guards) 2342 → 2519, банк 4 (gdraw) 3875 → 4269.

Не проверено вживую: сцена требует пройти уровень 3 до кнопки, которая открывает выход — без открытой двери скелет по условию не встаёт.

Что нужно:

• charid_4_skeleton в enter_guard/pop_guard_enter (seg002:196): при tbl_guard_type[level] == 2 персонаж поднимается с вынутым мечом и последовательностью seq_63_guard_active_after_fall, а не seq_77_guard_stand_inactive;
• скелет бессмертен — чит K его уже не берёт (pop_guard_kill проверяет CHARID_4_SKELETON), но и боёвка должна возвращать его к жизни (seg002:252);
• новый атлас: ../SDLPoP/data/SKEL/ (29 файлов) — pop_pack_guard.py сейчас прибит к GUARD/, нужен параметр набора (tbl_guard_dat = GUARD/FAT/SKEL/VIZIER/SHADOW). Здесь же удобно закрыть BUG-GUARD-COLOR-1: палитра стража подменяется по guards_color, и оба изменения живут в одном упаковщике.

L3-COLOR. Палитра КЛАДКИ уровня 3 (в оригинале он зелёный)

Наблюдение (пользователь, 2026-08-07, со сравнением карт VGA). В оригинальной VGA-версии кладка уровня 3 ЗЕЛЁНАЯ, а уровней 1-2 — серо-синяя. В SDLPoP все подземелья одинаковые, поэтому по нему разницу не увидеть.

Почему в SDLPoP её нет — проверено, не гипотеза. Механизм там ЕСТЬ (seg000:1140, «Level colors (1.3)»):

int level_color = custom->tbl_level_color[current_level];
if (level_color != 0) {
    byte* env_pal  = level_var_palettes + 0x30*(level_color-1);
    byte* wall_pal = env_pal + 0x30 * custom->tbl_level_type[current_level];
    set_pal_arr(0x50, 0x10, (rgb_type*)env_pal);    /* chtab_6 environment */
    set_pal_arr(0x60, 0x10, (rgb_type*)wall_pal);   /* chtab_7 wall        */
}

tbl_level_color (data.h:842) = {0,0,0,1,0,0,0,1,2,2,0,0,3,3,4,0} — у уровня 3 цвет 1, у 7 тоже 1, у 8/9 — 2, у 12/13 — 3, у 14 — 4. Но level_var_palettes — это ресурс 20 из PRINCE.DAT (только версии 1.3/1.4), а в SDLPoP/data/PRINCE/ его НЕТ: там лежит лишь res10.bin (палитры стражей). Значит level_var_palettes == NULL и вся ветка молча пропускается — отсюда одинаковые подземелья.

Данные у нас есть. В ../MSDOS/PRINCE.DAT ресурс 20 присутствует: offset 22790, 240 байт = 5 палитр × 16 цветов × 3 байта (6-битные каналы, как res10).

Что делать (когда дойдём до вида уровня 3).

1. Достать ресурс 20 из MSDOS/PRINCE.DAT (упаковщику придётся читать сам .DAT — сейчас все скрипты берут распакованные PNG из SDLPoP);
2. сгенерировать таблицу палитр рядом с pop_guard_pal.h;
3. при загрузке уровня заливать слоты 0x50..0x5F (env) и 0x60..0x6F (wall) — у нас ровно эти базы (pop_pack_bg.load_indexed: pal_base = 0x60 для WALL, 0x50 для env), то есть совпадение со set_pal_arr один в один;
4. wall_pal = env_pal + 0x30 * tbl_level_type[level] — для подземелья (level_type == 0) обе палитры одинаковые.

Грабли, уже пойманные на цвете стражей: gfx_pal_load отдаёт указатель в BIOS ($A4 через rst #0x08), а BIOS читает только #4000-#BFFF — таблицу нельзя передавать прямо из банка (0xC000+), надо копировать в W1/W2 (см. BUG-GUARD-COLOR-1).

DRAW-COST. Кадр НЕ УКЛАДЫВАЕТСЯ в бюджет — нужна оптимизация

ШАГ 1 СДЕЛАН 2026-08-08: пропуск неизменившегося персонажа. Комната 1.3, труп стража, Кид стоит: было 210 % кадрового периода, стало 116 % (500 772 такта при бюджете 430 000). Отрисовка перестала быть узким местом: персонажи в покое не рисуются ВООБЩЕ (ноль вызовов pop_heal_fast за кадр), весь фон — ДВА блита факелов (44 136 тактов). Механизм и почему метка позиционная — в шапке pop_cdraw.h.

Исходные замеры пользователя (полосы бордюра, до шага 1). Уровень 1, Кид СТОИТ — то есть НЕ худший случай, ни боя, ни движения:

комната	синяя (ввод+heal+логика)	зелёная (фон)	циан (спрайты)	итого
3, страж УБИТ	~80 %	~20 %	~110 %	~210 %
2, стража НЕТ	~60 %	~20 %	~60 %	~140 %

Разница ровно в теле убитого стража: +20 % синей и +50 % циана. Труп сохраняет charid != 0, поэтому каждый кадр честно проходил весь путь живого персонажа (heal → спрайт+clip_char+брызги+клинок → fore-проход), хотя его кадр постоянен до выхода из комнаты.

Что сделано (шаг 1). Не спецкейс «мёртвый», а общее правило: у каждой страницы дабл-буфера свой снимок ВХОДОВ отрисовки слота; совпал снимок, спрайт этой страницы цел и фон в его прямоугольнике не трогали — heal, блит и fore-проход пропускаются целиком. Покрывает и труп, и стоящего Кида, и ждущего стража. Детали контракта — pop_cdraw.h, реализация — pop_char_skip_mask / cd_quiet в pop_cdraw.c, метка фона — pop_cd_touch в резидентном pop_tile.c.

Грабли, на которые наступили по дороге: сначала метка была ФЛАГОМ «фон трогали хоть где-то» — и выигрыш оказался ровно нулевым, потому что факелы анимируются каждый кадр и гасили пропуск для всех персонажей сразу (замер: 597 684 такта, как без оптимизации). Метка обязана быть ПОЗИЦИОННОЙ.

Остаточный эффект от объединения прямоугольников. Метка одна на страницу — объединение всех правок фона. В комнате 1 два факела дают прямоугольник x 40…88, а стоящий там Кид занимает x 32…44: пересечение 4 px, и он перерисовывается каждый кадр (140 % против 94 %, если отойти). Если понадобится — держать не один прямоугольник, а 3-4 отдельных и мержить только при переполнении.

Шаг 2 сделан частично: ЛОГИКА (синяя полоса) 2026-08-09

Пользователь: «на стоящем Киде с двумя факелами на логику уходит 60 % кадрового периода — недопустимо». Разобрано брейкпоинтами в MAME (z80_profiling_method), сцена: уровень 1 комната 1, Кид СТОИТ вплотную к левому факелу (то есть пропуск персонажа НЕ срабатывает — худший случай).

Калибровка, которую надо знать заранее. Один такт totalcycles в MAME — НЕ один номинальный T-такт Z80: у Sprinter на обращениях к ОЗУ есть wait-state'ы, и замеренная стоимость выходит ≈ 2,4× номинала (get_tile: 574 номинальных против 1 422 замеренных). Считать бюджет по таблице T-тактов из справочника нельзя — только мерить. Кадр растра = 430 000; главный цикл спейсится тремя gfx_wait_vsync, поэтому работа СВЫШЕ 430 000 стоит сразу целый лишний кадр.

Что нашли и починили:

правка	что было	стало
окно перебора коллизии как в оригинале (было: все 14 колонок каждый кадр)	check_collisions 60 888	50 940
get_tile_div_mod — таблицей (tile_div_tbl/tile_mod_tbl), было /14 и %14	5 400 тактов на вызов, 13 вызовов за кадр ≈ 70 000 = 16 % кадра	~250 на вызов
разрешение ряда вынесено из цикла колонок + грань шагом 14 + wall_type таблицей	check_collisions 58 026	42 750
move_coll_to_prev — memcpy (LDIR) вместо цикла на C	14 байт за 5 514 тактов (390 на байт!)	~1 200
окно режется на непрерывные пробеги (левый сосед / своя / правый), пролог ряда вынесен на кадр	check_collisions 44 022	38 334

Замер одной итерации перебора: пустая колонка 750 тактов, колонка-стена ~1 700 (две 16-битные знаковые сверки граней — SDCC пишет их через jp PO / xor 0x80 / jp P). Ловушка, на которую наступили: «быстрый путь для окна внутри комнаты» не срабатывал ПОЧТИ НИКОГДА — Кид, стоящий в колонке 0, даёт окно с −1, и шёл медленный сбор во временный буфер с тернарником на колонку (1 340 тактов на колонку). Отсюда разбиение на пробеги: вопрос «чья это колонка» решается раз на пробег, а coll_scan сам двигает scan_left.

Самое дорогое было НЕ там, где ожидалось: /14 и %14 SDCC разворачивает в __divsint + __modsint, а __modsint внутри зовёт __divsint ещё раз — два полноценных 16-битных деления на каждый вопрос «в какой колонке точка». Оригинал делит таблицей (seg006:702) — мы просто не портировали это место.

ГЛАВНОЕ: логический кадр уложился в бюджет. Главный цикл спейсится тремя gfx_wait_vsync, поэтому работа сверх 430 000 тактов стоит СРАЗУ целый лишний растровый кадр. Было 470 964 (период цикла 4 кадра), стало 409 956 + ~15 600 на ввод = 425 600 — период цикла 3 растровых кадра. Игра стала быстрее на треть (16,7 логических кадров/с против 12,5).

Что дало последние тысячи (по убыванию):

правка	экономия
pop_y_to_row — цепочка сравнений вместо /63 % 4	~12 000
расширение окна fore-прохода арифметикой вместо перебора 10 колонок и 3 рядов	~8 500
col_from_x — таблицей (те же POP_TILE_DIV, вынесены в резидент)	~11 000
pop_cd_touch — развёрнутый цикл по страницам, x+w/y+h один раз	~8 600 (зовётся с каждого блита фона)
tp / 10, tp % 10 у факелов — таблицей	~4 000
пустой слот соперника считается «тихим»	~8 200

Ловушка SDCC, на которой я потерял один прогон: в pop_y_to_row одно и то же выражение t / 63 % 4 - 1 стояло в двух ветках, и компилятор поднял деление В ВЕРШИНУ функции — быстрые возвраты не спасали, __divsint звался всё равно. Лечится выносом медленного хвоста в ОТДЕЛЬНУЮ функцию. Тот же эффект уже был описан в pop_loose_tick; теперь ясно, что это правило, а не частный случай: любое деление, встречающееся дважды, SDCC поднимает выше всех проверок.

Приём, которым это ловится: брейкпоинт на __divsint/__divuint/ __divuchar с печатью адреса возврата (printf "%04X", w@(sp)) — сразу видно, кто и сколько раз делит за кадр.

Профиль работы за логический кадр СЕЙЧАС (409 956 тактов + ~15 600 ввод):

блок	тактов	% растрового кадра
see_kid + ctrl_tick + skip + heal + kid_tick	52 536	12
физика Кида + страж + боёвка	73 452	17
pop_loose_tick	27 438	6,4
pop_process_trobs (два факела)	75 720	17,6
pop_redraw_needed + шов + skip_mask	10 932	2,5
pop_char_draw Кида	56 250	13
pop_char_fore Кида + борта	113 628	26

Синяя полоса (ввод + логика) была ~60 % → стала ~29 %.

Оптимизация закрыта по решению пользователя 2026-08-10. Всё, что осталось неcделанным, вынесено с замерами в ../docs/perf_backlog.md — там же протокол «как мерить», чтобы не наступать заново на wait-state'ы и на устаревшие адреса символов. Что доделано после таблицы выше: pop_cd_touch развёрнут, tp/10 у факелов таблицей, пустой слот соперника считается тихим, ранний выход в fore-проходе (нулевой эффект, оставлен как порт), быстрый путь без клипа в pop_blit_b (факел 41 778 -> 31 218 тактов).

Что осталось (запас на будущее, срочности больше нет):

1. pop_char_fore 113 628. Внутри: char_footprint + расширение окна ~21 000, дальше шесть fore_tile, из которых два реально рисуют (по ~32 000). Дальше резать — кэш «в этом тайле переднего слоя нет вовсе».
2. pop_process_trobs 75 720 на два факела (~31 000 на факел). Внутри одного факела: gfx_blit_noclip 8 700, чтение w/h и клип 6 400, pop_cd_touch (теперь дешевле), маппинг окна 0 и возвраты. Пламя перерисовывается каждый кадр обязательно (TORCH_ANIM_DIV = 1, кадр меняется), так что пропуск тут не поможет — только удешевление блита.
3. pop_loose_tick 27 438 при полном отсутствии падающих плит.
4. Одно __divsint осталось в pop_char_draw (obj_x * 8 / 7) — ~2 400.

Шаг 2 (СЛЕДУЮЩИЙ, назначен пользователем): ДВИЖУЩИЙСЯ Кид

Пропуск закрывает только покой. Наблюдение пользователя 2026-08-08: как только Кид побежал, циан-полоса (спрайт + fore-проход) вырастает почти до 100 % кадрового периода — и это на ОДНОГО персонажа. То есть цена одной перерисовки персонажа сама по себе непозволительно велика, и её надо резать по существу, а не пропусками.

Куда смотреть (мерить каждое, метод — z80_profiling_method):

1. разделить замером спрайт-блит и fore-проход: у fore уже была история 78 % кадра до кэша кладки (pop_fore_layer_cost), он и сейчас главный подозреваемый;
2. fore-проход перебирает 2×2…3 тайла и в каждом разбирает кладку заново — кэш «в этом тайле переднего слоя нет вовсе» снял бы половину;
3. расширять перебор ТОЛЬКО по накладным спрайтам (клинок/брызги), а не по всему окну клипа: габарит кадра уже покрыт футпринтом + правилом меча;
4. heal + блит спрайта: сейчас это два прохода по одной площади; посмотреть, нельзя ли стирать только РАЗНОСТЬ прямоугольников при мелком сдвиге.

Куда идти дальше в ПОКОЕ — там это ЛОГИКА, а не отрисовка. Разбивка работы кадра брейкпоинтами (комната 3, труп, Кид стоит; всего 500 772 такта):

участок	тактов	% кадра
ввод + check_skel + луч видимости + ctrl_tick + heal	65 862	15 %
kid_tick + физика + страж + боёвка	260 022	60 %
loose_tick + process_trobs	119 562	28 %
redraw_needed + шов + спрайты + метка	55 152	13 %
— из них два блита факелов	44 136	10 %

1. 60 % на тик персонажей при том, что оба СТОЯТ — первый кандидат. Смотреть pop_phys_tick/pop_guard_phys_tick (банк 3) и pop_guard_tick (банк 1): сколько там работы, которую неподвижный персонаж делать не обязан, и сколько стоит трамплин на каждом шаге.
2. 28 % на loose_tick + process_trobs в комнате БЕЗ единой ловушки — явно перебор; разобрать, что там сканируется каждый кадр (список trob, pop_trob_modif соседа для шва, pop_room_link).
3. Запечь труп в фон (как щебень: тело в фоне + fore-часть поверх Кида) — тогда бесплатным станет и проход Кида ПО телу, который сейчас снимает пропуск по правилу «слоты рядом». Предложено пользователем 2026-08-08.

Мерить в ЭТОЙ точке (комната 3, страж убит, Кид стоит) — она воспроизводима и даёт нижнюю границу; худший случай (бой + бег + падающая плита) считать отдельно. Метод — memory z80_profiling_method (брейкпоинты с totalcycles); полосы бордюра показывают только одну картинку из периода и годятся лишь для раскладки по фазам.

Наблюдение пользователя на приёмке DRAW-CHAR 2026-08-08: циан-полоса профиля (спрайты + fore) выросла — тогда «в пределах».

Отчего именно. Раньше перебор тайлов у Кида шёл строго по футпринту кадра (char_x_left/right, seg006:1021), а он УЖЕ спрайта; расширение перебора окном спрайта (клинок и брызги уходят за габарит кадра) было только у соперника. DRAW-CHAR сделала его общим — то есть у Кида теперь на колонку-другую больше fore_tile за кадр. Это не регрессия «лишней работы», а недостающая ранее корректность: тайл, который спрайт задевает, обязан вернуть свой передний слой поверх него.

Если fore-проход снова станет узким местом (сейчас он в покое не выполняется вовсе): расширять перебор ТОЛЬКО по накладным спрайтам (клинок/брызги), а не по всему окну; кэш «в этом тайле fore-слоя нет вовсе»; считать окно клипа в тайловых координатах один раз.

DRAW-CHAR — ЗАКРЫТА И ПРОВЕРЕНА 2026-08-08

Отрисовка сведена к одному набору функций над Char (pop_cdraw.c), проход окклюзии — один на всех (pop_fore_over_char). Разбор, таблица «было → стало», пять починенных расхождений и замеры — в TASKS_CLOSED.md. Оттуда же список того, что надо потрогать вживую при приёмке уровней.

L3-PASS. Приёмка уровня 3 — обход всех комнат

Как L1-PASS/L2-PASS: сквозной проход руками плюс обход комнат читом ROOMNAV. Осмысленна ТОЛЬКО после L3-CHOMP и L3-SKEL — без них уровень заведомо неполон, и половина наблюдений будет «механики нет».

Что уже снято и пригодится (справка ниже): комнаты 23 и 24 недостижимы и полностью пусты — баги в них не в приоритете; чекпойнт уровня 3 сделан (L3-CHKP), его тоже надо потрогать вживую: уйти влево из комнаты 7, умереть, проверить респавн в комнате 2 и снятую loose-плиту (7, кол 4, ряд 0).

Справка: связность комнат уровней 1–3 (снято 2026-08-05)

Обход графа roomlinks (@1952, по 4 байта на комнату: L, R, U, D; 0 = нет соседа) от стартовой комнаты — тем же методом, которым на уровне 1 нашлись 13/18/24 (см. «НЕ БАГИ» в bug_closed.md). Скрипт разовый, в репозиторий не клался: чтение трёх массивов, BFS и проверка симметрии.

уровень	старт	недостижимы	признак
1	к.1 (0,0)	13, 18, 24	ссылки наружу есть, обратных нет
2	к.5 (1,3)	нет	граф полностью симметричен, все 24 достижимы
3	к.9 (2,4)	23, 24	то же, что на 1: односторонние ссылки, обе комнаты полностью пустые

ур.3:  23 L→4,  у 4  R=22   |  24 L→2,  у 2  R=7
       23 R→22, у 22 L=4    |  24 R→7,  у 7  L=2
                            |  24 U→16, у 16 D=0
       на 23 ссылается только 24, на 24 — только 23; тайлы обеих = все empty

То есть на уровне 3 это даже более чистый случай, чем на уровне 1: там в брошенных комнатах была геометрия, здесь — пустота. Практический вывод тот же: в 23/24 возможен «мусор в шве» (наш рендер кромки читает крайнюю колонку соседа ПО ССЫЛКЕ, а сосед соседом себя не считает), приоритет багов там низкий, в игре их не видно.

Уровень 2 — недостижимых нет, но есть три КОЛОДЦА без выхода (единственная связь — вверх, откуда Кид падает):

к.10  U→4    пики(2,2) + пол — падение из комнаты 4
к.14  U→21   шахта 2 тайла шириной, дно = обломки
к.17  U→15   то же

Это не баги данных: в 14/17 попадают только падением насмерть, а из 10 (если выжил) выхода нет вовсе — так в оригинале. При приёмке не считать «застрял» багом.

---

P1 — берётся в любой момент

L1-SPEED. Игра идёт быстрее оригинала (найдено 2026-08-01)

Сверка таймингов: оригинал — BASE_FPS = 60 при base_speed = 5 тиков на логический кадр (SDLPoP/src/types.h:1373, data.h:869) = 83.3 мс, в бою fight_speed = 6 = 100 мс. У нас roomtest.c ждёт три gfx_wait_vsync() = 60 мс, и отдельной скорости боя нет — то есть примерно +39 % к скорости эталона. Соответствие: 4 ожидания (80 мс) обычно, 5 (100 мс) в бою. Условие «делать ПОСЛЕ CLIP-1» снято — CLIP-1 закрыт. Проверка — секундомером по одинаковому отрезку рядом с живым SDLPoP, не «на глаз».

TUNE-1. Параметры движка — в конфиг, а не в код

Что уже есть. pop_tune.h — все настраиваемые числа собраны в одном заголовке: чекпойнт уровня 3 (POP_CHKP_*), отладочное окно решётки (POP_DBG_GATE_HOLD), включатель зацепа в прыжке (POP_ENABLE_JUMP_GRAB). Правило уже действует: новое «особое событие» или тайминг заводится ТАМ, а не константой по месту.

Что нужно сделать. Читать их из ФАЙЛА рядом с exe, чтобы менять без пересборки — под отладку («растянуть решётку, чтобы успеть пройти») и под моды. Формат: простой ini/ключ=значение, парсер на ~50 строк (числа, комментарии ;, неизвестные ключи игнорировать), файл необязателен — нет файла, значит зашитые дефолты. Секции по смыслу: [level], [debug], [enhancements].

Ориентир — SDLPoP. У него это custom_options_type (types.h) + SDLPoP.ini + меню Settings/Mods; наши имена намеренно совпадают с его (custom->имя), чтобы сверка оставалась механической. Осмотр его меню и опций — часть задачи: у него уже разложены по группам стартовые HP/минуты, номера «особых» комнат и уровней (шадоу, скелет, зеркало, чекпойнт), тайминги ворот и пик, скорости, а отдельной группой — fixes/enhancements (включая enable_jump_grab, который мы уже портировали). Брать всё подряд не надо: переносим по мере того, как константа реально понадобилась в игре.

Оговорка по памяти. Парсер и таблица параметров — холодный код, исполняется один раз при старте: кандидат в банк, а не в резидент W1.

MEM. Следующий шаг разгрузки W1/W2

pop_ctrl.c уехал в банк 5 (MEM-BANK5, куча 180 Б → 2298 Б; после снижения --max-allocs — 2751 Б). Следующий кандидат по тому же критерию (не размер, а частота вызова и отсутствие горячих банк→банк переходов) — расщепление pop_kid.c: холодная половина (загрузка страниц спрайтов, pop_kid_load) в банк, движок кадров (load_frame/play_seq, 2×/кадр) оставить в резиденте.

Брать по факту нехватки места, не заранее. Таблица резидентного кода по модулям и разбор, почему pop_level.c в банк НЕЛЬЗЯ, — в TASKS_CLOSED.md.

---

Отложено осознанно (не брать, пока не появится причина)

• KBD-1, остаток — «иногда при зажатом Shift стрелка всё-таки пропускается» (ощущение пользователя, не замер: счётчики на 35 нажатиях подряд потерь не показывают). Решение пользователя 2026-08-01: отложено до финальной полировки. Где именно осталась дыра и что делать, если вернёмся, — в TASKS_CLOSED.md (там же весь протокол замеров и список того, что делать НЕЛЬЗЯ).
• Quickload (Shift+F9) и остальные читы SDLPoP — оценка сделана (DBG-CHEATS), код не написан. Самое ценное и самое дорогое: сериализация Char + room_modif всех комнат + trob'ов + стражей (levels_plan.md §4), зато даёт воспроизводимый регресс «вот кадр, где баг» вместо ручной подгонки позы.
• Звук (CBL-эффекты, Фаза 5 PORT_PLAN.md) — геймплей не блокирует.
• Таймер уровня / HUD времени / меню / сохранения — Фаза 6.
• T-1 (пики: перерисовка по причине) — отдаётся почти бесплатно после T-2, отдельно не окупается.
• Отключение мыши на время игры и замена PRNG — ../docs/ideas_backlog.md (оба дают доли процента кадра).
• OPT-1 (хирургический редрой шва) — решено НЕ делать, стоимость транзиентная; разбор в bug_closed.md.