Files
Sprinter-SDCC/applications/SprPoP/docs/prng_alternatives.md
T
snark13 31b82661eb SprPoP: автономное приложение, выделенное из roomtest
Порт PoP переехал в applications/SprPoP — приложение, которое собирается
само: код, оригинальные данные, конверторы ресурсов и сборка внутри одной
папки.  Наружу знает единственный путь — корень тулчейна (SPRINTER_ROOT,
по умолчанию ../..).  applications/PoP/roomtest ЗАМОРОЖЕНА и остаётся
архивом закрытых задач, багов и исполненных планов.

Скопировано из applications/PoP/roomtest@4b74478.  Перенос проверен
побайтово: собранный sprpop.exe совпал с roomtest.exe того же коммита,
все 39 дисковых ресурсов и все 16 генерируемых заголовков — тоже, host-
тесты зелёные (15/15).

Раскладка:
  src/           рукописный C (roomtest.c -> sprpop.c)
  gen/           генерируемые заголовки, в репозитории
  assets/orig/   оригинальные данные игры, вне репозитория (копирайт)
  assets/packed/ то, что ложится на диск, в раскладке диска
  tools/         конверторы; все пути — в одном tools/paths.py
  build/         выход: exe, каталоги ресурсов, hdd/, промежуточные atl/

Сборка ресурсов: assets/packed и gen — версионируемые ВХОДЫ, а не то, что
пересчитывается каждым make.  Автоматика построена на ОТСУТСТВИИ файла, а
не на таймстемпах: git не хранит времена, и в свежем клоне сравнение по
времени превращалось бы в лотерею.  Недостающий ресурс или заголовок
чинится сам, рекурсивным вызовом в ветку генерации.

Музыка собирается из любого из четырёх наборов записей (make music-mp3,
music-mt32, ...); набор входит в имя stamp'а, поэтому смена набора сама
делает музыку устаревшей.  Длины реплик больше не захардкожены: упаковщик
печатает их в gen/pop_music_ticks.h, и шкала сцены выражена через них —
иначе mt32 (реплики на 6% длиннее) молча ломал катсцену.

Тулчейн: в app.mk два обратносовместимых крючка (SRC_DIR/BUILD_DIR),
HDD_IMG стал ?=; команда сборки roomtest не изменилась.  Корневой
make host-tests переключён на SprPoP.

Подгонка тайминга катсцены с принцессой (PV_MAGIC_LEAD): сцена
render-bound и идёт ~49 тиков/с вместо 60, из-за чего кода реплики
приходила раньше молнии.  Это обход, а не лечение; разбор с замерами —
docs/BUGS_OPEN.md, записи SND-PACE-DEAD, PV-RENDER-BOUND, MUS-LEFT-TEAR.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-27 12:12:28 +03:00

6.4 KiB

Генераторы псевдослучайных чисел: запасные варианты

Что сейчас стоит в порте, какие есть альтернативы и сколько на них реально можно выиграть. Заготовка на случай, если упрёмся в бюджет кадра — сейчас менять ничего не нужно.

Что стоит сейчас

pop_geom.c, ветка POP_PRANDOM_EXACT=1 (по умолчанию) — LCG оригинала s = s*214013 + 2531011, шаг написан на Z80-ассемблере (единственное такое место в порте). Схема Горнера по разреженной записи константы:

214013 = ((((1<<1)+1)<<2 + 1)<<4 + 1)<<10 - 3

17 удвоений, три сложения, одно вычитание; величина 3*s, нужная в конце, попадается по дороге на втором шаге. Тело — ≈1 020 тактов по статическому подсчёту. Бит-в-бит совместим с SDLPoP, поэтому по картинке можно сверяться с эталоном.

Вторая ветка, POP_PRANDOM_EXACT=0 — xorshift16 + шаг Вейля на C. Совместимость теряется.

Замер в MAME, комната 3, 175 кадров (медиана кадра):

вариант кадр prandom → torch_draw
C, бит-в-бит (16-битные половины) 403 632 10 933
C, xorshift16 + Вейль 397 986 7 927
asm, бит-в-бит (сейчас) 400 800 9 331

Вариант A — комбинированный LFSR + LCG, ~148 тактов

Период > 4 млрд (lcm(65536, 65535) ≈ 4.29e9), младшие биты не вырождены.

prng16:
    seed1=$+1
    ld hl, 9999
    ld b, h
    ld c, l
    add hl, hl
    add hl, hl
    inc l
    add hl, bc
    ld (seed1), hl
    seed2=$+1
    ld hl, 987
    add hl, hl
    sbc a, a
    and 101101b
    xor l
    ld l, a
    ld (seed2), hl
    add hl, bc
    ret

Устройство: seed1 — LCG x = 5x + 1 (по модулю 2^16; inc l вместо inc hl — экономия байта, на период не влияет). seed2 — 16-битный LFSR Галуа: сдвиг влево, и если выехала единица, XOR младшего байта с маской 0x2D (примитивный многочлен x^16 + x^5 + x^3 + x^2 + 1). На выходе сумма обоих состояний — она и разрушает регулярность младших бит LCG.

Что мешает взять как есть: сиды зашиты в код (SMC), а нам нужны ДВЕ независимые последовательности — раскладка кладки и анимация тайлов. Пришлось бы передавать состояние через указатель, как сейчас у pop_prandom (это +20…40 тактов, не принципиально).

Вариант B — xorshift(7,9,8), ~86 тактов

Самый быстрый, период 65535.

xrnd:
    ld hl, 1       ; seed must not be 0
    ld a, h
    rra
    ld a, l
    rra
    xor h
    ld h, a
    ld a, l
    rra
    ld a, h
    rra
    xor l
    ld l, a
    xor h
    ld h, a
    ld (xrnd+1), hl
    ret

Две оговорки. Ноль — неподвижная точка, а сид раскладки кладки у нас считается как номер комнаты + смещение ряда + колонка и вполне может оказаться нулём: нужен либо guard, либо шаг Вейля поверх. И тот же SMC-сид, что в варианте A.

Чего НЕ брать: RND из Apple II

Оригинальный Prince-of-Persia-Apple-II:

RNDseed := (5 * RNDseed + 23) mod 256
RND
 lda RNDseed
 asl
 asl
 clc
 adc RNDseed
 clc
 adc #23
 sta RNDseed
 rts

Полный период 256 (a ≡ 1 mod 4, c нечётное), и для своего движка он работал. Нам не годится: у LCG по модулю 256 младшие биты вырождены — бит 0 просто чередуется. Наши вызовы это увидят: раскладка кладки берёт prandom(1) (ОДИН бит) и prandom(4), то есть вместо шума получилась бы аккуратная шахматка.

Сколько реально можно выиграть

Меньше, чем кажется по числам 86/148 против 1 020. Тело генератора — уже не весь расход: остаются обёртка pop_prandom, приведение к диапазону pop_rnd_fit и ABI вызова. Верхняя граница выигрыша видна из замера выше: между нынешним asm-LCG и самым дешёвым из проверенных вариантов разница 2 814 тактов за кадр (0.65 %) при двух вызовах за кадр, и это ПОТОЛОК — любой из вариантов A/B ниже него не опустится.

Порядок действий, если понадобится:

  1. Сначала убрать обёртки: слить pop_rnd_fit в ту же asm-процедуру, чтобы на вызов приходился один call, а не три. Это ничего не ломает и не трогает совместимость с эталоном.
  2. И только если этого мало — менять генератор, начиная с варианта A (качество последовательности у него не хуже LCG, в отличие от B).

Важно помнить: число вызовов вырастет с боёвкой. Сейчас их два за кадр (факелы), а guard_advance / guard_block / guard_strike дёргают prandom(255) каждый по разу за кадр боя — то есть при драке станет 5–6, и цена вопроса вырастет во столько же раз.