L2: падение с мечом, разбег-прыжок через 3 тайла, стартовое состояние ворот
BUG-FALL-SWORD-1 — start_fall (seg006:1044) был портирован не целиком: не хватало трёх веток выбора последовательности и уборки меча в ножны. Из-за seq_7 с set_fall(1,15) (дрейф 1 px/кадр) Кид с мечом уезжал примерно на тайл вбок; в оригинале это seq_81_fightfall — падение строго вниз. Сверено по логу SDLPoP: кадры 102..105 дают x = 155,157,159,160. BUG-RJUMP-1 — run_jump (seg005:0AA8) не выравнивал Кида по кромке пола перед толчком, а был заглушкой «полировка K3». Суммарный dx seq_4 — 62 px при тайле 14, то есть провал ровно в три тайла берётся ТОЛЬКО с кромки: без выравнивания Кид не перепрыгивал его никогда. Порт — pop_run_jump_align() в pop_map (беззнаковое сравнение оригинала = «сдвиг не попал в [-8,-1]»). На харнессе: было — толчок с x=165, кадр 44 в колонке 3 (провал); стало — 5 кадров добега, толчок с x=149, кадр 44 даёт x=87 col=1 row=1. Остальные 8 сценариев не изменились. BUG-GATEMOD-1 — load_alter_mod (seg008:198E) был портирован только для зелий, поэтому ворота с bg=1 («Open» по спецификации DAT, табл. 8) стартовали закрытыми. Добавлены ветки gate (1 -> 188) и loose. Ветка wall намеренно НЕ портируется: связи стен наш pop_bg считает по типам соседей в момент отрисовки. На уровнях 1-3 таких ворот всего двое (ур. 1 комн. 5 (0,9); ур. 2 комн. 13 (1,5)) — у остальных bg=2, а 2 и 0 ведут себя одинаково. Убран временный трассировщик pop_dbg_trace/pop_dbg_draw; pop_dbg_trap() оставлен как многоразовый инструмент. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This commit is contained in:
Александр Петров
@@ -45,6 +45,7 @@
|
||||
| — | [L1-SPEED](#l1-speed) | игра на ~39 % быстрее оригинала | ощущение от ВСЕХ уровней; берётся в любой момент |
|
||||
| — | [L1-PASS](#l1-pass) | сквозной прогон ур. 1 + таблица 24 комнат | приёмка ур. 1 |
|
||||
| — | [DBG-CHEATS](#dbg-cheats) | `[`/`]` — подгонка Кида по X | отладка (BUG-GATE-PASS-1) |
|
||||
| — | [MEM-BANK5](#mem-bank5) | новый банк кода: W1/W2 осталось 38 Б кучи | берётся по факту нехватки места |
|
||||
|
||||
---
|
||||
|
||||
@@ -154,6 +155,17 @@ loose-плиту (комната 7, колонка 4, ряд 0). Механик
|
||||
|
||||
### KBD-1. Shift + стрелки: нажатия теряются — **ПРИЧИНА НАЙДЕНА, ФИКС ПРОВЕРЕН**
|
||||
|
||||
> **ПОПРАВКА К ПОСЫЛКЕ (2026-08-05).** Ниже «fake shift» подан как
|
||||
> установленный факт («при зажатом Shift PS/2 удваивает трафик»). Прямой
|
||||
> замер потока байт это не подтвердил: клавиатура MAME-Sprinter
|
||||
> (`pc_kbd ms_naturl`) обёртку `E0 F0 12` / `E0 12` не шлёт вовсе — при
|
||||
> зажатом Shift поток на стрелку ровно `E0 75 E0 75 …`. Значит удвоения
|
||||
> трафика в связке Shift+стрелка нет, и мотивировка «поэтому FIFO
|
||||
> переполняется» отпадает; сам ФИКС (плотный опрос `kbd_raw_poll`) остаётся
|
||||
> верным и нужным — переполнение вызывает не Shift, а короткая жизнь
|
||||
> импульса IRQ (пункт 3 гипотезы) плюс DI-окна графики. Разбор и следствия
|
||||
> — [BUG-KBD-5](bug_closed.md#bug-kbd-5).
|
||||
>
|
||||
> **Итог (2026-08-01).** Причина — не наш код и не DI-окна графики: при
|
||||
> зажатом Shift PS/2 удваивает трафик («fake shift»), а импульс запроса
|
||||
> прерывания здесь теряется примерно в 44 % случаев, и трёхбайтовый FIFO
|
||||
@@ -659,6 +671,47 @@ Shift+L → уровень 3 (комната 9). То есть цепочка
|
||||
|
||||
---
|
||||
|
||||
### <a id="mem-bank5"></a>MEM-BANK5. Разгрузка W1/W2 новым банком кода
|
||||
|
||||
Вопрос 2026-08-04: «надо делать новый банк?». **Да, и он лечит именно то,
|
||||
что жмёт.** В нашей раскладке (`MEMORY=huge`, small-вариант) CODE и DATA
|
||||
живут в ОДНОМ 32-КБ пространстве W1+W2 — карта текущей сборки:
|
||||
|
||||
```
|
||||
_CODE 0x4100..0xAA00 26880 Б
|
||||
_DATA 0xAAD0..0xB9B0 3808 Б
|
||||
_BSS 0xB9B8..0xBADA 290 Б
|
||||
куча 0xBADA..0xBB00 38 Б ← упёрлись сюда, добавляя отладку
|
||||
стек 0xBB00..0xC000 1280 Б
|
||||
```
|
||||
|
||||
Поэтому **каждый килобайт кода, уехавший в банк, становится килобайтом,
|
||||
доступным данным**. Отдельного «дефицита W2» у нас нет — дефицит один.
|
||||
(38 байт кучи не опасны сами по себе: malloc'ом мы не пользуемся, страницы
|
||||
берутся через `mem_alloc_block`. Опасно то, что следующая структура
|
||||
данных упрётся в стек молча.)
|
||||
|
||||
Резидентный код по модулям (из `.sprinter-cc-roomtest/*.rel`):
|
||||
|
||||
| модуль | _CODE | как часто зовётся | в банк? |
|
||||
|--------|------:|-------------------|---------|
|
||||
| `pop_kid.c` | 6287 | `load_frame`/`play_seq` — 2×/кадр (Кид + страж) | частично: холодная половина (загрузка страниц спрайтов, `pop_kid_load`) — да; движок кадров — нет |
|
||||
| `roomtest.c` | 3893 | main-loop | нет (точка входа, зовёт всех) |
|
||||
| `pop_trob.c` | 2526 | `do_trobs` 1×/кадр, но `pop_trob_modif` — горячий аксессор | **кандидат №1**, если вынести аксессор в резидент |
|
||||
| `pop_level.c`| 2292 | `pop_level_tile` — из `pop_bg` (банк 2) на каждый тайл | **нет**: банк→банк на каждый тайл убьёт отрисовку |
|
||||
| `pop_ctrl.c` | 2189 | `user_control` 1×/кадр | **кандидат №2** — дёшево и безопасно |
|
||||
| `pop_guard.c`| 923 | 1×/кадр | нет смысла |
|
||||
|
||||
Порядок действий, когда упрёмся: `pop_ctrl.c` → банк 5 (2.2 КБ, один
|
||||
banked-вызов за кадр), затем расщепление `pop_kid.c` на горячее ядро и
|
||||
холодную загрузку. Критерий кандидата — **не размер, а частота вызова и
|
||||
отсутствие горячих банк→банк переходов**; `pop_level` показывает, что
|
||||
большой холодный на вид модуль может быть горячим аксессором.
|
||||
|
||||
Брать по факту нехватки места, не заранее.
|
||||
|
||||
---
|
||||
|
||||
## Отложено осознанно (не брать, пока не появится причина)
|
||||
|
||||
- **Звук** (CBL-эффекты, Фаза 5 `PORT_PLAN.md`) — геймплей не блокирует.
|
||||
|
||||
Reference in New Issue
Block a user