snark13
bbf91d10ee
DRAW-CHAR. Отрисовка персонажа сведена к одному набору функций над Char — как физика после GUARD-PHYS. В оригинале add_kid_to_objtable (seg008:22F0) и add_guard_to_objtable (seg008:2324) имеют идентичное тело и различаются окном (loadkid/loadshad), набором спрайтов и типом объекта, а redraw_at_char/redraw_at_char2 гейтов по charid не имеют вовсе. pop_gdraw.c -> pop_cdraw.c: pop_char_draw/heal/fore(who), слот POP_CH_KID / POP_CH_OPP; состояние слотов pop_cd[] в _DATA — читается из любого банка без трамплина. Проход окклюзии тоже один (pop_fore_over_char), pop_fore_over_kid больше нет. Починилось само (расхождения, которые и были ценой дублирования): у соперника не было clip_char; у Кида не было клипа полем 192 и ветки брызг «мёртв/падение»; char_width_half СТРАЖА считался по спрайту КИДА. Замер: _CODE 24 881 -> 20 524 (куча 2023 -> 6333), BANK2 -265, итого -3.2 КБ. Проверено пользователем в MAME; циан-полоса профиля подросла — оптимизация заведена отдельной задачей DRAW-COST. MEM-BANK2, шаг 1: общие «листья» слоя фона в РЕЗИДЕНТ (pop_tile.c/.h). Ограничение платформы: писучие данные банка лежат в _DATA и видны всем, а const-таблицы — в странице банка, из другого банка их не прочитать; трамплин же выбирается объявлением, то есть __banked на листе бьёт и по горячим вызывающим (654 такта). W1 замаплено всегда — оттуда обе половины зовут листья прямым call и читают таблицы напрямую. MEM-BANK2, шаг 2: дедуп внутри банка. wall_pattern 808 -> 394 и wall_rnd 786 -> 654: четыре ветки по виду стены отличались только набором кусков и числами в одной серии prandom — сведены к таблицам WP_PARTS и WR_RULE, порядок вызовов prandom сохранён дословно. Заодно: kid_seq_off больше не static const в kid_data.h (230 Б мёртвой копии в каждом из 9 модулей) — генератор pop_extract_kid_data.py отдаёт макро-инициализатор, массив определяет один pop_kid.c. Итог: BANK2 14 815 -> 11 942 (72.9 %, свободно 4442 Б), _CODE 22 556, куча 4301 Б. tests-host зелёные (65/39/53/1723/1); в MAME комната 1 совпала с дорефакторным снимком попиксельно (0 из 227 520), комната 3 — та же раскладка кладки. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
48 lines
3.0 KiB
C
48 lines
3.0 KiB
C
/*
|
||
* _pop_draw.h — внутренний заголовок слоя отрисовки: выбор ядра libbgi
|
||
* (клипающее / линейное «noclip») по одному и тому же тесту для блита и
|
||
* для heal.
|
||
*
|
||
* ПОЧЕМУ ОТДЕЛЬНЫЙ ФАЙЛ, А НЕ pop_bg.h. Обе функции — `static inline`, а
|
||
* SDCC 4.5 оставляет тело такой функции в КАЖДОМ TU, который видит
|
||
* объявление, даже если тот её не зовёт (memory
|
||
* `sdcc_inline_codegen_findings`). pop_bg.h включают почти все модули PoP,
|
||
* то есть из общего заголовка эти ~100 Б размножились бы десятком мёртвых
|
||
* копий (замер CLIP-1, 2026-08-01: +1091 Б в _CODE и +636 Б в банке
|
||
* стража — за код, который там никто не вызывает). Здесь их видят ровно
|
||
* три файла, которые реально рисуют: pop_bg.c, pop_kid.c, pop_cdraw.c.
|
||
*/
|
||
#ifndef POP_DRAW_H
|
||
#define POP_DRAW_H
|
||
|
||
#include <stdint.h>
|
||
#include <gfx.h>
|
||
|
||
/* Спрайт целиком на экране И укладывается в 8-битные параметры noclip-
|
||
* примитивов libbgi? Условие входа в gfx_blit_cols_part_noclip: клипающий
|
||
* вариант платит ~5.6 К тактов подготовки на КАЖДЫЙ вызов, независимо от
|
||
* того, вылезает край или нет. */
|
||
static inline uint8_t pop_onscreen_cols(int x, int y, uint16_t w, uint16_t h)
|
||
{
|
||
return (uint8_t)(x >= 0 && y >= 0 && w < 256 && h < 256 &&
|
||
x + (int)w <= 320 && y + (int)h <= 256);
|
||
}
|
||
|
||
/* Стереть прямоугольник (heal из ОЗУ-копии) тем же приёмом, что и блит:
|
||
* целиком на экране → линейное ядро без клипа. Условие входа у
|
||
* gfx_heal_noclip ровно то же, что у gfx_blit_cols_part_noclip, поэтому
|
||
* тест один — общее ядро gfx_heal платит за клип и 16-бит, а не за пиксели
|
||
* (замер: 11 658 тактов на heal 22×22).
|
||
*
|
||
* НЕ inline (тело — pop_draw.c, резидент W1): SDCC 4.5 встраивал бы его в
|
||
* каждое место вызова по 181 Б И оставлял мёртвую копию в каждом TU — см.
|
||
* шапку pop_draw.c с замером. Зовётся 5 раз за кадр, цена вызова тонет в
|
||
* стоимости самого heal.
|
||
*
|
||
* w/h тут int, а не uint16_t: вызывающие считают их вычитанием (h − skip), и
|
||
* отрицательный результат обязан быть no-op, а не превратиться в огромный
|
||
* unsigned. */
|
||
void pop_heal_fast(int x, int y, int w, int h);
|
||
|
||
#endif
|