# Слои отрисовки: как устроен оригинал и чего стоит порт Разбор 2026-08-13, по `../SDLPoP/src/seg008.c`. Повод — семь дефектов падающих плит на уровне 13, из которых три оказались не багами кода, а следствием того, что у нас нет слоя, в котором объекты и куски тайлов сортируются между собой. Решение по этому документу ещё не принято. --- ## 1. Как это работает в оригинале ### 1.1 Три таблицы, а не «слои» `draw_tables` (seg008:1373) рисует ровно в таком порядке: ``` restore_peels(); draw_wipes(0); draw_table(0); // BACKTABLE draw_table(3); // MIDTABLE draw_wipes(1); draw_table(1); // FORETABLE ``` Это грубое разделение на три уровня глубины. Куда попадёт кусок тайла, решает переменная `ptr_add_table`, которую вызывающий переставляет перед `draw_tile*`: по умолчанию `add_backtable`, в оверлее кромки — `add_midtable` (`draw_other_overlay`, seg008:1499), а `add_foretable` вызывается явно и точечно. ### 1.2 Объекты живут НЕ в таблицах, а в objtable — и привязаны к ТАЙЛУ Персонажи, падающие куски, мечи, брызги попадают в `objtable`, и у каждой записи есть поле `tilepos` — тайл, которому объект принадлежит. Ключевое: объекты рисуются **не отдельным проходом после фона**, а ВНУТРИ обхода тайлов. В `redraw_needed_tile` (seg008:207) стоит: ```c if (tile_object_redraw[tilepos]) { if (tile_object_redraw[tilepos] == 0xFF) draw_objtable_items_at_tile(tilepos - 1); draw_objtable_items_at_tile(tilepos); tile_object_redraw[tilepos] = 0; } if (redraw_frames_fore[tilepos]) draw_tile_fore(); ``` То есть на каждом тайле: сначала его фоновые куски, потом объекты ЭТОГО тайла, потом его передние куски. ### 1.3 Порядок глубины складывается из ТРЁХ независимых механизмов | механизм | что даёт | |---|---| | порядок обхода тайлов: ряды **2, 1, 0**, колонки 0..9 (seg008:129) | тайл, обойдённый позже, рисуется поверх | | сортировка объектов ВНУТРИ одного тайла (`sort_curr_objs`, seg008:1553) | кто из объектов одного тайла поверх кого | | три таблицы back/mid/fore | грубая глубина для кусков тайлов | Сортировка внутри тайла (`compare_curr_objs`, seg008:1572) — пузырьком, и правил в ней три: ``` объект типа 1 (ТЕНЬ) — всегда первым; оба объекта — падающие плиты (0x80): y1 < y2 → по УБЫВАНИЮ y; любая другая пара: y1 > y2 → по ВОЗРАСТАНИЮ y. ``` Обратный порядок для пары плит — не описка: две плиты из `loose_fall` летят в 6 пикселях друг от друга, и верхняя обязана лечь поверх нижней. ### 1.4 Что из этого следует **«Сортируемый midtable» — неточное имя.** Глобальной сортировки среднего слоя в оригинале нет. Есть привязка объекта к тайлу и сортировка внутри тайла; всё остальное решает порядок обхода. Это принципиально дешевле общей сортировки: объектов на один тайл обычно 1-2. --- ## 2. Что делаем мы Наш кадр — жёсткая последовательность проходов, без привязки объектов к тайлам: ``` фон: pop_loose_tick (физика кусков) -> pop_process_trobs -> pop_redraw_needed -> редрой шва объекты: pop_loose_mob_draw (куски ПОД Kid, отсортированы по y между собой) pop_char_draw(OPP/KID) (порядок задаёт guard_over_kid) pop_loose_mob_draw_over (куски ПОВЕРХ Kid) перед: pop_fore_over_char — ТОЛЬКО в окне вокруг персонажа ``` Отличия, из которых растут все три оставшихся дефекта: 1. **Объект не знает своего тайла.** Глубина «кусок против Кида» считается отдельной формулой (`pop_room.c`, поле `defer`), а «кусок против КУСКА ТАЙЛА» не считается вовсе — куски тайлов рисуются раньше всех объектов. 2. **Передний слой считается только вокруг персонажа.** Это наша оптимизация (memory `pop_fore_layer_cost`: полный проход стоил 78 % кадра). Падающая плита в чужом углу комнаты передних частей тайлов поверх себя не получает — отсюда «плита перед колонной». 3. **Оверлей кромки идёт после персонажей** и потому безусловно поверх всех, тогда как у оригинала он в midtable и сортируется. --- ## 3. Что затрагивает порт | участок | объём правки | |---|---| | `pop_room.c` — куски | привязать к тайлу, убрать `defer`, убрать собственную сортировку | | `pop_cdraw.c` — персонажи | то же: объект вместо слота, привязка к тайлу | | `pop_bg.c` — `overlay_mid_tile`, `fore_only_tile`, `ceil_over_kid_tile` | вызов из обхода тайлов, а не из отдельного прохода | | `pop_redraw.c` — пометки | добавить «на этом тайле есть объект» (порт `tile_object_redraw`) | | `roomtest.c` — главный цикл | вместо трёх проходов один: обход тайлов с объектами внутри | | окно fore-клипа (`pop_t_fclip_*`) | смысл меняется: клип по тайлу, а не по персонажу | Плюс новая структура objtable и её сортировка — но маленькая, на тайл. --- ## 4. Плюсы * **Уходят разом** MOB-CLIP-RIGHT, MID-OVERLAY-LAYER и «плита перед колонной»: все три — следствие отсутствия привязки к тайлу, а не самостоятельные баги. * **Уходят подпорки.** Перерисовка соседнего тайла поверх куска, `defer`, ручная сортировка кусков, отдельный проход `draw_over` — всё это заменяется одним механизмом. * **Совпадение с оригиналом по построению.** Дальше любой вопрос «что поверх чего» решается чтением seg008, а не экспериментом в MAME. * **Возможный выигрыш по кадру.** Сейчас fore-проход считает окно вокруг персонажа и всё равно перебирает до девяти тайлов; при привязке к тайлу передние части рисуются только там, где реально есть помеченный объект. Но это НАДО ЗАМЕРИТЬ, а не обещать. --- ## 5. Минусы и риски * **Риск регресса широкий.** Трогается порядок отрисовки ВСЕГО: Кид, соперник, меч, брызги, зеркало, куски, оверлеи, полоса потолка. Уровни 1-11 приняты и держатся на текущем порядке. * **Наша оптимизация fore-окна может не пережить порт в прежнем виде.** Она даёт 3.2x на самом дорогом проходе (memory `pop_fore_layer_cost`). Если привязка к тайлу заставит рисовать передние части шире — можно потерять больше, чем выиграть. * **Дабл-буфер.** У оригинала один экран с dirty-rect, у нас две страницы со своими копиями фона и heal. Пометка «на тайле есть объект» обязана быть счётчиком страниц, как остальные наши пометки, — иначе объект перерисуется на одной странице и не перерисуется на другой. * **Банки.** Отрисовка размазана по трём банкам (`pop_bg` 2, `pop_cdraw` 4, `pop_room` 7) плюс резидент. Единый обход тайлов с объектами внутри означает, что цикл обхода зовёт код из всех трёх — надо проверить, что не упрёмся в границы банков и трамплины. * **Объём.** Это не правка, а этап: сопоставимо с тем, что делалось для fore-слоя. --- ## 6. Развилки **A. Полный порт** — objtable с привязкой к тайлу, сортировка внутри тайла, объекты внутри обхода. Максимально близко к оригиналу, максимальный риск и объём. **B. Частичный: только привязать КУСКИ к тайлам.** Персонажей оставить как есть. Закрывает MOB-CLIP-RIGHT и «плиту перед колонной», не трогает проверенный порядок персонажей. Дешевле и безопаснее; MID-OVERLAY-LAYER остаётся. **C. Отложить** до этапа BG-ONCE и делать вместе — там всё равно пересматриваются слои, и два пересмотра подряд дороже одного. Рекомендация: **B или C**. Вариант A целиком оправдан только если мы одновременно берёмся за BG-ONCE — тогда это один пересмотр слоёв вместо двух, и замер кадра делается один раз. --- ## 7. ЗАМЕРЫ (сделаны 2026-08-13, уровень 13) Метод — маркеры-пустышки в РЕЗИДЕНТЕ вокруг измеряемого вызова плюс брейкпоинты с `printf totalcycles` (memory `z80_profiling_method`). В банковый код брейкпоинт ставить нельзя: 0xC000 — общее окно всех банков. | что | такты | доля логического кадра | |---|---|---| | логический кадр целиком | **1 289 526** | 100 % | | `pop_redraw_needed` | **978** | 0,08 % | | **fore-проход, ОДИН персонаж** | **128 778** | **10 %** | Плюс два счётчика за прогон ~229 логических кадров: * fore-проход вызван **10 раз** — на 96 % кадров он не выполняется вовсе (пропуск неизменившегося персонажа, `pop_char_skip_mask`). Средняя цена по кадру выходит ~0,4 %, но КАК ТОЛЬКО персонаж движется — платим все 10 % каждый кадр, и при двух персонажах это ~20 %; * **максимум объектов на одном тайле = 2** (комната 16, пара из `loose_fall`: плита сбивает плиту, дальше летят обе). В комнате 23, где гряда падает в пустоту, максимум 1. ### 7.1 Что эти числа меняют в оценке **Сортировка внутри тайла — бесплатна.** Два объекта, пузырёк на два элемента. Возражение против варианта A, которое закладывалось в §5, снято. **`pop_redraw_needed` можно не считать вовсе.** 978 тактов против 128 778 у fore-прохода — соотношение 131 к 1. **Единственный настоящий риск порта — окно клипа fore-прохода.** Если привязка объектов к тайлам заставит рисовать передние части шире нынешнего окна вокруг персонажа, мы потеряем 10 % кадра, и потеряем их НА ДВИЖЕНИИ, когда бюджет и так самый напряжённый. ### 7.2 Что осталось выяснить ДО выбора варианта Как оригинал отсекает лишнюю работу переднего слоя: `redraw_frames_fore[tilepos]` рисует передние части ТОЛЬКО у помеченных тайлов (seg008:214). Надо понять, насколько узко эта пометка ставится — если не шире нашего окна, вариант A безопасен по кадру; если шире, остаёмся на B. **Обновлённая рекомендация:** решение упирается в §7.2, и до его разбора выбирать между A и B преждевременно. B остаётся безопасным запасным вариантом.