31b82661eb
Порт 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>
149 lines
6.4 KiB
Markdown
149 lines
6.4 KiB
Markdown
# Генераторы псевдослучайных чисел: запасные варианты
|
||
|
||
Что сейчас стоит в порте, какие есть альтернативы и сколько на них реально
|
||
можно выиграть. Заготовка на случай, если упрёмся в бюджет кадра —
|
||
**сейчас менять ничего не нужно**.
|
||
|
||
## Что стоит сейчас
|
||
|
||
`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), младшие биты не вырождены.
|
||
|
||
```z80
|
||
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.
|
||
|
||
```z80
|
||
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
|
||
```
|
||
|
||
```asm
|
||
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, и
|
||
цена вопроса вырастет во столько же раз.
|