Files
Sprinter-SDCC/applications/SprPoP/docs/vanilla_vs_bugfixed.md
T
snark13 90e304f071 SprPoP: тесты стены + задача VANILLA/BUGFIXED, находка 24 отложена
КОД ИГРЫ НЕ МЕНЯЛСЯ — правка находки 24 сделана и откачена.

ТЕСТЫ.  Набор t_wall вырос с одной проверки до трёх: добавлены проверка
X на каждом кадре падения (персонаж не должен оказываться внутри кладки)
и симметричный прыжок через провал с другой стороны.

Ключевое в них — форма ожидания.  Тест НЕ требует нуля заходов в кладку,
а сторожит их ЧИСЛО: сейчас ровно два случая из четырнадцати стартовых
позиций.  Это ванильное поведение оригинала, для которого SDLPoP держит
отдельное опциональное исправление; больше двух — значит правка сделала
нас хуже ванили, меньше — значит фикс кем-то портирован.  То есть тест
сразу готов обслуживать оба будущих режима.

По дороге тест дважды ловил не баг движка, а мою ошибку в самой сцене
(старт в пустой клетке; перелёт через площадку считался нарушением).
Оба раза чинился тест, а не движок.

НАХОДКА 24 ОТЛОЖЕНА.  Перезагрузка кадра в in_wall верна по букве
оригинала, но эффекта показать не удалось: все 15 наборов host-тестов
дают одинаковый результат до и после.  При этом правка не бесплатна —
маппинг окна и перезагрузка кадра на каждое выталкивание.  Платить за
недоказанное не стали.

НОВАЯ ЗАДАЧА: docs/vanilla_vs_bugfixed.md — поддержка двух поведений,
ванильного и с багфиксами.  Туда переехали находка 24, три опциональных
фикса SDLPoP (скольжение сквозь стену, прыжок над воротами, гобелен) и
готовый детектор из t_wall.  Открытые вопросы записаны: чем переключать
(возможно, объединить с уже существующим VANILLA/ENHANCED), цена
рантайм-проверки в горячем пути, что считать умолчанием, как гонять
тесты в двух режимах.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_011MsUsEFAQfsjjQpJ7RtKVY
2026-08-31 20:13:25 +03:00

6.2 KiB

Два поведения: VANILLA и BUGFIXED

Заведено 2026-08-31. Задача поставлена, работа НЕ начата.

Зачем

У оригинального PoP есть баги, которые игроки знают наизусть и на которых построены известные трюки. SDLPoP чинит их не молча, а ОПЦИОНАЛЬНО: каждое исправление отдельным переключателем, по умолчанию часть включена, часть нет. Мы до сих пор повторяли ваниль — сознательно, чтобы порт вёл себя как оригинал.

Задача: дать ДВА поведения на выбор, не размазывая условия по всему коду:

  • VANILLA — как в оригинале 1989 года, со всеми его багами;
  • BUGFIXED — с портированными исправлениями SDLPoP.

Что уже известно (из аудита)

Разбор расхождений — docs/sdlpop_audit.md. Оттуда прямо в эту задачу переезжает следующее.

Опциональные фиксы SDLPoP, которых у нас НЕТ

Все три относятся к прохождению сквозь препятствия и живут в do_fall (seg005) и рядом:

фикс SDLPoP что чинит
«скольжение сквозь стену» Кид падает сквозь стены после разворота в беге, особенно под зельем медленного падения
«прыжок сквозь стену над воротами» пролёт в тайл над воротами
«проваливание сквозь гобелен» падение сквозь тайл гобелена

Ни один не портирован — это и есть наше нынешнее VANILLA.

Находка 24 — отложена сюда

in_wall у нас пересчитывает только колонку, а оригинал перезагружает ещё и данные кадра (load_fram_det_col, seg006). Правка сделана и ОТКАЧЕНА 2026-08-31 по такой причине:

  • по букве оригинала находка верна;
  • но практического эффекта показать НЕ УДАЛОСЬ — все 15 наборов host-тестов дают одинаковый результат до и после, включая специально написанный тест на заход в кладку;
  • при этом правка не бесплатна: добавляет маппинг окна и перезагрузку кадра на каждое выталкивание из стены.

Платить за недоказанное не стали. Вернуться к ней имеет смысл именно здесь: при работе над BUGFIXED появится сценарий, где кадр меняется перед выталкиванием, и тогда эффект станет наблюдаемым.

Готовый детектор поведения

tests/host/t_wall.c расширен с одной проверки до трёх. Ключевая — wall_stops_jump_from_left_side: она НЕ требует нуля заходов в кладку, а сторожит их ЧИСЛО (сейчас ровно два случая из четырнадцати стартовых позиций).

Это и есть переключатель ожиданий между режимами:

  • больше двух — правка сделала нас хуже ванили, регресс;
  • ровно два — ведём себя как оригинал (режим VANILLA);
  • меньше двух — кто-то портировал фикс; в режиме BUGFIXED тест должен ждать нуля.

То есть когда появится BUGFIXED, этому тесту понадобится ожидание, зависящее от режима, — и он готов стать первым таким.

Что предстоит решить

  1. Как переключать. Ключ сборки (два разных .exe) или настройка в POP.CFG с проверкой в рантайме. У нас уже есть VANILLA/ENHANCED в меню настроек (docs/menu_settings_plan.md) — возможно, это то же самое измерение и стоит объединить, а не заводить второе.
  2. Цена рантайм-проверки. Условия попадают в физику и play_seq, то есть в горячий путь. Если переключать в рантайме, проверка должна быть дешевле самого фикса: флаг в резиденте, а не вызов через банк.
  3. Что считать умолчанием. Оригинальное поведение честнее для порта, но часть фиксов SDLPoP включает по умолчанию.
  4. Как тестировать оба режима. Host-тесты гоняются одним прогоном; для двух режимов нужен либо параметр сборки тестов, либо ожидания, зависящие от флага.

Список кандидатов на BUGFIXED

Пополняется по мере аудита. Пока:

  • три опциональных фикса SDLPoP выше;
  • находка 24 (перезагрузка кадра в in_wall);
  • находка 21 из аудита — общая рамка «мы намеренно повторяем ваниль».

Не относятся сюда находки, где мы расходимся с оригиналом НЕ в его пользу (ранги А и Б аудита): их надо чинить в обоих режимах, потому что это не баги оригинала, а наши.