fparkan/docs/tomes/07-implementation.md

# VII. Работа над движком

FParkan развивается небольшими законченными изменениями. Для нового поведения
сначала нужен пример из оригинала и Rust-тест, затем реализация и объяснение
в соответствующей главе. Если меняется видимый результат, проверка заканчивается
запуском приложения на настоящих игровых ресурсах.

## Где находится код

Библиотеки в `crates/` читают архивы и форматы, связывают ресурсы миссии,
вычисляют геометрию и хранят мир. Они не создают окно и не обращаются к GPU.
Окно находится в адаптере winit, графические ресурсы — в адаптере Vulkan.
`fparkan-game` связывает их в приложение.

У файла на диске и объекта в игре разные сроки жизни. Одна модель может быть
прочитана однажды и использоваться многими объектами, у каждого из которых
свои положение и время анимации. Материалы и текстуры тоже разделяются между
экземплярами. Владение этими данными видно из Rust-структур; отдельный сервис
или интерфейс добавляется, когда появляется реальная потребность.

## Один тест на правило

Для бинарного формата полезен короткий массив байтов: тест проверяет значения
полей и отказ при обрыве записи или неправильной ссылке. Для преобразования
координат удобны точки и повороты, результат которых легко посчитать вручную.
Тесты находятся рядом с соответствующим алгоритмом и запускаются через
`cargo test --workspace`.

Оригинальные ресурсы остаются в установленной игре. Локальные тесты с ними
помечены `#[ignore]`, чтобы обычная проверка работала без коммерческих файлов.
Сообщение об ошибке должно сразу назвать ресурс и причину: например, какой
материал сослался на отсутствующую текстуру. Поэтому диагностика остаётся
частью самого запуска и не зависит от отдельного отчёта.

## Числа и порядок вычислений

Порядок умножения матриц имеет значение: поворот объекта вокруг своей оси и
поворот его положения вокруг начала мира дают разные результаты. Единицы высоты
ландшафта могут отличаться от единиц размещённых объектов. Эти преобразования
выполняются в одном месте и проверяются конкретными точками.

Оригинальный x86-код использует x87. Промежуточное значение может иметь большую
точность, чем сохранённый `float32`. Особенно внимательно проверяются переходы
между кадрами анимации, округление и границы треугольников. Эмулировать x87 во
всём движке не требуется: существенные расхождения разбираются в конкретной
формуле.

Случайные числа и порядок обхода тоже влияют на поведение. Перестановка вызовов
генератора меняет время молнии или траекторию частицы даже при прежнем seed.
Для повторяемой проверки сохраняют начальное состояние и одинаковую
последовательность шагов. Дополнительные потоки и альтернативные алгоритмы
имеют смысл после измерения узкого места.

## Проверка изображения

Успешное создание Vulkan pipeline доказывает только корректность обращения
к API. Положение моделей, масштаб карты, текстуры, прозрачность и свет
проверяются в самом окне. Validation layer помогает находить ошибки владения
GPU-ресурсами, синхронизации и пересоздания swapchain.

Кадр для сравнения читается после завершения работы GPU. При изменении размера
окна старые framebuffer и изображения освобождаются лишь после окончания их
использования. При сворачивании окно может иметь нулевой размер; тогда новые
кадры не отправляются. Обычное закрытие завершает программу успешно.

Оптимизация начинается с измерения: время загрузки, число повторных декодирований,
объём текстур и время кадра. Повторное использование уже загруженного ресурса
обычно полезнее дополнительного слоя управления кэшем.