snark13
dd40c24e7a
Найдено пользователем (2026-08-17, уровень 2 комната 4): после падения плит
(1,7) и (1,8) поверх стража в (1,0) появляются два чёрных бара, большой и
маленький, и МЕРЦАЮТ — то есть живут только на одной странице дабл-буфера.
Пока плиты не упали, баров нет.
Диагноз пользователя оказался верным дважды — и в причине, и в механизме.
ПРИЧИНА. Падение плиты (1,8) помечает соседа (1,9), и pop_floor_bake заливает
там прямоугольник ШИРИНОЙ 60 от x = 288 — то есть 348, на 28 пикселей за
экран. Ширина «свой тайл + свес соседа» (40/60/64 при шаге тайла 32) верна
для любой колонки, кроме последней.
А заливка по контракту НЕ КЛИПУЕТ, и это правильно: проверка координат стоила
бы дороже самой заливки (шапка _gfx_recthfill256: «Клиппинга НЕТ, координаты
обязаны быть валидны»). Значит обрезать обязан ВЫЗЫВАЮЩИЙ — bar не трогаем.
МЕХАНИЗМ МЕРЦАНИЯ (объяснение пользователя). Страница 1 начинается на 320
байт дальше страницы 0, поэтому запись в страницу 0 с x > 320 попадает в
страницу 1 по x−320. Отсюда и «бар только на одной странице». Хуже того,
такая же запись НА странице 1 уходит уже за пределы обеих страниц — в то, что
лежит дальше (палитры и прочее), так что баг не только косметический.
ПОДТВЕРЖДЕНИЕ АРТЕФАКТОМ. Трасса всех вызовов pop_bar_black на прогоне:
BAR x=288 y=117 w=60 h=39 ret=D754 <- pop_floor_bake, 288+60 = 348
и независимо снятое расхождение страниц: РОВНО x 0..27 (348−320 = 28 px) при
y 117..155 — то есть в точности y этого бара (yb+26 = 117, высота 39).
ФИКС. Хелпер bake_w(x, w) обрезает ширину по правому краю (и отдаёт 0, если
прямоугольник целиком за экраном); применён во всех точечных запечках —
pop_floor_bake, pop_ceil_bake_empty, pop_loose_bake_empty. Обрезка ничего не
теряет: правее 320 восстанавливать нечего. Копия второй страницы (bake_copy)
берёт ту же обрезанную ширину, иначе запечка и копия разъехались бы.
Заодно, того же рода:
- pop_torch_wipe у факела в колонке 9 заливал x = 328, то есть ЦЕЛИКОМ за
экраном — теперь пропускается;
- pop_loose_bake_empty читал POP_COL_XH[col + 1] БЕЗУСЛОВНО, то есть у
последней колонки за концом массива (10 элементов); чтение убрано под
проверку.
Отсечено по дороге (проверками, не рассуждением): копия запечки не виновата
(сборка с выключенной копией — бары остались, проверил пользователь).
8 наборов tests-host зелёные.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Prince of Persia на ZX Sprinter
Порт Prince of Persia на компьютер Sprinter Sp2000 поверх нашего target-слоя SDCC (sprinter-cc / libc / libbgi). Цель — 320×256×256 (режим 0x81), VGA-256 ассеты оригинала переносятся почти впрямую.
Состояние (2026-08-01): играется весь уровень 1 — комнаты и переходы, Kid со всем набором действий, ловушки, ворота, дверь уровня, меч и бой, стражи с ИИ, HP и зелья. Нет: перехода на следующий уровень, звука, таймера/HUD, сохранений.
- Что в работе прямо сейчас —
roomtest/TASKS_OPEN.md. - Следующий этап (уровни 2+) —
docs/levels_plan.md. - Общий план и статус фаз —
docs/PORT_PLAN.md. - Правила работы для ИИ-сессий —
CLAUDE.md.
Что где
| Папка | Назначение |
|---|---|
roomtest/ |
Активная разработка. Уровень 1 целиком: фон композицией тайлов, Kid (seqtbl-анимация, ввод, коллизия, падение, зацеп, окклюзия), ловушки, ворота, стражи, бой. Свой README/CLAUDE/TASKS. |
docs/ |
Планы и разбор форматов ресурсов Apple II / DOS — см. индекс в docs/README.md. |
toolchain/ |
Python-упаковщики ассетов под Sprinter (рендер комнат, атласы тайлов/Kid, извлечение данных анимации) + эталонные скриншоты. |
poc/ |
Ранний proof-of-concept (снег, атлас, raw-клавиатура). Ассеты в poc/res/. |
bgtest/, coltest/ |
Точечные проверки фона и коллизии. |
SDLPoP/, PR/, mininim/ |
Референсные реализации движка (GPL) — читаем логику/константы, НЕ копируем код. SDLPoP/data/ — источник распакованных VGA-ассетов. |
Prince-of-Persia-Apple-II/ |
Оригинальный 6502-исходник 1989 г. |
MSDOS/ |
Локальные .DAT-ресурсы DOS-версии. |
Референсы = только справочник
SDLPoP/, PR/, mininim/, Prince-of-Persia-Apple-II/ используются как
справочник структур/логики и как источник готовых ассетов — их код НЕ
копируется в наш порт (лицензии несовместимы, ABI другой). Любая механика
сверяется с SDLPoP/src/ до реализации.
Форматы ресурсов
Формат уровня почти идентичен в Apple II и DOS (2304 / 2305 байт,
blueprnt). Графика различается принципиально, но брать распакованные PNG
из SDLPoP/data/ практичнее, чем декодировать сырой .DAT. Подробности —
docs/README.md.